http://jianchen.iteye.com/blog/695314
2010
之前主管推薦過這本書，主管買了幾本，20多個同事大家共享著看。端午節(jié)放假期間去書店溜達了下，看看價格也不貴，才35塊，就買了。沖動的是同時買了《重構-改善既有既有代碼的設計》這本書。今天在卓越上看到便宜17塊多。覺得是好書就本著收藏的想法，本已所剩不多的錢袋又多了一筆開銷。這個月剩下的日子花錢可得悠著點了。
這兩天迅速的把《高效程序員的45個習慣》這本書翻完了。這本書讀起來還是挺流暢的，翻譯的質量不錯。將一些敏捷的理念和時間款款道來。寫的還是很好的，不是那么教條，讀起來輕松愉快。說實話，很多概念在沒看這本書之前就有所了解了?？傮w感受是，提出的方法實踐還是靠譜的，如果真能說實施起來，對平時的工作絕對是有益處的。
真正的難點是實施起來不太容易。但在敏捷越發(fā)得到認可的今天，公司里已近有些項目團隊開始進行實踐，雖然不是很成功，但是終歸是個開始，會向真正的敏捷靠攏的。
書中提出了45個習慣，抑或是手段。從團隊的管理，到個人的提升，以及項目的完成，多角度的進行闡述。
1， 做事
強調做事的重要性，每當出了問題，不是找出導致出現(xiàn)問題的人是誰去抱怨，打擊對方，優(yōu)先做的是大家共同將該問題解決。
2， 欲速則不達
在實際的工作中，一個新手接到一個問題，面對不熟悉的代碼，往往會迅速的定位問題，然后加上自己自認為可以解決的方法，而沒能很好的理解上下文，就貿然加上相關代碼，
可能看起來問題的確得到了解決。之前就討論過這個問題，一個項目為什么代碼越寫越爛。往往是不敢動被人的代碼，我們需要的是一種勇氣，敢于跟老大提出，給我一周的時間，將這段代碼重構。如此每個人都能做到，代碼會越來越好，而不會smell bad。
3， 對事不對人
面對比起來無論是經驗還是實際技能上多遠不如你的人，需要保持一顆謙遜的心。在某個會議上，他提出的問題和想法也許會很愚蠢，但是沒有必要嘲笑別人。想想看，自己當年何嘗不是這樣過來的呢。況且他的想法未必沒有道理，看起來很簡單的問題往往會促使你做出思考，得到新的結論。打擊別人讓自己顯得很聰明，絕對沒有必要。這樣只會讓你的同事感覺很氣餒，以后他發(fā)言就不會很積極了。你要做的是鼓勵他，跟他積極的探討，久而久之，他就會成長起來。
4， 注重團隊的投資。
內部經常性的交流分享，可以比較有效的提升大家的技能，激發(fā)大家的學習興趣?！叭诵?，必有我?guī)煛?，別人總有你可以學習的地方?？梢宰寛F隊成員定期的做分享，技術，人生，主題不限。分享者會積極的準備，強化他這方面的知識，提高他的演講能力。要知道，經常跟代碼打交道的人往往沉默吶言，不善于溝通。還可以增進團隊的合作氛圍。哎呀，好處太多了。新人前期主要是聽別人的分享，慢慢的可以自己分享一些東西出來，已分享促進學習，良性循環(huán)。
5， 敏捷強調小步前進，增量迭代式開發(fā)。
面對用戶善變的需求，需要的是經常跟用戶溝通，讓用戶參與進來，讓用戶做決定，你需要做的是幫他們分析這樣做的好處，以及不這樣做帶來的后果，進行多方面的比較。讓用戶深刻的體會到，你是跟他們一伙的。呵呵。迭代周期中，定期的發(fā)布版本，給用戶進行demo演示，讓客戶看到你的成果，頻繁獲得反饋，以進一步確認需求，一步一步的接近用戶想要的結果。
6， 敏捷強調不能過分設計。
前期的設計只要在戰(zhàn)略上正確即可。真正詳細的設計是面對開發(fā)過程中需要解決的問題進行的戰(zhàn)術調整。書中提出的“讓設計指導開發(fā)而不是操作開發(fā)”，與后面的“架構師必須寫代碼”，因為前期的設計往往無法預料到實際出現(xiàn)的問題。如果一開始就定死了代碼的設計，讓一群代碼編寫人員豈不很無聊。這樣可以在每次迭代中大家集體參與設計，真正得到滿足當前需要的最好的設計方案。我在之前參與的項目中，每個人負責相應的模塊，自己設計自己的，雖然滿足要求，但是未必是最好的，如果幾個人共同參與，一方面可以提升設計的質量，還可以提高成員的設計能力。同是大家都能了解對方模塊的設計理念（因為我也參與了），有書中后面提到“代碼共同所有制”有異曲同工之妙。這樣任何一個人都可以完全接手別人寫的代碼，這樣后期的維護成本不會因為某個成員不在而幾何級的增加。結合代碼復審，一個人可以把一段代碼發(fā)給大家，讓大家?guī)兔纯磳懙氖欠裼袉栴}。當然根據(jù)實際情況，可以每周花固定的時間大家做在一起探討。面不要鋪的太寬，選取比較核心或有相關人員提出的代碼就可以了。
7， 對于開發(fā)人員，也提出了比較好的實踐指導。
別對警告視而不見，覺得不影響程序的運行。將警告當做錯誤，力求沒有警告。項目中經?？吹轿词褂梅盒偷木?，未使用的局部變量等警告，雖然你的程序可以跑，但是代碼的質量不能算高。真正的編程人員不容許代碼存在壞的味道。自己寫的代碼就是自己的作品，一個人的臉面，力求讓別人覺得你的代碼親切，覺得似曾相識，一下看懂你這個“人”，了解你這個“人”。代碼要清晰的表達意圖，注釋不需要太多，敏捷追求的就是代碼即文檔。程序員間用代碼可以輕松的溝通，那才厲害。具體的有很多良好實踐：增量式編程，保持簡單，編寫內聚的代碼，告知對方，不需要詢問，根據(jù)契約進行替換。
8， 越來越多的人認可單元測試的重要性。
但是做好單元測試卻不是那么容易的事情。我自己在寫代碼的時候，往往就覺得寫單元測試，造數(shù)據(jù)很麻煩。還好現(xiàn)在有很多開源的框架可以利用，很大程度上減輕的工作量。單元測試不應該是一次性的，良好的單元測試可以作為代碼文檔。測試驅動開發(fā)，這個有點高級，通過一個個失敗的測試，不斷的編寫代碼，完善自己的設計。TDD暫時還沒見到比較好的時間，但是基本的單元測試還是寫的比較多了。對象之間的依賴可以用mock對象解決，數(shù)據(jù)庫層，web層的代碼都可已進行相應的測試了，編寫測試是項目的成本，前期自己的代碼會寫的比較慢，但是越往后，就越會發(fā)現(xiàn)些單元測試的好處。需要修改代碼的時候，跑一下單元測試，如果出現(xiàn)了紅條，迅速的定位問題，可以明顯的提高效率。對于一個新接觸這段代碼的人來說，單元測試同樣會提供很大的幫助，他可以輕松的了解代碼的邏輯，需要注意的地方。
9， 提倡比較高頻率的提交代碼，但是代碼必須是準備好的。
不能因為你提交的代碼導致程序無法編譯，或者報錯導致別人無法繼續(xù)工作。所以就和上面的單元測試有關系了，代碼必須自己本地自測通過后再提交。提交需要單元測試卻沒做的代碼是不負責任的行為。這一點我們要堅決抵制。
10，不得不提的還有持續(xù)集成。
自動構建，跑單元測試，失敗后立即通知，迅速發(fā)現(xiàn)問題。像hudson持續(xù)集成平臺，提供單元測試的覆蓋率報告等其他有用信息。要提早集成，不要大爆炸式的最后集成。當早期集成的時候，你會看到系統(tǒng)之間的交互和影響，就可估算他們之間通信和共享的信息數(shù)據(jù)。代碼提交后自動的構建部署，不得不說這樣很酷。一切都幫你搞定，你需要做的只是收到報告即可。成功的報告當然很爽，失敗也沒關系，因為目前一切都可控，影響范圍不大。
作者用幾句歌訣簡明的進行了概述：
迭代開發(fā)，價值優(yōu)先
分解任務，真實進度
站立會議，交流通暢
用戶參與，調整方向
結對編程，代碼質量
測試驅動，安全可靠
持續(xù)集成，盡早反饋
自動部署，一鍵安裝
定期回顧，持續(xù)改進
不斷學習，提高能力
看完這本書對敏捷的理解貌似不是很多，就是感覺對你書中的觀點挺贊同的，好像理所應當這么做似的?，F(xiàn)在公司里QA已近慢慢的在推這些事情了。包括現(xiàn)在的代碼質量管理，使用類似findbug，checkstyle之類的工具進行簡單的改進。要真正的把敏捷搞好，將項目的質量做好，首先要做的是必須大家認可才行，在大家支持的情況下去做這件事就會比較順利。之前聽過scrum的分享，大概的了解的一些新鮮詞語。什么sprint，backlog等。等看完《輕松scrum之旅----敏捷開發(fā)故事》，我想會對敏捷有更多的認識和理解吧。
聯(lián)系客服
