《TO》導讀：原文作者 Roger Hughes 是一名工程師，也是一名部落格作者；以下為第一人稱編譯。
在我先前的博客中，我主要講了我們的編碼風格應該適應我們所處的業務領域。即不同的業務領域需要不同編碼風格的軟件。
例如，為防禦體系寫的軟件必須強健穩定，因為一次崩潰可能就會終結它的生命週期，而為市場交易寫的軟件，則必須可維護，並且還可以添加廣告，通常這些項目和軟件的生命週期都非常短，所以這些軟件還必須可以重複使用。
雖然我之前從沒看到過它被應用於這些業務領域，但是關於編碼優先順序這一觀點卻並不是最近才出來的。我第一次看到這一觀點是在 Steve Maguire 寫的一本由微軟出版社於 1997 年出版的書上，書名叫做《Debugging the Development Process》（台灣翻譯：軟體研發致勝策略）。
在這本書中，Steve 論述了關於在編寫軟件時，我們應該建立優先順序的觀點。他列舉的他認為需要考慮的優先事項包括：
● 規模
● 速度
● 穩健性
● 安全性
● 可測試性
● 可維護性
● 簡單
● 可重用性
● 可移植性
現在說說那個時候的背景 —— 1997 年，那時的 CD-RW 驅動器和媒介剛問世，內存還很昂貴，處理器還很慢，語種選擇還是 C / C++。
隨著時間的推移，現在的 Java 程序員通常毋需再考慮規模和速度，所以上面的列表可以縮減為：
● 安全性
● 可測試性
● 穩健性
● 可維護性
● 簡單
● 可重用性
下面我們要討論的是上面這個列表是否還適用於今天，具體為……
- 1. 安全性
雖然寫著的是「安全性」，但是 Steve 真正想說的是編程範例和算法。
有些技術是比其他的要來得更安全，例如，使用查表返回值比使用邏輯驅動來計算數值要安全。我們設計時也需要考慮到安全性這一特點。
- 2. 可測試性和穩健性
對我來說，這兩者差不多。從定義上講，經過充分測試的代碼就會比較穩健。如果你正在使用測試驅動開發（TDD），那麼你也可以將這一條從列表中刪除，這是因為它們在此進程中是固有的。如果你是不喜歡使用 TDD 的程序員大軍中的一員，那麼這一條應該保留 ……
- 3. 可維護性
這一條可以反映出一個人的代碼風格、思維條理和清楚表達自己的能力。
在風格方面，大家可以藉鑑 Uncle Bob 在《無瑕的程式碼：敏捷軟體開發技巧守則（Clean Code）》中的描述，這也是我最喜歡的書籍之一。
Uncle Bob 的風格……怎麼說呢，整體感覺就是乾淨。方法和類都很短，服從 SRP 和整潔的佈局。這也是優秀軟件的關鍵屬性。
- 4. 簡單
代碼簡單是我們共同的目標追求，但是這並不意味著寫出來的代碼是被過分簡化的，我們只需要做到，代碼雖然最簡化，沒有裝飾、沒有鍍金，也不具備以後可能需要添加的功能，但是依然可以完成工作。
這種最簡化代碼的觀點已然成為了敏捷社區的核心思想，甚至 Shane Warden 和 James Shore 也在他們的《敏捷開發藝術（The Art of Agile Development）》一書中，花費了一整章的篇幅來描述這一觀點，包括它的概念，如「once and only once」以及「you ain’t gonna need it」。
- 5. 可重用性
這一點我就不多說了，我們總是希望現在寫的代碼以後還可以再次使用，省時省力。
- 綜上所述
首先，自 1997 年以來，很多事情都發生了變化，這是毋庸置疑的。但是在我看來，一些好的觀點依然值得我們學習和借鑒……
譯文鏈接：http://www.codeceo.com/article/rank-order-best-code.html
英文原文：A Ranking Order for Coding Priorities
翻譯作者：碼農網 –小峰
- 延伸閱讀
（轉載自合作夥伴《碼農網》）
