1. 做事

指責不會修復bug鱼响。把矛頭對準解決問題的辦法，而不是人组底。這是真正有用處的正面效應丈积。

• 勇于承認自己不知道答案，這會讓人感覺放心债鸡。一個重大的錯誤應當為當做是一次學習而不是指責他人的機會江滨。
• 如果一個團隊成員的行為一再傷害了團隊，我們必須要求他離開厌均。
• 如果大部分團隊成員（特別是開發(fā)領導者）的行為都不職業(yè)唬滑，并且他們對團隊目標都不感興趣，你就應該主動從團隊中離開棺弊，尋找更適合自己發(fā)展的團隊晶密。

2. 欲速則不達

不要墜入快速的簡單修復之中。要投入時間和精力保持代碼的整潔模她、敞亮稻艰。

• 一次又一次的快速修復，每一次都不探究問題的根源侈净，久而久之就形成了一個危險的沼澤地尊勿，最終會吞噬整個項目的生命僧凤。
• 在工作壓力之下，不去深入了解真正的問題以及可能的后果元扔， 就快速的修改代碼躯保，這樣只是解決表面的問題，最終會引發(fā)大問題澎语。

3. 對事不對人

對事不對人途事。讓我們驕傲的應該是解決了問題，而不是比較出誰的注意更好擅羞。

4. 排除萬難盯孙，奮勇前進

做正確的事。要誠實祟滴，要有勇氣去說出實情振惰。有時，這樣做很困難垄懂，所以我們要有足夠的勇氣骑晶。

• 看到糟糕的代碼，不要只是嚷嚷抱怨草慧。相反桶蛔，你應該重寫這些代碼，并比較重寫前后的優(yōu)缺點漫谷。列出重寫理由仔雷，會有助于你的老板（以及同事）認清當前形勢，幫助他們的到正確的解決方案舔示。

5. 跟蹤變化

跟蹤技術變化碟婆。你不需要精通所有技術，但需要清楚和知道行業(yè)的動向惕稻，從而規(guī)劃你的項目和職業(yè)生涯竖共。

• 迭代和增量式的學習。每天計劃用一段時間來學習新技術俺祠。
• 了解最新行情公给。
• 如饑似渴的閱讀。

6. 對團隊投資

提供你和團隊學習的更好平臺蜘渣。通過午餐會議可以增進每個人的知識和技能淌铐，并幫助大家在一起進行溝通交流。喚起人們對技術和技巧的激情蔫缸，將會對項目大有裨益腿准。

7. 懂得丟棄

學習新的東西，丟棄舊的東西捂龄。在學習一門新技術的時候释涛，要丟棄會阻止你前進的舊習慣加叁。畢竟倦沧，騎車要比馬車車廂強得多唇撬。

8. 打破沙鍋問到底

不停的問為什么。不能只滿足于別人告訴你的表面現象展融。要不停的提問直到你明白問題的根源窖认。

9. 把握開發(fā)的節(jié)奏

解決任務，在事情變得一團糟之前告希。保持事件之間穩(wěn)定重復的間隔扑浸，更容易解決常見的重復任務。

• 以固定燕偶、有規(guī)律的長度運行迭代喝噪。

10. 讓客戶做決定

讓你的客戶作決定。開發(fā)者指么、經理或者業(yè)務分析師不應該做業(yè)務方面的決定酝惧。用業(yè)務負責人能夠理解的語言，向他們詳細解釋遇到的問題伯诬，并讓他們做決定晚唇。

11. 讓設計 指導 而不是 操縱 開發(fā)

好設計是一張地圖，它也會進化盗似。設計指引你向正確的方向前進哩陕，它不是殖民地，它不應該標識具體的路線赫舒。你不要被設計（或者設計師）操縱悍及。

12. 合理使用技術

根據需要選擇技術。首先決定什么是你需要的接癌，接著為這些具體的問題評估使用技術并鸵。對任何要使用的技術，多問一些挑剔的問題扔涧，并真實的做出回答园担。

