記得來TW之前看到過一個論壇上有人對TW的一條評價：這是一個奇怪的公司，非常強調代碼風格。

現在已經在TW工作半年多了，回想起這句話，發現自己已經完全融入到這種“奇怪的”代碼風格了。簡言之，就是要把程序寫的清晰易懂，易維護。具體如何達到這種目的。可以參看下面thoughtworks文集中的一篇，對象健身操，中所闡述的“編程規范”。

方法只使用一級縮進

拒絕else關鍵字

封裝所有的原生類型和字符串

一行代碼只有一個“。”運算符

不要使用縮寫

保持實體對象簡單清晰

任何類中的實例變量都不要超過兩個

使用一流的集合

不使用任何Getter/Setter/Property

以上的這些標題如果感覺不是很能表意，不妨去網上搜下或者買本thoughtworks文集看看。其中第一條中的具體內容提到“把函數控制在5行”。其他條目中也有一些具體的“變態的”要求。

我在開頭把“編程規范”打上引號的意思是：這不是真正要嚴格遵守的規范，而是一個方向。以此為方向寫出來的程序能夠在一定程度上符合前面提到的“清晰易懂，易維護”。我一直認為，標準一定是要定高一些的，這樣即使不能完全達到標準的要求，也會為此為努力。比如你的標準是60分，你可以輕松的達到而自我滿足；而我的標準是101分，雖然永遠都達不到，可是我可以保持在饑餓的狀態，從而不斷的進步。

工作的前4，5個月，大部分時候寫的是一些新代碼?？梢蚤_心的按照上述的原則去編碼。事實上寫出來的代碼也能夠讓自己覺得滿意：短方法，表意的名字，測試，清晰簡單的結構。并且感覺現代IDE對這種代碼風格也是比較支持的。直到從TWU回來，回到原來的項目。項目進入support階段。其實就是給人家修修bug。關鍵這些bug不是我們之前做的新功能引入的，而是他們的陳年老bug，兩三年前的都有。所以這個階段寫的新代碼少，多數是先讀懂之前的代碼，然后做少許修改。不得不說看這些老代碼看起來真是恨痛苦，很慢。很多超過一屏甚至兩屏的長函數，在我們24寸的大顯示器下。

在抱怨老代碼寫的像一坨的同時，突然覺得，還是自己看代碼的能力有欠缺。一直工作在相對來說比較簡單易懂的代碼庫上，然后去看這些一坨的代碼就好像一個人很整潔很愛衛生的人突然被扔到垃圾堆里，異常難受。而對于常年在垃圾堆里生活的人們早已久聞不覺其臭，甚至還對垃圾堆中的那些病菌產生了抗體。世界沒有那么美好，工作中總是會遇到不盡如人意的代碼庫，無論是做交付還是做咨詢。所以除了要有寫出清晰漂亮代碼的能力外，還要有讀復雜，凌亂的代碼的能力和改造復雜凌亂代碼的能力，也就是我們常說的重構。

復雜代碼可以分成兩種：

一種是受到語言，平臺，庫的限制，使得代碼無法寫的非常簡短和易懂。比如使用純c，沒有很好的語言特性和可用的sdk，使得實現復雜邏輯的時候不可避免的要寫出很長很復雜的代碼。有時短的代碼也不一定清楚，比如在代碼中大量使用組合表達式或者是位運算符，在讓代碼變短的同時，變得更難懂。這些時候通常是處于效率的考慮。

一種是我們有了更高級的語言和其上的大量的框架。如java＋spring＋struts＋hibernate，或者是直接用Ruby on rails，Django等更易用的工具。通常在這些框架下寫程序，是很容易遵循上面提到的讓程序清晰簡單的原則的。如果在這樣的基礎上寫出了讓人摸不著頭腦的代碼，那就完全是程序員的責任了。

現在有種感覺，在層層疊疊的框架下寫程序，就像是搭積木，越來越簡單。底層封裝的越來越嚴實，程序員都像白癡一樣機械的在框架中填寫你想實現的業務邏輯。發明框架的原因是為了讓程序員不再重新創造輪子。但是長期在框架上工作的結果是，大家都不會做輪子了，真正有一天需要你做點不太一樣的輪子的時候，就sb了。

程序員寫代碼的能力是凌駕于語言之上的，是思考問題，抽象問題和用另外一種語言簡潔，有效，清晰地描述問題的能力。我相信一個能寫出優秀c代碼的人通過一段時間對java及其上的一些框架的學習，也能寫出優秀的java代碼。

目前我正在學習各種各樣的框架，平時的工作也是在這些框架上工作，越來越感覺，學習這些新知識的同時，做為一個程序員的基本功也不能放下?？蚣苁呛芎玫臇|西，在提高生產力方面，但是框架讓寫程序變得簡單的同時也會降低對程序員的要求，久而久之，基本功就被荒廢了。如何鍛煉這些基本功？個人認為用最簡單的語言，如c，去做一些算法題是一個不錯的主意；或者不甘做玩積木的小孩兒，看看框架的源碼。其實做為一個計算機專業的學生，這些鍛煉應該是當學生的時候都好好練習過的東西。如果現在發現有所欠缺了，就趕緊補補吧。