讀《軟體之道》的筆記

挖個坑埋點土，數個一二三四五。

ch 6

能確切定義優秀的軟體開發者嗎？

如果可以，能找到可靠有效的方式確定一名開發人員比其他人優秀嗎？

• 如何辨識優秀的程式設計師？

• 程式設計師身上的哪些因素使其有優秀的程式設計表現？經驗？個性？測智商？結對和團隊工作時，這些問題的答案又是怎樣？

• 什麼是優秀的程式設計表現？是單位時間寫程式碼最多還是不管耗時程式碼質量最高，無論質量是如何定義的？

ch 16

因為沒有留下記錄，

大量使用談話作為溝通方式會不會對敏捷團隊的長遠發展造成影響還有待研究。

存在於團隊集體記憶中的資訊，怎樣權衡是否文件化？

ch 18

code review要不要做？怎麼做？是獨立進行小量審查？還是開會？

拍腦袋在團隊裡推一個方法、工具、流程、制度都要謹慎，如果自己都不能堅持、自己很難幫助團隊堅持，多好的念頭都還是壓住吧。

人們對自己陌生的事物往往有恐懼，因為恐懼所以抗拒，因為抗拒所以找出各種理由。當然沒有什麼東西是十全十美無可挑剔的。推行者自己要堅持，你不堅持就沒人堅持了。還要幫助大家1）讓事情儘可能簡單方便，2）把事情做對，看到實實在在的效果。

ch 26

新手（通常也是團隊新人）的很多問題有相同根源，就是溝通的不順暢和社交上的稚嫩。

一個好的導師並不只是簡單地跟新人介紹文件、工具、流程、隊員等，而是以身作則，親身為新人展示正確的行為和方法。