怎樣編寫優秀軟體

軟體必須是自由的
優秀軟體是自由軟體。我將避免使用“開源”，因為它根本沒有包含社會層面，它和技術本身同等重要。你可以從這裡瞭解更多。

廣泛被接受的工具和語言
編寫優秀軟體的語言是被廣泛使用的，這使得有人能夠閱讀和修改程式碼。優秀的語言，比如C、Python 和 Java。當然也有例外，一些較少被使用的語言是更好的選擇。

保持簡單
優秀軟體不做不必要的事情。換句話說，沒有不必要的功能。實現沒人使用的功能只會產生 bug。設計軟體時，保持簡單應該作為最高優先順序。正如愛因斯坦說的“讓事情儘可能簡單，而不是比較簡單。”
太多抽象是糟糕的。如果你把程式碼隱藏在多層抽象之後，你也隱藏了 bug。太多的抽象讓程式碼難以理解，難以跟蹤執行路徑和 debug。它也會降低效能。抽象之上的抽象經常可以在 Java 編寫的企業軟體中看到。優秀軟體可以用 Java 編寫，但是 Java 也讓編寫恐怖的、結構複雜程式碼變得非常容易。C++也是如此。

不要弄成火箭科學
使用具有真正意義的變數名。不要使用單字元變數名。它們幾乎不可能理解和追蹤。也有單字元的變數名，它們是被普遍接受了。例如對於座標，用x和y就行。對於迴圈，就使用i，j等等。除此之外，不要這樣使用了。通常地，對於優秀軟體，程式碼的結構是清晰的，還有可查的、記錄下來的程式碼風格。

文件是重要的
不管文件是多麼地讓人厭煩，優秀軟體也是有文件的。程式碼有清晰的註釋，軟體有隨之一起安裝的手冊。對於 web 應用程式，讓文件可以線上上訪問到。
開發者經常認為，當軟體被完成後再去寫文件，就足夠了。那是完全錯誤的方式。文件必須是開發人員在開發軟體過程中的一件事情。文件必須是開發的一部分，而不是程式碼被寫完之後的工作。

使用版本控制系統
優秀軟體使用版本控制系統，一直都用。如今我差不多總是推薦 Git 做版本控制，但是有一些情況，SVN 之類的系統就可以做得很好了。版本控制容易回滾到可能有問題的修改。考慮下面的例子，如果沒有版本控制系統，該怎麼辦：

開發者A修改了檔案 program.c，該檔案被拷貝到了原始碼樹（source tree），舊檔案被替換了。後來發現了一個 bug，問題出在開發者A對 program.c 所做的修改。開發者B、C等人費了好大勁兒才搞清楚開發者A修改了什麼。如果有版本控制系統，這就不是問題了。當然聰明的開發組應該有備份的，因此在這種情況下，他們將找到修改前的原始備份，使用 diff 工具看看修改了什麼地方。然而，既花時間、又麻煩。更不要提從備份拷貝並替換檔案是多麼地容易出錯了。

擴充套件性
擴充套件性不是嚴格意義上的強制項，不過它經常讓軟體更加有用。開發軟體、便於讓它能夠與其它軟體一起被使用，是一種優秀的方式。事實上，這是 Unix 主要設計原則之一。

例子
網際網路充滿了編寫良好的軟體。很多標準的 Unix 工具編寫良好，然而有些就不是。一個寫得不錯的例子是 Memo，這是我寫的軟體。
如果需要推薦一本書，那麼我會為你推薦 Eric Raymond 編寫的《Unix 程式設計藝術》。

英文原文：How to write good software