態度決定一切
1、做事
當出現問題，BUG的時候不要抱怨，指責，最終要的是解決問題。
2、欲速則不達
不要墜入快速的簡單修復之中，要投入時間和精力理解它，並使代碼保持整潔、敞亮。
不要孤立的編碼，花時間閱讀其他人的代碼。
使用單元測試。
3、對事不對人
不要一味否定別人的意見，要提出自己的看法。
只有更好，沒有最好。
不帶任何情緒並不是盲目接受所有的觀點。用合適的詞和理由去解釋爲什麼不贊同，並提出明確的問題。
4、排除萬難，奮勇前進
如果發現項目中代碼有問題，向其他成員反饋問題，並且想辦法重寫它。
學無止境
5、跟蹤變化
迭代和增量式的學習：記錄下想學的東西——當聽到不熟悉的術語或短語時，簡要的記錄，然後有計劃的深入學習。
瞭解最新行情：選擇一些公認的優秀技術博客，瞭解頂尖博客作者們在關注什麼。
參加本地的用戶組活動。
參加研討會議。
如飢似渴的閱讀：好書，期刊雜誌等。
6、對團隊投資
提供你和團隊更好的學習平臺：可以搞一些類似午餐會議，提供一個團隊分享的平臺
不要侷限於純技術的主題
7、懂得丟棄
學習新的東西，丟棄舊的東西。
要果斷丟棄舊習慣，一味遵循過時的舊習慣會危害你的職業生涯。
不是完全忘記舊的習慣，而是在使用適當的技術時才使用它。
對所使用的語言，要總結熟悉它的特性，並比較這些特性在新語言或新版本中有什麼不同。
8、打破砂鍋問到底
要不停地問爲什麼，直到明白事情的本質。
9、把握開發節奏
每天下班的時候提交所有的工作，包括測試代碼。第二天開始新的內容。
每天固定時間固定地點的站立會議。
最大的節拍就是迭代時間，一般是1-4周。
項目開發需要一致和穩定的節奏。編輯，運行測試，代碼複審，一致的迭代，然後發佈。
交付用戶想要的軟件
10、讓客戶做決定
開發、經理、或者業務分析師不應該做業務方面的決定。用業務負責人能夠理解的語言，向他們詳細解釋遇到的問題，由他們做決定。
不要用低級別或沒有價值的問題打擾業務人員。
11、讓設計指導而不是操縱開發
好的設計應該是正確的，而不是精確的。設計不應該涉及細節。
做一些類層次的設計：類名，職責，協作者。
白板，草圖，便利貼是非常好的設計工具。
12、合理的使用技術
根據需要選擇技術。
新技術就像新工具，它可以幫助你更好的工作，它自己不應該成爲你的工作。
不要開發那些容易下載到的東西。
13、保持可以發佈
提交代碼之前: 在本地運行測試;檢出最新的代碼;提交代碼
可以弄一個持續集成系統.
14、提早集成，頻繁集成
決不要做大爆炸式的集成。
集成也不要太頻繁，一天幾次就差不多了。
15、提早實現自動化部署
系統安裝、部署應該簡單、可靠及可重複。
16、使用演示獲得頻繁反饋
需求就像是流動的油墨。
定期地，如一個迭代的結束，就與客戶會晤，並演示你已經完成的功能特性。
維護項目術語表。
會晤也不要太頻繁，只有在你做完一些東西可以給客戶演示的時候 ，才進行。
17、使用迭代，增量發佈
給我一份詳細的長期計劃，我就給你一個註定完蛋的項目。 （Show me a detail long-term plan, and I'll show you a project that's doomed.）
確定產品可用的核心功能，然後把它們放在生產環境中，越早交到用戶的手裏越好。
發佈帶有最小卻可用功能塊的產品，每個增量開發中，使用1-4周左右迭代時間。
18、固定的價格就意味着背叛承諾
構建系統最初、小的和有用的部分，之後再根據功能迭代，每個迭代給客戶選擇繼續還是取消合同。每個迭代的費用還是相對可以評估的。並且客戶承擔更低的風險。
敏捷反饋
19、守護天使
編寫能產生反饋的代碼。-》自動化單元測試。
在後臺架設一臺構建機器，不斷獲得最新版本的源代碼，然後編譯代碼，運行單元測試，有錯誤及時通知。
如果單元測試到位，可以隨意重構代碼。
簡單屬性的訪問方法和價值不大的方法是不值得寫單元測試的。
20、先用它再實現它
編程之前，先寫測試。測試驅動開發
使你站在代碼用戶的角度。
有助於消除過度的設計。
好的設計並不意味着需要更多的類。
只有在具體理由的時候纔開始編碼，你可以專注於接口設計，而不會被很多實現的細節干擾。
測試優先和提交代碼之前的測試要區分開來，測試先行幫助改進設計，提交代碼之前還需要進行測試。
21、不同環境，就有不同問題
使用自動化在多個平臺上運行測試。
22、自動驗收測試
爲核心的業務邏輯創建測試。讓客戶單獨驗證這些測試，要讓他們像一般的測試一樣可以自動運行。
23、度量真實的進度
專注於你的方向。
在真正完成一項任務時，要清楚知道完成這個任務真正花費的時間。
使用代辦事項。
度量剩下的工作量。要評估那些需要完成的代辦事項。
24、傾聽用戶的聲音
沒有給用戶很友好的提示。
每一個抱怨的背後都隱藏了一個事實，需要努力找出背後真正的問題。
如果代碼問題解決不了，可以用修改文檔和培訓來解決。
敏捷編碼
25、代碼要清晰的表達意圖
開發代碼時，應該更注重可讀性，而不是隻圖自己方便。
代碼必須說出意圖，而且富有表達力。
26、用代碼溝通
建立代碼文檔：利用代碼本身；利用註釋溝通代碼之外的問題。
不需要註釋來包裹你的代碼。
使用細心挑選的名稱和清晰的執行路徑，代碼幾乎不需要註釋。
對於類中的方法，可能要說明下面的信息： 目的；需求；承諾；異常。
解釋代碼做了什麼的註釋用處不那麼大。註釋要說明爲什麼這樣寫代碼。
27、動態評估取捨
強調性能的重要性情有可原。但如果性能已經足夠好了，就沒有必要再花時間去投入了。
沒有最佳解決方案。
過早的優化是萬惡之源。
28、增量式編程
它可以精煉並結構化你的代碼。
會使你傾向於創建更小的方法和更內聚性的類。
持續做一些細小而有用的事情，而不是做一段長時間的編程或重構。
在很短的編輯/構建/測試循環中編寫代碼。
要想重構代碼一樣重構你的測試，而且要經常重構測試。
29、保持簡單
不要被迫過分設計，也不要將代碼過分複雜化。
開發人員應該爲自己創建一個簡單並且可用的設計而驕傲。
簡單不是簡陋。
不要盲目使用模式、原則和高難度技術之類的東西。
當你覺得代碼中沒有一行是多餘的，並且仍能交付全部的功能，這種感覺就對了。
30、編寫內聚的代碼
組件中各個類的功能類似，且功能緊密相關，這就是組件的內聚性。
類中的方法和屬性共同完成了一個或一系列緊密相關的功能，這就是類的內聚性。
MVC模式分離展示邏輯、控制器和模型，它可以讓開發人員獲得更高的內聚性。
內聚性會影響一個組件的可重用性。
讓類的功能儘量集中，讓組件儘量小。