• 這個技術框架真能解決這個問題嗎？
• 你將會被他拴住嗎枯夜？
• 維護成本是多少弯汰？

13. 保持可以發(fā)布

保持你的項目時刻可以發(fā)布。保證你的系統隨時可以編譯湖雹、運行咏闪、測試并立即部署。

14. 提早集成摔吏，頻繁集成

提早集成鸽嫂，頻繁集成纵装。代碼集成是主要的風險來源。要想規(guī)避這個風險据某，只有提早集成橡娄，持續(xù)而有規(guī)律的進行集成。

15. 提早實現自動化部署

一開始就實現自動化部署應用癣籽。

16. 使用演示獲得頻繁反饋

清晰可見的開發(fā)挽唉。在開發(fā)的時候，要保持應用可見（而且客戶心中也要了解）筷狼。每隔一周或兩周瓶籽，邀請所有的客戶，給他們演示最新完成的功能埂材，積極獲得他們的反饋塑顺。

17. 使用短迭代，增量發(fā)布

增量開發(fā)俏险。發(fā)布帶有最小卻可用功能塊的產品严拒。每個增量開發(fā)中，使用1~4周左右迭代周期寡喝。

18. 固定的價格就意味著背叛承諾

基于真實工作的評估糙俗。讓團隊和客戶一起，真正地在當前項目中工作预鬓，做具體實際的評估巧骚。有客戶控制他們用的功能和預算。

19. 守護天使

使用自動化的單元測試格二。

20. 先用它再實現它

先用它再實現它劈彪。將TDD（Test Driven Development，測試驅動開發(fā)）作為設計工具顶猜，它會為你帶來更簡單更有實效的設計沧奴。

21. 不同環(huán)境，就有不同問題

不同環(huán)境长窄，就有不同問題滔吠。使用持續(xù)集成工具，在每一種支持的平臺和環(huán)境中運行單元測試挠日。要積極的尋找問題疮绷，而不是等問題來找你。

22.自動驗收測試

為核心業(yè)務邏輯創(chuàng)建測試嚣潜。讓你的客戶單獨驗證這些測試冬骚，要讓它們像一般的測試一樣可以自動運行。

23.度量真實的進度

度量剩下的工作量。不要用不恰當的度量來欺騙自己或者團隊只冻。要評估那些需要完成的待辦事項庇麦。

• 用小時來評估工作量。

24. 傾聽用戶的聲音

每一個抱怨背后都隱藏了一個事實喜德。找出真相山橄，修復真正的問題。

• 沒有愚蠢的用戶住诸。
• 只有愚蠢驾胆、自大的開發(fā)人員涣澡。

25. 代碼要清晰的表達意圖

要編寫清晰而不是討巧的代碼贱呐。向代碼閱讀者明確表明你的意圖∪牍穑可讀性差的代碼一點都不聰明奄薇。

• 應該讓自己或團隊的其他任何人，可以讀懂自己一年前寫的代碼抗愁，而且只讀一遍就知道它的運行機制馁蒂。

26. 用代碼溝通

用注釋溝通。使用細心選擇的蜘腌、有意義的命名沫屡。用注釋描述代碼意圖和約束。注釋不能替代優(yōu)秀的代碼撮珠。

27. 動態(tài)評估取舍

動態(tài)評估權衡沮脖。考慮性能芯急、便利性勺届、生產力、成本和上市時間娶耍。如果性能表現足夠了免姿，就將注意力放在其他因素上。不要為了感覺上的性能提升或者設計的優(yōu)雅榕酒，而降設計復雜化胚膊。

28. 增量式編程

在很短的編輯/構建/測試循環(huán)中編寫代碼。這要比花費長時間僅僅做編寫代碼的工作好得多想鹰∥赏瘢可以創(chuàng)建更加清晰、簡單杖挣、易于維護的代碼肩榕。

29. 保持簡單

開發(fā)可以工作的、最簡單的解決方案。除非有不可辯駁的原因株汉，否則不要使用模式筐乳、原則和高難度技術之類的東西。

