為什麼軟體會被稱為“軟體”

軟體工程比任何其他工程學科都更需要返工，因為軟體涉及到抽象概念。如果準確描述硬體都會有困難的話，那可以想象一下人們形容那些只存在於腦海裡的想法或晶片中電流的傳導模式該是多麼困難。我一下就想到了一句格言：“入此門者，莫存希望”（Abandon all hope, all ye who enter here）。 如果終端使用者可以詳細闡明其想要的功能，如果軟體工程師能夠完全瞭解使用者現在和未來的需求，那我們可能就不需要軟體了。每個編寫出來的程式可以第一時間就被燒錄到只讀儲存器（ROM）裡。遺憾的是，這種完美的世界並不存在。

在早期做軟體設計師的日子裡，我常常會追求軟體的完美。我反覆修改子程式，直到它們能夠最快速地執行，程式碼也足夠乾淨整潔；我還重複審閱程式，希望能找出哪怕一丁點的改進之處；在想到任何新點子的時候，我都會去新增新的功能（是的，我就是傳說中的“功能控”）。我盡情發揮，直到老闆將我拽回到現實。

“該釋出軟體了。”他宣佈。

“可是我還沒有幹完呢！再多給我幾天時間吧……”

“永遠都沒有做完的軟體，只有釋出的軟體。”

在軟體釋出之後，沒有人真正知道會發生什麼。經驗豐富的工程師可能會有一些模糊概念，大概知道軟體面對的客戶群，它會被應用於什麼樣的環境之下，等等。但他們很難預料這款軟體產品最終的命運到底是成功還是失敗。

我一度在一家大型電腦公司擔任電話技術支援工程師。在幹過多年作業系統的設計工作之後，我轉換成了一個與以往截然不同的角色，開始為我們編寫的程式作客戶支援。這段工作經歷確實讓我眼界大開。從事軟體設計工作時，你其實很容易掉入一個怪圈，認為一切盡在自己的掌握，誤以為自己很瞭解人們會如何使用你的軟體。

你錯了。也許你確實對此信心十足。但是，安然待在辦公室工作間的工程師，身邊圍繞的同事與自己一樣同樣擁有高學歷，他能意識得到下列諸多情況嗎？

• 某個在交易日導致系統反覆崩潰的核心bug可能會給一家華爾街企業造成每小時100多萬美元經濟損失。一個星期之後，該公司在心煩意亂的情況下選擇安裝原系統競爭對手的產品。可再過了一個月，他們還是重新切換成最早的系統，因為儘管它有一些缺陷，但在這兩個系統之間，還是原來的系統顯得更為可靠。
• 一家石油公司可能會使用某個系統來對墨西哥灣進行地震波掃描以尋找天然的石油儲備。他們每天都會獲取到千兆位元組資料，這需要在系統叢集上安裝90多塊大硬碟。人們必須能夠隨時獲取所有資料。而且出於安全考量，沒有任何一名地質學家能夠持有訪問所有關鍵資料的金鑰，這是因為公司很擔心會有人帶著在哪開採石油的機密資訊跑掉，這將會給公司造成數十億美元的損失。
• 一家每天在資料庫中儲存超過1000萬條記錄的電信公司想設計一個新系統，讓它每天可以插入1億條記錄。每秒處理1000次資料庫的插入動作本身就已經夠困難的了，可現在，他們不得不在高峰期處理每秒高達5000次的資料插入工作。
• 某家電力公司的系統是美國最大一個州的電網中央控制器。一旦該系統出現故障，就可能導致百萬人斷電。

Unix的開發人員當然不知道Unix上會發生什麼事情。MS-DOS、OpenVMS和一切其他作業系統的開發人員也一樣。每一個新的作業系統（Linux也不例外）都會將它們的設計者帶到未知領域。他們唯一的希望就是不斷收集系統使用報告，然後糾正過程中的相應偏差。

例如，Ken Thompson在編寫第一個Unix核心時，有沒有注意到可移植性的重要性呢？顯然沒有，因為他使用的是組合語言。後來，他採取了一門高階語言對它進行了改寫，也改變了原來的方向。那麼， Dennis Ritchie是否預料到了C語言將成為一門通用程式語言，讓數百萬的程式設計師為之愛恨交加呢？也沒有。他那本經典著作The C Programming Language 的修訂版包括了對該語言規範的修訂，這更加讓我們確信他在第一次創作的時候並沒有將它完全折騰好。

因此，我們大多數人都還在學習。即使我們自負到認為自己知曉一切，也總會有人改變對我們的期望。那我們到底該如何開發軟體呢？接下來的這條原則是關鍵。

本文摘自《Linux/Unix設計思想》