程序員必須養成良好的代碼習慣
養成良好的代碼習慣，就是將代碼寫的漂亮，執行效率也自然就得到了提升。軟件開發中包含太多東西了，需求的、設計的、測試的、管理的、文化的、心里的、溝通的，需要大家自己去琢磨。
前天在AgileChina2009上聽了Fred George的演講，他說他以前拿自己的代碼給Kent Beck看，結果Kent說這代碼很垃圾，你去看看我寫的Smalltalk best practice patterns吧。然后Fred George就看了這本書并且完全按照書上的要求去做，5年后當他再給Kent看自己的代碼時，Kent說很漂亮的代碼。
考慮到Fred比Kent要老，可以看出Fred是非常虛心的，聽了Kent的評價不僅沒有生氣，而且還完全聽從了建議。當然這也可能是Kent太出名的緣故，若是我說他的代碼不好，或許他就不會這樣做了。
這讓我聯想到有一次和8x一起面試，8x的手工重構讓我很是驚訝。雖然我也看過《重構》，雖然我平時也重構，但是不論從步伐還是安全性上，都相差深遠。我讀《重構》的時候對如此小步伐的改變是不太贊同的，因為效率比較低。我認為書中之所以把條目分的很詳細，每個條目的步驟很小很謹慎，完全是為了可以讓支持重構的工具得以實現，對于人來說，保持這樣小的步驟太難了，不管是從記憶還是從操作的角度來看。然而8x的表現讓我改變了看法，不僅速度并不慢，而且安全性非常的高?；叵肫鹞业闹貥嫿洺３霈F改錯以后沒法返回的問題，不禁感嘆－－差距啊。
經常在國內的論壇上看到各種討論設計、架構的帖子，然而每每show代碼的時候卻發現一塌糊涂。當然他們自己不覺得，可是我覺得很不好。最近 Kent Beck和Robert C.Martin出的兩本書《Implementation Patterns》和《Clean Code》都是討論一些很細節的東西的，如何命名、方法應該要多長、注釋怎么寫、格式怎么排等等，這些東西早在《The Element of Programming Style》中其實都有對應的東西，只不過語言不同了，細節方面也不同。然而為何這么多年來，一直有人不停的寫本質上相同的東西呢？我覺得還是大家不重視，沒有養成良好的習慣，自然就需要有人去寫這些東西，反反復復的提醒大家。
這里再一次很慚愧的說，我沒有好好去讀，也沒有按照書中的東西認真去做，總是以為大概了解個概念，知道怎么回事，然后差不多做到了就行了。然而現在想來，卻完全不是那么回事。記得XP中有很多非常“極限”的要求，都是“一定”要如何如何，可實際上很多人都不以為然，認為太過激進，實際操作不現實或者不必要，因此在實施的時候，做了一些妥協和變通，***失敗了還說XP不好。當然XP不可能是包治百病的靈丹，在某些情況下確實也不應該用它，但是很多人明明可以從中獲益，卻因為沒有領悟到其中的精髓而早早放棄。
比如說TDD，看起來與一般的單元測試的不同只是把寫測試的工作放在了寫代碼之前，而Pair Programming也不過就是兩個人坐在一起寫程序罷了。然而在實際應用中，卻會發現TDD并不是那么簡單，它帶來的好處是你在使用之前完全想不到的，甚至很多都和Test是無關的。而Pair也不簡單的就是兩個人干一份工，如何根據技能的不同組合Pair，兩人如何分工都有很大的講究，甚至一般的對于Pair目的的理解可能也是錯誤的。因此要想證明一件東西能不能起作用，首先要完全按照他要求的方式去做，等到你真的把該遇到的問題都遇到了，你才能真正知道它是什么，能做什么，不能做什么，***才知道它到底能解決什么問題，不能解決什么問題。
在說回到代碼習慣的問題，軟件開發中包含太多東西了，需求的、設計的、測試的、管理的、文化的、心里的、溝通的……要想掌握這么多東西是很大的挑戰。如何將一件事記住而不忘掉，***的辦法就是將之變成習慣，就像呼吸一樣自然，不需要刻意去想就能做到。良好的代碼習慣是一個開發人員最基本的技能，使之成為習慣，會獲益很多。
決定在看一遍《重構》和《實現模式》并完全按照其中的要求去做，爭取也能在5年之內將之養成習慣。
原文標題：代碼習慣
鏈接：http://www.cnblogs.com/wangyh/archive/2009/09/15/clean-code.html
【編輯推薦】
