程式碼之道

第2部分 (第1/4頁)

我很關注微軟內部團隊在軟體開發的過程中，他們是如何去處理技術與人際交流之間的關係的；這類欄目總是我的最愛。看到大量的公司內幕被寫了出來，我常常會感到吃驚——我不知道還有多少不為人知的故事沒有說出來。

大型專案中的軟體工程管理者面臨著3個基本的問題。第一個是，程式程式碼太容易被改變了。跟機械或土木工程不一樣，它們在現有系統上做一次改變總是要付出實實在在地拆毀某些東西的代價，而軟體程式的改變只需要敲敲鍵盤就行了。如果對一座橋的橋墩或一架飛機的引擎做一個錯誤的結構性更改，由此產生的後果，即使不是專家也很容易就能看出來。然而，如果在一個現有程式上做修改，對於其風險，即使經驗豐富的軟體開發者進行了充分的討論，其結果常常還是錯的。

建築隱喻實際上可以很好地適用於軟體。基於程式程式碼在系統中所處的層次，它們可以被比作為“基礎、框架和裝飾”。“基礎”程式碼具有高度的槓桿作用，它們的改動常常會引起嚴重的連鎖反應。“裝飾”程式碼比較容易改動，而且也需要被經常改動。問題是，累積了幾年的改變之後，複雜的程式就跟歷經過幾次裝修的房子差不多了——電源插座躲到了櫥櫃的後面，浴室風扇的出風口通向了廚房。再做任何改變的話，其副作用或最終的代價都是很難預知的。

第二個基本問題是，軟體行業還太年輕，關於可複用元件的正確標準實際上還沒有被發現或建立起來。大頭釘是否應該放在離開16英寸的地方，以同時適應水平或垂直的4x8英尺的幹壘牆或夾板？我們不僅在這類問題上還沒有取得一致意見，甚至我們還沒有決定，是否像大頭釘、幹壘牆和夾板這樣的組合更可取，還是我們要去發明像泥漿、稻草、石頭、鋼鐵和碳化纖維這樣的組合。

最後一個問題實際上是第二個問題的另一種表現形式。每個專案中重複發明的軟體元件，它們也被重複命名了。軟體行業裡對現有的概念發明新的名字是很常見的，即使用的名字相同，這些名字也以新的方式被重用。行業裡有一個心照不宣的秘密：關於軟體開發最佳方法的相當多的討論，參與的實際上都是同一群人，只不過他們用了不同的名字，他們甚至對彼此正在說的東西都沒有一個哪怕是很朦朧的想法。

表面上看來，這些都是很簡單的問題。建立一些標準，然後強制實行它們。在快速進步的大容量、高價值、低成本的軟體世界裡，這可是一個讓你的業務落敗的捷徑。實際情況是，軟體最大的工程障礙，同時也是它最大的優勢。無處不在的軟體（執行在低成本的個人電腦和網際網路上），已經使得以驚人的步伐去創新成為可能。

隨著微軟的成長，公司已經不再能在最佳工程實踐的研究方面大量地投入，然後經過深思熟慮，挑選出其中具有最好質量的方法。個人電腦和Windows的成功，已經把公司從按傳統方式做些小專案的形態轉變出來，轉而要去譜寫開發有史以來最龐大、最複雜軟體的新篇章。

為了能夠建立出平衡風險與效率、創新的最佳系統，微軟面臨著持續不斷的掙扎。考慮到我們的一些專案有著極度的複雜性，這些努力甚至可以稱得上“英勇無畏”。在過去的一段時間以來，我們已經設定了專員、建立了專門的組織，他們都一心一意、致力於這個行業裡最困難的事情——“軟體釋出”。我們已經學會了很多的民間傳說、風俗、文化、工具、過程和大拇指規則（譯者注：Rules　of　Thumb，是指沒有經過科學實驗、直接從實踐中總結出來的方法和規則；它們在很多情況下都有用，但並不是放之四海皆準），那些都有助於我們建造和釋出這個世界上最複雜的軟體。但與此同時，每天都處理這些問題難免也讓人心驚膽戰、士氣受挫。Eric的欄目正是大家跟我們一起分享和學習的極好方式。

Mike　Zintel，微軟公司Windows　Live核心開發部門總監

2007年8月

第3章

根除低下的效率

本章內容：

2001年7月1日：“遲到的規範書：生活現實或先天不足”

2002年6月1日：“閒置人手”

2004年6月1日：“我們開會的時候”

2006年7月1日：“停止寫規範書，跟功能小組呆在一起”

2007年2月1日：“糟糕的規範書：該指責誰？”

正如我在第2章的“精益：比帕斯雀牛肉還好”欄目中所說