高效程序員的45個習慣讀書筆記

「接納別人的想法，而不是盲目接受，這是受過教育的頭腦的標誌。」                  

                                                  — 亞里士多德 

 

態度篇:
一、作實事
   少抱怨和牢騷，少指責他人；找出問題所在，想辦法解決；用於承擔責任
二、欲速則不達
   權宜之計不能長久；代碼質量相當重要（持續重構）
三、對事不對人
   就事論事
四、排除萬難，奮勇前進
   勇氣是克服困難的惟一方法

 

學習篇
五、跟蹤變化
   新技術層出不窮，堅持學習；參與技術活動，多與人交流；把握技術大趨勢
六、對團隊投資
   打造學習型團隊
七、懂得丟棄
   老套路和技術，該丟則丟
八、打破沙鍋問到底
   多問爲何
九、把握開發節奏
   控制好時間，養成好習慣，儘可能不要加班

 

開發流程篇
十、讓客戶作決定
    用戶必須在現場，傾聽他們的聲音，對業務最重要的決策他們說了算
十一、讓設計指導而不是操縱開發
    設計是前進的地圖，指引的是方向，而不是目的自己。設計的詳略程度應該適當
十二、合理地使用技術
    根據須要而不是其餘因素選擇技術。對各類可選技術方案進行嚴格篩選，真誠面對各類問題
1三、讓應用隨時均可以發佈
    經過持續集成和版本管理，隨時能夠編譯、運行甚至部署應用
1四、提前集成，頻繁集成
    集成有風險，要儘早儘可能多地集成
1五、提前實現自動化部署
1六、使用演示得到頻繁反饋
1七、使用短迭代，增量發佈
1八、固訂價格就意味着背叛
    估算應該基於實際的工做而變化

 

工具篇
1九、守護天使
    自動化測試是你的守護天使
20、先用它再實現它
    測試驅動開發
2一、不一樣環境，就有不一樣問題
    要重視多平臺（跨平臺）問題
2二、自動驗收測試
2三、度量真實的進度
    在工做量估算上，不要自欺欺人
2四、傾聽用戶的聲音
    每一聲抱怨都隱藏着寶貴的真理

 

編程篇
2五、代碼要清晰地表達意圖
    代碼是給人讀的，不要耍小聰明
2六、用代碼溝通
    註釋的藝術
2七、動態地進行取捨
    沒有最佳解決方案，各類目標不可能作到面面俱到，關注對用戶重要的需求
2八、增量式編程
    寫一點代碼就構建、測試、重構、休息。讓代碼乾淨利落
2九、儘可能簡單
    寧簡勿繁。複雜必須有充足的理由。
30、編寫內聚的代碼
    類和組件應該足夠小，任務單一
3一、告知，不要詢問
    多用消息傳遞，少用函數調用
3二、根據契約進行替換
    委託每每優於繼承

 

調試篇
3三、記錄問題解決日誌
    不要再同一地方摔倒兩次。錯誤時最寶貴的財富。

        錯誤歸檔記錄信息應該包括：
     . 問題發生日期
     . 問題簡述
     . 解決方案詳述
     . 引用文章或網址，以提供更多細節或相關信息
     . 任何代碼片斷、設置或對話框的截屏
3四、警告就是錯誤
    忽視編譯器的警告可能鑄成大錯
3五、對問題各個擊破
    分而治之
3六、報告全部的異常
3七、提供有用的錯誤信息
    稍微多花點心思編寫錯誤信息

團隊協做篇
3八、按期安排會面時間
    常開會，開短會（站立式會議）
3九、架構師必須寫代碼
    不寫代碼的架構師不是好架構師。好的架構師來自實際編程，編程能夠深刻的理解代碼
40、實行代碼集體全部制
    讓開發人員在系統不一樣區域中不一樣的模塊和任務之間輪崗
4一、成爲指導者
    教學相長。分享
4二、讓你們本身想辦法
    指引方向，而不是直接提解決方案
4三、準備好後再共享代碼
    不要提交沒法編譯或者沒有經過單元測試的代碼
4四、作代碼複查
    複查對提升代碼質量、減小錯誤極爲重要
4五、及時通報進展與問題

 

另外，豬和雞的比喻蠻有趣的！

代碼複查checklist:
全部異常處理程序不容許爲空
輸入參數是否檢測了有效性
代碼可讀性
是否有明顯錯誤
是否存在重複代碼