《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
翻譯作者:碼農網 –小峰
- 延伸閱讀
(轉載自合作夥伴《碼農網》)