>>>  技術話題—商業文明的嶄新時代  >>>

簡體     傳統

所有軟件活動包括根本任務——打造由抽象軟件實體構成的復雜概念結構，次要任務——使用編程語言表達這些抽象實體，在空間和時間限制內將它們映射成機器語言。軟件生產率在近年內取得的巨大進步來自對后天障礙的突破，例如硬件的限制、笨拙的編程語言、機器時間的缺乏等等

一個相互牽制關聯的概念結構，是軟件實體必不可少的部分，它包括：數據集合、數據條目之間的關系、算法、功能調用等等。這些要素本身是抽象的，體現在相同的概念構架中，可以存在不同的表現形式。盡管如此，僅由于它們是不同的人——而非上帝——設計的結果。

軟件工程師卻無法從類似的信念中獲得安慰，他必須控制的很多復雜度是隨心所欲、毫無規則可言的，來自若干必須遵循的人為慣例和系統。它們隨接口的不同而改變，隨時間的推移而變化，而且，這些變化不是必需的，僅僅由于它們是不同的人——而非上帝——設計的結果。

畢竟，我的從業背景是程序員，樂觀主義是這個行業的職業病。

普遍的做法是，選擇一種方法，試試看；如果失敗了，沒關系，再試試別的。不管怎么樣，重要的是先去嘗試。
- 富蘭克林 D. 羅斯福1

It is common sense to take a method and try it. If it fails, admit it frankly and try another. But above all, try something.
- FRANKLIN D. ROOSEVELT1

但是我們中的一些——那些非常固執，以致于可以認為是現實主義者的人——把它看成是清新的空氣。我們終于可以將焦點集中在更加可行的事情上，而不是空中的餡餅。現在，有可能，我們可以在軟件生產率上取得逐步的進展，而不是等待不大可能到來的突破。

《人月神話》的觀點：是或非？（Propositions of the Mythical Man-Month: True or False？）
我們理解的也好，不理解的也好，描述都應該簡短精練。
塞繆爾·巴特勒，諷刺詩
For brevity is very good, where we are, or are not understood.
SAMUEL BUTLER Hudibras

編程系統產品（Programming Systems Product）開發的工作量是供個人使用的、獨立開發的構件程序的九倍。我估計軟件構件產品化引起了3倍工作量，將軟件構件整合成完整系統所需要的設計、集成和測試又強加了3倍的工作量，這些高成本的構件在根本上是相互獨立的。

編程行業“滿足我們內心深處的創造渴望和愉悅所有人的共有情感”，提供了五種樂趣：
􀂉 創建事物的快樂
􀂉 開發對其他人有用的東西的樂趣
􀂉 將可以活動、相互嚙合的零部件組裝成類似迷宮的東西，這個過程所體現出令人神魂顛倒的魅力
􀂉 面對不重復的任務，不間斷學習的樂趣
􀂉 工作在如此易于駕馭的介質上的樂趣——純粹的思維活動，其存在、移動和運轉方式完全不同于實際物體

同樣，這個行業具有一些內在固有的苦惱：
􀂉 將做事方式調整到追求完美，是學習編程的最困難部分
􀂉 由其他人來設定目標，并且必須依靠自己無法控制的事物（特別是程序）；權威不等同于責任
􀂉 實際情況看起來要比這一點好一些：真正的權威來自于每次任務的完成
􀂉 任何創造性活動都伴隨著枯燥艱苦的勞動，編程也不例外
􀂉 人們通常期望項目在接近結束時，（bug、工作時間）能收斂得快一些，然而軟件項目的情況卻是越接近完成，收斂得越慢
􀂉 產品在即將完成時總面臨著陳舊過時的威脅

良好的烹飪需要時間，某些任務無法在不損害結果的情況下加快速度。

關于進度安排，我的經驗是為1/3計劃、1/6編碼、1/4構件測試以及1/4系統測試。

為了獲得概念完整性，設計必須由一個人或者具有共識的小型團隊來完成。

第二個系統是人們所設計的最危險的系統，通常的傾向是過分地進行設計。

為功能分配一個字節和微秒的優先權值是一個很有價值的規范化方法。

即使是大型的設計團隊，設計結果也必須由一個或兩個人來完成，以確保這些決定是一致的。
出于精確性的考慮，我們需要形式化的設計定義，同樣，我們需要記敘性定義來加深理解。

工作手冊的使用者應該將注意力集中在上次閱讀后的變更，以及關于這些變更重要性的評述。

傳統的樹狀組織結構反映了權力的結構原理——不允許雙重領導。

精煉、充分和快速的程序。往往是戰略性突破的結果，而不僅僅技巧上的提高。
更普遍的是，戰略上突破常來自于數據或表的重新表達。數據的表現形式是編程的根本。

對于大多數項目，第一個開發的系統并不合用。它可能太慢、太大，而且難以使用，或者三者兼而有之。

系統的丟棄和重新設計可以一步完成，也可以一塊塊地實現。這是個必須完成的步驟。

因此，為舍棄而計劃，無論如何，你一定要這樣做。

在大型的團隊中，各個小組傾向于不斷地局部優化，以滿足自己的目標，而較少考慮隊用戶的整體影響。這種方向性的問題是大型項目的主要危險。

出于這個原因，廣受吹捧的市場概念——支持管理人員的“完備信息管理系統”并不基于反映管理人員行為的有效模型。
“開發人員交付的是用戶滿意程度，而不僅僅是實際的產品。”（Cosgrove）

用戶的實際需要和用戶感覺會隨著程序的構建、測試和使用而變化。

軟件產品易于掌握的特性和不可見性，導致了它的構建人員（特別容易）面臨著永恒的需求變更。
程序員不愿意為設計書寫文檔的原因，不僅僅是由于惰性。更多的是源于設計人員的躊躇——要為自己嘗試性的設計決策進行辯解。（Cosgrove）

對于一個廣泛使用的程序，其維護總成本通常是開發成本的40％或更多。

在每次修復之后，必須重新運行先前所有的測試用例，從而確保系統不會以更隱蔽的方式被破壞。
所有修改都傾向于破壞系統的架構，增加了系統的混亂程度。即使是最熟練的軟件維護工作，也只是放緩了系統退化到不可修復混亂的進程，從中必須要重新進行設計。[許多程序升級的真正需要，如性能等，尤其會沖擊它的內部結構邊界。原有邊界引發的不足常常在日后才會出現。]

目標機器的使用需求量是一種特殊曲線：剛開始使用率非常低，突然出現爆發性的增長，接著趨于平緩。

同天文工作者一樣，系統調試總是大部分在夜間完成。

自頂向下、徹底地開發一個性能仿真裝置。盡可能早地開始這項工作，仔細地聽取 “它們表達的意見”。
有限的數據表明了系統軟件開發中，交互式編程的生產率至少是原來的兩倍。

系統調試的困難程度證明了需要一種完備系統化和可計劃的方法。

“項目是怎樣延遲了整整一年的時間？⋯一次一天。”

一天一天的進度落后比起重大災難，更難以識別、更不容易防范和更加難以彌補。

根據一個嚴格的進度表來控制項目的第一個步驟是制訂進度表，進度表由里程碑和日期組成。

里程碑必須是具體的、特定的、可度量的事件，能進行清晰能定義。

如果里程碑定義得非常明確，以致于無法自欺欺人時，程序員很少會就里程碑的進展弄虛作假。

進取對于杰出的軟件開發團隊，同優秀的棒球隊伍一樣，是不可缺少的必要品德。

對于大型項目，一個對里程碑報告進行維護的計劃和控制（Plan and Control）小組是非常可貴的。

對于軟件編程產品來說，程序向用戶所呈現的面貌與提供給機器識別的內容同樣重要。

即使對于完全開發給自己使用的程序，描述性文字也是必須的，因為它們會被用戶－作者所遺忘。
培訓和管理人員基本上沒有能向編程人員成功地灌輸對待文檔的積極態度—
—文檔能在整個生命周期對克服懶惰和進度的壓力起促進激勵作用。

軟件系統可能是人類創造中最錯綜復雜的事物（從不同類型組成部分數量的角度出發）。

軟件工程的焦油坑在將來很長一段時間內會繼續地使人們舉步維艱，無法自拔。

人類歷史是一個舞臺，總是上演著相同的故事。隨著文化的發展，這些故事的劇本變化非常緩慢，而舞臺的布局卻在隨時改變。正是如此，我們發現二十世紀本身會反映在莎士比亞、荷馬的作品和圣經中。因此，某種程度上，《人月神話》是關于人與團隊的書，所以它的淘汰過程會是緩慢的。

核心觀點：概念完整性和結構師

概念完整性。一個整潔、優雅的編程產品必須向它的每個用戶提供一個條理分明的概念模型，這個模型描述了應用、實現應用的方法以及用來指明操作和各種參數的用戶界面使用策略。用戶所感受到的產品概念完整性是易用性中最重要的因素。（當然還有其他因素。Macintosh上所有應用程序界面的統一就是一個重要的例子。此外，有可能建立統一的接口，盡管它可能很粗糙，就像MS-DOS。）

