何謂軟體工程？

我們在程式設計（programming）與軟體工程（software engineering）之間看到三個關鍵區別：時間、規模以及權衡。

在軟體專案中，工程師需要更加注意時間的流逝以及最終的需求變更。

在軟體工程組織中，我們需要更加關注規模（scale）和效率（efficiency），無論是對我們生產的軟體，還是對生產軟體的組織。

最後，做為軟體工程師，我們被要求做出更複雜的決策，其結果風險更大，因為這往往是基於對時間和成長不精確的估計。

在Google內部，我們有時會說：「軟體工程是隨著時間的推移不斷整合的程式設計。」程式設計無疑是軟體工程的重要部分：畢竟，程式設計是你首先產生新軟體的方式。如果你接受這種區別，那麼顯然，我們可能需要在程式設計任務（開發）和軟體工程任務（開發、修改、維護）之間進行劃分。時間的加入，為程式設計添加了一個重要的維度。正如立方體不是正方形，距離不是速度。軟體工程不是程式設計。

觀察時間對程式之影響的一種方法是，思考這樣一個問題：「你的程式碼的預期壽命（life span）是多久？」這個問題的各個合理答案大約可以相差到10萬倍。程式碼存活幾分鐘是合理的，存活幾十年的程式碼一樣是合理的。一般來說，位於該光譜短端（short end）的程式碼將不受時間的影響。對於效用只有一個小時的程式，你不太可能需要去適應（adapt）其背後之程式庫（library）、作業系統（OS）、硬體或程式語言的新版本。這些短命（short-lived）的系統實際上「只是」一個程式設計問題，就像是立方體在一個維度上被壓縮得很厲害時就成為正方形一樣。當我們把時間擴大到允許更長的壽命時，變化就會變得更為重要。在十年或更多的時間裡，大多數程式的依賴關係（dependency），無論是隱性的還是顯性的，都可能發生變化。這種認識是我們區分軟體工程和程式設計的根源。

這種區別是我們所謂的軟體的「可持續性」（sustainability）之核心。如果在你的軟體的預期壽命內，你能夠出於技術（technical）或業務（business）的原因，對任何有價值的變化做出反應，則你的專案是「可持續的」（sustainable）。重要的是，我們只看重能力──你可能選擇不進行某項升級，無論是因為缺乏價值，還是因為其他優先事項。當你完全無法對底層技術或產品方向做出反應時，你就是在下一個高風險的賭注，希望這種變化永遠不會成為關鍵。對於短期的專案來說，這可能是一個安全的賭注。但是在幾十年的時間裡，這可能並不安全。

另一種看待軟體工程的方法是考慮規模（scale）。涉及多少人？隨著時間的推移，他們在開發和維護中扮演什麼角色？程式設計任務通常是個人創造的行為，但是軟體工程任務是團隊的工作。早期定義軟體工程的嘗試為此觀點提供了一個很好的定義：『多人開發的多版本程式』（The multiperson development of multiversion programs）。這說明了軟體工程與程式設計的區別是時間與人員的區別。團隊協作帶來了新的問題，但也提供了比任何單個程式員更多的潛力來營運有價值的系統。

團隊組織、專案組成以及軟體專案的政策和實施方法都主導著軟體工程複雜性這一方面。這些問題是規模固有的：隨著組織的成長和專案的擴展，它在生產軟體方面是否會變得更有效率？我們的開發流程是隨著我們的成長變得更有效率，還是我們的版本控制政策和測試策略會按比例增加我們的成本？從軟體工程早期開始，人們就一直在討論關於溝通（communication）和人員擴展（human scaling）的規模問題（scale issues），這可追朔到《人月神話》（Mythical Man Month）。這樣的規模問題通常是政策問題，也是軟體可持續發展的根本問題：重複進行我們需要做的事情，成本有多少？

我們也可以說，軟體工程與程式設計的不同之處在於需要做出決策的複雜性及其利害關係。在軟體工程中，我們經常被迫在多條前進道路之間做權衡，有時風險很大，有時價值指標（value metrics）並不完善。軟體工程師或軟體工程領導者的工作目標是實現組織、產品和開發工作流程的可持續性（sustainability）和擴展成本（scaling costs）管理。考慮到這些問題，評估你的權衡並做出合理的決定。

我們有時可能會推延維護方面的變更，或甚至會接受那些擴展性不好的政策，因為我們知道，我們將需要重新審視這些決策。這些選擇應該明確和清楚地說明推延的成本。

在軟體工程中，很少有一個萬能的（one-size-fits-all）解決方案，本書也是如此。對於「軟體的使用壽命是多久」，合理的答案是100,000（十萬）的因數；對於「你的組織中有多少工程師」的範圍，可能是10,000（一萬）的因數；而對於「你的專案有多少運算資源可用」，誰知道是多少呢；Google的經驗可能與你的經驗不符。

在本書中，我們的目的是介紹我們在軟體建構和維護中發現的行之有效的方法，我們預期這些軟體能夠持續數十年，擁有數以萬計的工程師，以及跨越世界的運算資源。我們發現，在這種規模下，大多數必要的實施方法也適用於較小規模的工作：考慮到這是一份關於工程生態系統（engineering ecosystem）的報告，我們認為隨著規模的擴大，這種生態系統可能會有不錯的效果。在某些地方，超大的規模是有固定的成本，因此如果不用支付額外的費用，我們會很樂意的。我們將此視為一個警訊。

希望如果你的組織發展到需要擔心這些成本的程度時，你可以找到一個更好的答案。

海勒姆法則

如果你要維護供其他工程師使用的專案，那麼關於「它是有效的」與「它是可維護的」的最重要教訓是所謂的海勒姆法則（Hyrum's Law）：

如果有足夠的API用戶，那麼你在契約中的承諾就無關緊要：你的系統所有可觀察到的行為都會被某個人所依賴。

根據我們的經驗，這個原則（axiom）是任何關於軟體隨時間變化之討論中的主導因素（dominant factor）。從概念上講，它類似於熵（entropy）：在討論隨時間變化和維持時，必須注意到海勒姆法則，正如討論效率和熱力學時，必須注意到熵一樣。僅僅因為熵永遠不會減少，並不意味著，我們不應該嘗試提高效率。僅僅因維護軟體時適用海勒姆法則，並不意味著，我們不能未雨綢繆或者不能更好地瞭解它。儘管我們可以減輕它的影響，但我們知道，它永遠無法根除。

海勒姆法則代表了這樣的實務知識（practical knowledge）：即使有最好的意圖、最好的工程師以及程式碼審查（code review）方法，我們也不能假設你會完全遵守已發布的契約或可靠的最佳實施方法（best practices）。做為一個API擁有者，你可以透過清楚瞭解介面承諾來獲得一定的靈活性和自由度，但實際上，一個給定之變更的複雜性和困難度還取決於用戶發現API的某些可觀察到之行為的有用程度。如果用戶不能倚賴這樣的東西，你的API將很容易變更。如果有足夠的時間和足夠的用戶，那麼即使是無害的變更也會破壞一些東西；你對這些變更的價值分析必須將調查、確定和解決這些問題的困難度納入其中。（本文摘錄整理自《Google的軟體工程之道》第一章，碁峰資訊提供）

 書名  Google的軟體工程之道：從程式設計經驗中吸取教訓

Titus Winters, Tom Manshreck, Hyrum Wright／著；蔣大偉／譯

歐萊禮出版

定價：880元

 作者簡介 

Titus Winters
Titus Winters是Google高級軟體工程師。他是Google C++程式碼基底的程式庫負責人：每月有數千名不同的工程師編輯2.5億列的程式碼。圖片來源／Titus Winters

Tom Manshreck
Tom Manshreck是Google軟體工程部技術作家。他是C++程式庫團隊的成員，負責開發文件、開設培訓課程，以及記錄Google的開源C++程式碼Abseil。圖片來源／Tom Manshreck

Hyrum Wright
Hyrum Wright是Google軟體工程師，負責領導Google的auton自動變更工具組。Hyrum對Google之程式碼基底進行的個人編輯比公司歷史上任何其他工程師都多。圖片來源／Hyrum Wright