相關閱讀 |
>>> 創業先鋒 眾人拾柴火焰高 >>> | 簡體 傳統 |
在我先前的博客中,我主要講了我們的編碼風格應該適應我們所處的業務領域。即不同的業務領域需要不同編碼風格的軟件。例如,為防御體系寫的軟件必須強健穩定,因為一次崩潰可能就會終結它的生命周期,而為市場交易寫的軟件,則必須可維護,并且還可以添加廣告,通常這些項目和軟件的生命周期都非常短,所以這些軟件還必須可以重復使用。 雖然我之前從沒看到過它被應用于這些業務領域,但是關于編碼優先順序這一觀點卻并不是最近才出來的。我第一次看到這一觀點是在Steve Maguire寫的一本由微軟出版社于1997年出版的書上,書名叫做《Debugging the Development Process》。 在這本書中,Steve論述了關于在編寫軟件時,我們應該建立優先順序的觀點。他列舉的他認為需要考慮的優先事項包括: 規模 速度 穩健性 安全性 可測試性 可維護性 簡單 可重用性 可移植性 現在說說那個時候的背景——1997年,那時的CD-RW驅動器和媒介剛問世,內存還很昂貴,處理器還很慢,語種選擇還是C / C++。 隨著時間的推移,現在的Java程序員通常毋需再考慮規模和速度,所以上面的列表可以縮減為: 安全性 可測試性 穩健性 可維護性 簡單 可重用性 下面我們要討論的是上面這個列表是否還適用于今天,具體為…… 雖然寫著的是“安全性”,但是Steve真正想說的是編程范例和算法。有些技術是比其他的要來得更安全,例如,使用查表返回值比使用邏輯驅動來計算數值要安全。我們設計時也需要考慮到安全性這一特點。 對我來說,這兩者差不多。從定義上講,經過充分測試的代碼就會比較穩健。如果你正在使用測試驅動開發(TDD),那么你也可以將這一條從列表中刪除,這是因為它們在此進程中是固有的。如果你是不喜歡使用TDD的程序員大軍中的一員,那么這一條應該保留…… 這一條可以反映出一個人的代碼風格、思維條理和清楚表達自己的能力。在風格方面,大家可以借鑒Uncle Bob在《Clean Code>中的描述,這也是我最喜歡的書籍之一。Uncle Bob的風格……怎么說呢,整體感覺就是干凈。方法和類都很短,服從SRP和整潔的布局。這也是優秀軟件的關鍵屬性。 代碼簡單是我們共同的目標追求,但是這并不意味著寫出來的代碼是被過分簡化的,我們只需要做到,代碼雖然最簡化,沒有裝飾、沒有鍍金,也不具備以后可能需要添加的功能,但是依然可以完成工作。這種最簡化代碼的觀點已然成為了敏捷社區的核心思想,甚至Shane Warden和James Shore也在他們的《The Art of Agile Development》一書中,花費了一整章的篇幅來描述這一觀點,包括它的概念,如“once and only once”以及“you ain’t gonna need it”。 這一點我就不多說了,我們總是希望現在寫的代碼以后還可以再次使用,省時省力。 首先,自1997年以來,很多事情都發生了變化,這是毋庸置疑的。但是在我看來,一些好的觀點依然值得我們學習和借鑒…… (來源:碼農網)1.安全性
2.可測試性和穩健性
3.可維護性
4.簡單
5.可重用性
綜上所述
CocoaChina 2015-08-23 08:44:23
稱謂:
内容: