[閱讀筆記] 97 Things Every Programmer Should Know (2/2)

1. API 設計的黃金準則是：只為你開發的API 編寫測試是不夠的；你必須為使用API 的程式編寫單元測試。你必須親身體驗，一旦你體驗過了，就可以面對每一種設計挑戰
2. 專心在專案上，尋找聰明的解決方案來盡可能做出貢獻，提升你的技巧，反省你所做的，然後調整你的做法。別工作的像在籠子裡跑的倉鼠，每週工作超過60個小時是不明智的。要用專業的方式去做：準備、實現、觀察、反省與改變
3. 一份好的bug report 需要包含三件事情
1. 如何重現bug 以及出現的頻率
2. 預期原本應該要發生什麼事情
3. 實際上發生什麼事情
4. IDE 工具的存在是為了讓開發更容易，並增進程式設計師的生產力。但是有時候妳應該掀開引擎蓋，了解你的IDE 為你做了什麼，最好的方法就是學習command-line tools。之後回過頭來使用IDE 就會更了解他正在為你做什麼，以及如何控制建置的過程。
5. 評估、目標和承諾是彼此獨立的。但是，目標和承諾是建立在可靠的評估之上。軟體評估的主要目的並非預測專案的成果，而是為了判別專案的目標能否實現，讓專案得以掌控
6. 評估時程的用意是為了使適當的專案管理與規劃成為可能，允許專案的利害關係人將於實現目標做出承諾
7. 專案經理常對程式設計師要求的不是一個評估的時程，而是要對管理者內心不確定的目標做出承諾
8. 一個好的interface 應是容易被正確的使用、難以被誤用。故你必須要事先預想到並避免使用者可能犯的錯誤，並觀察早期釋出的interface 如何被誤用並修改interface ，避免發生同樣錯誤
9. 雖然在一般遇到的案例裡，使用 if - then - else 比多型更實用些，但絕大多數用 polymorphism 的寫作風格會讓程式碼更精簡、更易讀，且更少脆弱的程式碼。所以在我們的程式碼裡，要是錯過使用 polymorphism 的機會，便會逐漸增加  if - then - else 敘述句的數量。試試 command  pattern 吧
10. deployment的環境資訊也要保持在版本控制之下。沒有比破壞一個環境設定，卻沒辦法知道哪裡被改變過還糟。環境資訊應該要與程式碼分開控制版本，因為他們改變的頻率與理由接不相同
11. 如果你的程式碼需要註解來解釋，請考慮把它 refactor 到不再需要註解
12. 專業程式設計師唯一最重要的特點就是個人的責任感。他們對自己擁有的職業負責，對確認自己的程式碼可以良好的運作負責，對自己工作產出的品質負責，即使當截止日期迫在眉睫，他們還是不放棄自己的原則。當壓力日益增加時，專家要比以往任何時候都更嚴格堅持著原則，他們知道這樣才是正確的
13. 試圖挽救糟糕程式碼所浪費的時間，會比預想的多更多。一旦遇到怎麼修改都毫無起色的程式碼，應該立刻丟棄。修改糟糕程式碼的最好的方式就是換個做法，將程式碼無情的refactor 、移到別的地方或乾脆把它刪除掉。
14. SRP(Single Responsibility Principle) 是良好設計的最基本原則，即將那些為了相同的理由而改變的東西聚集在一起，並將那些為了不同的理由而改變的東西獨立出來。
15. 越接近交付期限，壓力越大，人本能的就開始偷工減料略過測試，所以你要想辦法把測試自動化，執行完就知道測試結果
16. 你可以把 soak test 設定在假日執行 (如星期五半夜到下週一早上六點)，藉此查看是否有 memory leak 的問題
17. 當一個程式設計師，做個有經驗的技術專家已經不夠了，你還必須能與其他人有效率地一起工作
18. 程式碼不會說謊，但是它卻會自我矛盾。有時候，錯加上錯就會變成對的，但它會變成更難以修復
19. 良好的測試就像受測程式碼的文件一樣，它描述了程式碼如何運作。在每一個使用情境中，測試可以
1. 描述出這些程式碼的執行脈絡、起始點或者必須滿足的前置條件
2. 說明軟體如何被調用
3. 描述出預期的結果或是需要驗證的 post condition
20. 在測試的過程中，過多的程式碼會把閱讀你程式碼的人轉移到無關緊要的瑣事上，盡可能把這些瑣事使用具有意義命名的方法隱藏起來，這樣的方法稱為 extract method，這個 refactor 技巧會是你最好的朋友
21. 你想要寫出良好的程式碼，並希望能成為一位好的程式設計師，你必須
1. 在任何情況下，拒絕用 hack 的方式做出那種只是看似能夠運作的程式碼
2. 你所寫的程式碼是淺顯易懂、易於維護、正確及確認已經解決問題
3. 考慮到團隊的其他程式設計師，讓其他人可以讀懂你建構的程式碼
4. check in 程式前，要讓程式碼比當初 check out 時來得更好 （如更好閱讀、更好的結構、更容易測試等）
5. 持續學習新的語言、方法和技術，在適當的時機就可以派上用場
22. 盡早挑戰你的客戶，並且要經常挑戰他們。別輕易的用他們的話重述他們告訴你的需求。請記住：客戶所告訴你的，不一定是他們想要的。客戶無法告訴你全部的事實，只是以客戶的方式陳述自己的想法，而非以開發人員的方式