程式者的胡言亂語
星期三 七月 23, 2008
程式員與開發文件之間的恩怨情仇
倘若談起開發文件，恐怕是許多程式員在內心深處最不願意碰觸的一個領域。大多數的程式員會認定自己工作職責在於程式設計，而對於「撰寫」所謂的開發文件，多半避之危恐不及，甚至認為那是浪費生產力的一件事情。
對於開發文件，在我的第一份程式設計工作中有一個相當特殊的規定 － 星期一至星期四寫程式，而在星期五寫所謂的「文件」。在我的這一份工作中，程式員被要求要撰寫的文件，便是程式碼的說明文件，其作用在於解釋自己每一片段的程式碼究竟在做些什麼事。公司會有這樣的要求，其根本的原因還是在於程式碼的銜接。在這家公司中，每個程式員都只照料自己撰寫的程式碼，而自己所照料的程式碼，也就只有自己最為熟悉，倘若遇上了離職或工作需要交接的其他情況，難免製造出一些額外的負擔和困擾。我所任職的公司在遭遇幾次此類的風波後，決定實施讓程式員們四天撰寫程式碼，一天撰寫這些程式碼的說明文件的制度。
對程式員來說，程式碼撰寫完成了，幾乎都會認定工作完成了。遇上了必須撰寫程式碼說明文件的硬性規定，無不視為是工作以外的額外負擔。可以想見的，倘若沒有實施徹底的審閱制度，大家寫起文件來，多半也只是徒具形式罷了。沒有適當的審閱制度，甚至沒有統一的文件結構，那麼文件本身是不是正確、能不能充份的表達程式碼的作用、能不能易於被他人所理解，都會構成極大的問題。原先的出發點或許是良善的，但是往往很難達成原先想達成的目的。這正是許多文件在開發流程中的問題所在，文件有文件打算達成的目標，可是文件本身的設計及配套的施行方法並不足以輔助文件達成，最後便使得文件形式化，大家也就以一種應付、交差了事的態度來面對。
在上例中的程式碼說明文件，不過只是軟體開發工作中會涉及的文件中的一類罷了。事實上，程式員在開發工作中可能會涉及的文件，隨著採用的開發方法或流程規範的不同，還會有各種不同類型的文件。例如，具有系統設計工作的程式員，或許就必須負責撰寫系統的設計文件。
但不論是那一類型的文件，僅具形式、過度工程化（過度擴張需求），都是造成程式員對文件持有負面觀感的原因。
此外，程式員之所以往往視開發文件為洪水猛獸，其中有很一個很主要的原因是這些文件之所以需要存在，往往只是基於管理上的需求，甚至是基於業務上的需求。好比在上例中的程式碼說明文件之所以需要存在，其主要原因是因為管理上對程式員工作交接的考量。我看過許多專案在完成即將交付客戶之際，才開始撰寫系統分析、系統設計的文件，原因無它，只是因為這些文件是合約中明訂必須交付予客戶的交付項目。而當這些文件的撰寫是基於此類的目的時，更是容易被程式員視為是額外的負擔。
倘若你團隊中所採用的文件，不論是流程文件（例如像輔助建構管理流程的「簽出簽入登錄表」）或開發技術文件（例如系統設計文件），不能為開發工作帶來真正的助益，而只是徒增負擔，便代表你們所採用的文件存在根本的問題。而這麼一來，這樣的文件更難說服程式員打從心裡接受它不會帶來額外的力氣花費。
不論你所採用的開發方法論為何，基本上在整個開發工作中總難免涵蓋系統分析、系統設計、系統實作、以及系統測試等工作。只不過，在不同的開發方法下如何進行、串接，以及各項工作的份量不盡相同罷了。
對於大型的團隊來說，系統分析人員、系統設計人員、程式實作人員、測試人員等角色各司其職。對程式員來說，多半專職於程式撰寫的工作，或是客串一下系統設計人員。諸如系統分析文件，那是系統分析人員的份內工作，沒有程式實作人員會抱怨系統分析文件為他帶來太多的額外負擔。不過，對於小型、輕量級的開發團隊來說，一名程式員或許有可能同時扮演系統分析、系統設計、以及程式實作的角色，過於繁文褥節的系統分析文件，就有可能帶來很大的產能損失及程式員的怨言。
先前提到，到了專案即將交付時，才開始準備系統分析文件、系統設計文件等相關文件的專案屢見不鮮。像這樣的情況，系統都已經完成了才開始後補文件，自然會讓開發人員認為文件本身是多餘的，因為沒有這些文件，系統也能完成。讓開發人員認為文件是多餘的，自然而然會造成開發人員對撰寫文件的抗拒心理。
事實上，開發中所產出的文件，是為了輔助系統的建構而生的。我很喜歡有些人利用「建模（modeling）」來描述他們所做的系統分析以及系統設計工作。系統分析及系統設計是系統實作的前期工作，它們的效用在於為即將實作出來的系統，提供一個具體而微的模型。人們喜歡用建造建築物來比喻建構軟體的過程。而在現實生活中，人們在利用鋼筋、水泥等材料建造一棟大樓之前，總是會先完成繪製設計圖、建立大樓模型的相關工作。
在我們還沒有完全明白我們所要打造的東西究竟是什麼之前，我們得透過一個漸進的過程，逐漸的拓展我們對它的認識。所以，我們先做了系統分析，了解我們的目標為何。接著，我們做了高階設計，描繪出系統高階的抽象樣貌。再來，我們進行低階設計，更深入的探索更靠近實作層次的細節。總算，我們有了一整套的施工藍圖，得以按圖中所描繪者，開始具體的建造工作。
從「建模」的觀點來看，系統分析文件及系統設計文件是我們在開始撰寫實際的程式碼時的中間產物，它們是愈來愈清晰、愈來愈具體的模型。它們的作用在於輔助產出最後程式碼，而不是在於做為一種僅有形式的象徵。
許多程式員對於文件的反感來自於，組織看待文件的角度失焦。組織並未適度的因應團隊及產品的特性調整文件需具備的元素，使得組織所規範設計的文件格式，內含過多不能為接下來產出程式碼派上用場的元素。也就是說，組織不知道應當權衡折衝，針對團隊的特性，留下真正有用、同時捨棄一些可能帶來過度生產力浪費的元素。
以組織的角度來看，應當要設計適宜的流程及文件，在不造成過度負擔的情況下，同時兼顧文件做為溝通、記錄、建模、..等的用途。這些文件應是輔助整體開發的中間產物。
而從程式員的角度來看，開發中所產出的文件，不應是程式碼撰寫工作之外的額外工作。它們是輔助你寫下具體程式碼的縮小抽象模型。或許你表面上可以不做任何分析、設計的工作，但你也不過只是把分析和設計的工作都濃縮在撰寫程式碼的階段中來進行罷了。你還是得在撰寫程式碼的同時考量、分析系統應有的長相、你還是得在腦中描繪出系統的高階架構。但更糟的是，你把這些事情都混在一塊做了，你沒有辦法漸進的在不同的抽象層級上以適當的抽象程度來思考系統。當你需要和多人一同工作時，沒有一個擺在大家面前可供討論、溝通的模型，又要如何確保彼此之間的認知能達成一致呢？這中介的模型，應當是用來協助程式員寫下最終實際碼的輔助工具，而不是浪費生產力的凶手呀。這正是許多程式員對此類文件最大的誤解所在。事實上，你不是在「撰寫文件」，你是在建立系統的模型。
因此，應讓團隊確實的在專案的不同階段，適度的完成該階段應該達成的目標，並且完成應產出的開發文件。許多團隊不在系統分析階段做分析，不在系統設計階段做設計，他們拿著混凝土就直接灌起漿來了。他們的系統分析文件、系統設計文件自然可以後補。運氣好，憑藉著團隊中天才洋溢的程式員，大樓還能維持一定品質。倘若先天不佳後天再失調，這大樓恐怕就會搖搖欲墜。
Blogged with Flock
Posted at 06:18下午 七月 23, 2008 by Chien-Hsing Wang in General | 迴響[1]
这些文章是您写的吗？期待更多好文章
由...發表 coderjoy on 七月 24, 2008 at 01:38 下午 CST #