有很多由一個或者兩個人設計的優秀軟件產品例子。大多數純智力作品，像書籍、音樂等都是采用這種方式創作出來的。不過，很多產業的產品開發過程無法負担這種獲取概念完整性的直接方法。競爭帶來了壓力，很多現代工藝的最終產品是非常復雜的，它們的設計需要很多人月的工作量。軟件產品十分復雜，在進度上的競爭也異常激烈。

今天，我比以往更加確信。概念完整性是產品質量的核心。擁有一位結構師是邁向概念完整性的最重要一步。這個原理決不僅限于軟件系統，它適用于所有的復雜事物，如計算機、飛機、防御系統、全球定位系統等。

盲目的功能（Featuritis）。對于如電子表格或字處理等通用工具的結構師，一個不斷困擾他們的誘惑是以性能甚至是可用性的代價，過多地向產品添加邊界實用功能。

總結：為用戶群的屬性明確地記載各種猜測。清晰和錯誤都比模糊不清好得多。

“開發第二系統所引起的后果（second-system effect）”情況怎樣？一位敏銳的學生說，人月神話推薦了一劑對付災難的處方：計劃發布任何新系統的第二個版本（第11章），第二系統在第5章中被認為是最危險的系統。

這實際上是語言引起的的差異，現實情況并不是如此。第5章中提到的“第二個”系統是第二個實際系統，它是引入了很多新增功能和修飾的后續系統。第11章中的“第二個”系統指開發第一個實際系統所進行的第二次嘗試。它在所有的進度、人員和范圍約束下開發，這些約束刻畫了項目的特征，形成了開發準則的一部分。

特別值得注意的是，他建議開發項目后期增加的開發人員，必須作為團隊成員，愿意在過程中努力投入和工作，而不是企圖改變或者改進過程本身！

更基本的是，這來自一個信念，即對于項目的成功而言，項目人員的素質、人員的組織管理是比使用的工具或采用的技術方法更重要的因素。

過去在軟件生產率上取得的進展大多數來自消除非內在的困難，如笨拙的編程語言、漫長的批處理周轉時間等。

像這些比較容易解決的困難已經不多了。

徹底的進展將來自對根本困難的處理——打造和組裝復雜概念性結構要素。

抽象數據類型提供了一種思考和指明模塊接口的統一方式，以及容易保證實施的類型規范化訪問方法。

E.F.Schumacher在他的經典《小就是美：人們關心的經濟學》（Small is Beautiful：Economics as if People Mattered）中，提出了最大化員工創造力和工作樂趣的理論。他的第一個原理是引自Pope Pius XI教皇通諭Quadragesimo Anno中的“附屬職能行使原理”：
向大型組織指派小型或者附屬機構能夠完成的職責是不公平的，同時也是正常次序的不幸和對它的干擾。對于每項社會活動，就其本質而言，應該配備對社會個體成員的幫助，而不是去破壞和吸收它們那些當權者應該確信遵守“附屬職能行使”原理，能在各種各樣的組織中維持更加完美的次序，越強和越有效的社會權威將會是國家更加融洽和繁榮的條件。

正如人們所預期的，完全不同的經濟學引發了非常不同的編程文化。傳統產業傾向于被大型公司以已指定的管理風格和企業文化所支配。另一方面，始于數百家創業公司的成品軟件產業，行事自由，更加關注結果，而不是流程。在這種趨勢下，那些天才的個人程序員更容易獲得認可，這隱含了“卓越的設計來自于杰出的設計人員”的觀點。創業文化能夠對那些杰出人員，根據他們的貢獻進行獎勵。而在傳統軟件產業中，公司的社會化因素和薪資管理計劃總會使上述做法難以實施。因此，很多新一代的明星人物被吸引到薄膜包裝的軟件產業，這一點并不奇怪。

今天，軟件工程的一些特殊問題正如第1章中所提出的：
􀂉 如何把一系列程序設計和構建成系統
􀂉 如何把程序或者系統設計成健壯的、經過測試的、文檔化的、可支持的產品
􀂉 如何維持對大量的復雜性的控制
軟件工程的焦油坑在將來很長一段時間內會繼續地使人們舉步維艱，無法自拔。軟件系統可能是人類創造中最錯綜復雜的事物，只能期待人們在力所能及的或者剛剛超越力所能及的范圍內進行探索和嘗試。這個復雜的行業需要：進行持續的發展；學習使用更大的要素來開發；新工具的最佳使用；經論證的管理方法的最佳應用；良好判斷的自由發揮；以及能夠使我們認識到自己不足和容易犯錯的——上帝所賜予的謙卑。

人月神話 2011-01-01 08:31:39