1技術債務和童子軍規則

技術債務
當你發現必須在“幹得好”和“幹得快”之間做出抉擇的時候，一般都會選擇“幹得快”，並提醒自己將來再來返工。下一輪迭代自有其新的問題，工作重點轉移到新問題上，老問題還存在。
Martin Fowler把它分成：蓄意和無意
把技術 債務立即記錄到任務卡上，在惡化前償還。
無論你承諾了什麼，都得小心處置，顧及後果，儘快償還你的技術債務吧，否則你會被你的輕率而後悔。


童子軍規則
要讓離開時的營地比進入時更加乾淨
編碼：讓模組check in 的時候比check out的時候更加整潔

團隊把系統當成一個整體來維護，不再“各人自掃門前雪”，團隊互相幫助，互相清理程式碼。
變數可讀性，長函式分割成更短，迴圈依賴，增加一個藉口解耦策略和實現細節。。。。

2.重構前的建議

1.重構程式碼的最佳起點是清理已有的基礎程式碼和基於這些程式碼寫的測試用例
2.避開重寫一切的誘惑
3.逐步增加的小改動勝過一次性的大改動
4.在每次開發迭代後，確保已有的測試用例都通過
5.個人好惡和利己主義不能摻雜到開發中來
6.新技術不是重構的理由
7.要記住人總是會犯錯的

在你重構之前
1.理解當前程式碼的優缺點
2.原有的程式碼都是經多年的測試並實戰過的程式碼，花費時間多
3.逐步反饋資訊來評估改動的對系統的影響，做一些測試
4.不要看不爽就重構
5.如果新的技術框架在功能性，可維護性或生產力上會有顯著提升，可以考慮
6.新的設計未必會比原來的好，多考慮

謹防共享
抽取公共的方法或類的時候，需要考慮清楚，是否是真正的公用，否則會適得其反，更加難以維護

3.編碼標準自動化和持續化

遵守編碼規範
確保程式碼格式一樣，自動執行
靜態程式碼分析工具掃描程式碼
每個人都配置好工具
測試覆蓋率過低，終止構建
程式碼註釋：團隊理解程式碼的含義,對待註釋要對待程式碼一樣來維護

程式碼審查
態度溫和，有建設性建議
每個星期正式的程式碼審查日


編碼標準的自動化
對註釋的一個註釋
程式碼說不清，註釋來補充
程式碼審查
程式碼審查日：2個小時一次，迴圈制模式，讓審查者輪流執掌每一次審查會議，可以讓專家加入進來，可以作為一次團隊的知識分享


自動化
自動化測試：每天和每週末，非工作時間執行（包括效能測試，穩定性測試）
充分利用程式碼分析工具:使用工具發現bug，規範程式碼

4.設計

美在於簡單
易用不是一種能力，為呼叫方考慮，為客戶考慮
瀏覽程式碼，閱讀程式碼的時間
易於檢索
清晰的佈局
緊湊格式（程式碼跟詩一樣）
封裝行為，而不僅僅是狀態
額外的設計
好玩的額外功能，但並無用處
遵守YAGNI原則，現在不用就不要寫
可能會有用，現在就寫，“雪球”會越高越大
系統需求不是隨便新增



柏拉圖：風格之美，和諧、優雅及優美的節奏盡在於簡單
不管系統有多複雜，但每個單獨的組成部分都保持著它的簡潔性，單一職責，方法的功能如同其名稱描述的一樣，
5~10行語句的短方法過於極端，這種是比較難，但我想這種間斷正是我們希望達到的目標

領域語言裡的程式碼
含義在程式碼中體現

易用不是一種能力
關於程式碼佈局的麻煩事
程式設計時間中：花費瀏覽程式碼，閱讀程式碼的時間是多少呢？
封裝行為，而不僅僅是狀態（看下書本中的例子）
程式碼 YAGNI(You aren’t gonna need it 你絕對不會需要它)

5.雜談

使用者需要什麼， 而不是我們提供什麼
責備先自責
不斷學習
有針對性的勤加練習,提升自身的能力
不要在你的測試程式碼裡裝可愛
瞭解你的侷限性，知己知彼
通曉兩門以上程式語言


使用者會怎麼做
當你卡住的時候，你會四處張望，需求幫助；而使用者卡住的時候，他們會縮小他們的注意力範圍，做好使用者體驗
在責備別人之前先檢查自己的程式碼
不斷學習
閱讀書籍，資料
找到一個號導師
利用虛擬世界，網路導師
瞭解你使用的框架和類庫
分享解決一個比較通用的問題方法
分享所學的知識
加入學習小組
參加研討會
學習業務知識
考慮回學校

有針對性的勤加練習,提升自身的能力
不要在你的測試程式碼裡裝可愛
在你的程式碼中，註釋，日誌，測試資料，想想一旦公開出去是否有問題，你會臉紅嗎？
瞭解你的侷限性
通曉兩門以上程式語言
每年學習一門新的語言