• 當你覺得所編寫的代碼沒有一行是多余的乔妈，并且仍能交付全部的功能時蝙云，這種感覺就對了。這樣的代碼容易理解和改正路召。

30. 編寫內聚的代碼

讓類的功能盡量集中勃刨，讓組件盡量小。要避免創(chuàng)建很大的類或組件股淡，也不要創(chuàng)建無所不包的大雜燴類身隐。

31. 告知，不要詢問

告知唯灵，不要詢問贾铝。不要搶別的對象或是組件的工作。告訴它做什么埠帕，然后盯著自己的職責就好了垢揩。

32.根據契約進行替換

通過替換代碼來擴展系統。通過替換遵循接口契約的類敛瓷，來添加并改進功能特性叁巨。要多使用委托而不是繼承。

33. 記錄解決問題的日志

維護一個問題及其解決方案的日志呐籽。保留解決方案是修復問題過程的一部分锋勺，以后發(fā)生相同或類似的問題時，就可以很快找到并使用了绝淡。

• 要記錄團隊做出一個重要決策的原因宙刘。否則，在6~9個月后牢酵，想再重新恢復決策過程的時候悬包，這些細節(jié)就很難再記得了，很容易發(fā)生相互指責的情形馍乙。

34. 警告就是錯誤

將警告視為錯誤布近。簽入帶有警告的代碼，就跟簽入有錯誤或者沒有通過測試的代碼一樣丝格，都是極差的做法撑瞧。簽入構建工具中的代碼不應該產生任何警告信息。

35.對問題各個擊破

對問題各個擊破显蝌。在解決問題時预伺，要將問題域與其周邊隔離開，特別是在大型應用中。

36. 報告所有的異常

處理或向上傳遞所有的異常酬诀。不要將他們壓制不管脏嚷，就算是臨時這樣做也不行。在寫代碼時要估計到會發(fā)生的問題瞒御。

37. 提供有用的錯誤信息

展示有用的錯誤信息父叙。提供更易于查找錯誤細節(jié)的方式。發(fā)生問題時肴裙，要展示出竟可能多的支持細節(jié)趾唱，不過別讓用戶陷入其中。

38. 定期安排會面時間

使用立會蜻懦。立會可以讓團隊達成共識甜癞。保證會議短小精悍不跑題。

39. 架構師必須寫代碼

優(yōu)秀的設計從積極的程序員那里開始演進阻肩。積極的編程可以帶來深入的理解带欢。不要使用不愿意編程的架構師——不知道系統的真實情況运授，是無法展開設計的烤惊。

40. 實行代碼集體所有制

要強調代碼的集體所有制。讓開發(fā)人員輪換完成體統不同領域中不同模塊的不同任務吁朦。

41. 成為指導者

成為指導者柒室。分享自己的知識很有趣——付出的同時便有收獲。還可以激勵別人獲得更好的成果逗宜，而且提升了整個團隊的實力雄右。

• 你會感到給予別人教導，也是提升自己學時的一種方式纺讲，并且其他人亦開始相信你可以幫助他們擂仍。

42. 允許大家自己想辦法

給別人解決問題的機會。指給他們正確的方向熬甚，而不是直接提供解決方案逢渔。每個人都能從中學到不少東西。

• 用問題來回答問題乡括，可以引導提問的人走上正確的道路肃廓。

43. 準備好后再共享代碼

準備好后再共享代碼。絕不要提交尚未完成的代碼诲泌。故意簽入編譯未通過或這個沒有通過單元測試的的代碼盲赊，對項目來說，應被視作玩忽職守的犯罪行為敷扫。

44. 做代碼復查

復查所有的代碼哀蘑。對于提升代碼質量和降低錯誤率來說，代碼復查是無價之寶。如果以正確的方式進行绘迁，復查可以產生非常實用而高效的成果惨险。要讓不同的開發(fā)人員在每個任務完成后復查代碼。

45. 積極通報進展與問題

及時通報進展與問題脊髓。發(fā)布進展狀況辫愉、新的想法和目前正在關注的主題。不要等著別人來問項目狀態(tài)如何将硝。