最近讀了Bob大叔《程式設計師的職業素養》，文章討論了專業這個詞，程式設計師如何讓別人感覺到專業，對裡面的論點很有同感，所以記錄下看書的心得。
序
文章提到了面試常常問這樣的面試的問題，工作時遇到了哪些困難以及是如何解決的？其實這個問題很多面試官根本不care你的困難到底有多難，更多的是關注你解決問題的過程以及對這個問題的挖掘深度。通過這些可以解讀出你對問題思考深度以及對工作的問題是否保持了足夠的好奇心。
專業
責任感，未測試的功能絕不交付
產品質量，把0 bug作為永恆的追求，單元化測試率達到90%， 不斷的重構程式碼
職業道德，工作時間高效為僱主工作，每週20小時為自己工作
專業領域，設計模式、設計原則、方法、實踐和圖表
業務領域
說不
專業人士敢於說明真相而不屈從權勢，專業人士有勇氣對他們的經理說NO！
如果工期很緊，可以確定哪些功能可以按期提供。
有時候提供太多細節，只會招致更多的微觀管理。
許諾嘗試，其實是在確保能夠成功，如果沒有達到預期，那麼你就失敗了。
快就是慢，打破這些紀律和原則，如果不好好設計程式碼，後面會越來越慢，直至專案失敗
說是
識別缺乏承諾的徵兆，需要、應當、希望、但願
真正的承諾要有具體的日期，xxx天完成， 周幾完成
承諾不能完成的原因，依賴其他的模組，任務太多真的搞不完（只能盡力達到自己的目標），不受控制的風險
（越早丟擲越好，可以用另一個承諾代替現在的承諾）
編碼
第一點是實現你需要解決的問題
第二點與現有系統的關係，不破壞現有系統的功能
第三點讓其他程式設計師讀懂你的程式
軟體開發是一場馬拉松，而不是短跑衝刺，需要儲存體力和穩定節奏感來取勝
TDD 測試驅動開發
第一點在編好失敗單元測試之前，不要編寫任何產品程式碼
第二點只要一個單元測試失敗，就不再編寫任何單元測試程式碼，無法編譯也是一種失敗情況
第三點產品程式碼恰好能夠讓失敗的單元測試成功通過即可，不要多寫
TDD優勢，功能正常，易於重構，設計解耦
練習
驗收測試
測試策略
時間管理
拒絕不必要的會議
沒有意義的會議選擇合適的時機離席
緊跟會議的議程和目標
站立會議，昨天干了啥，今天準備幹啥，遇到啥問題
時間拆分和番茄工作法
避免優先順序錯亂
預估
專業人員能夠區分出預估和承諾，只有在確切知道可以完成的前提下他們才會進行承諾。
過於樂觀的專案評估，它們最終花的時間是預估的3到5倍。
不管嘗試加班的進度的壓力有多大，專業開發人員都應該謹慎的設定合理的預估值。
大任務拆分小任務進行預估，可以忽略小任務的預估錯誤率。
壓力
避免壓力，不過沒有把握的承諾、程式碼保持整潔、遵循開發紀律
應對壓力，保持平靜放鬆、尋找團隊幫助、堅持開發紀律、結對程式設計