[BOOK] 成為卓越程式設計師的38項必修法則

作者 : Pete Goodliffe

譯者 : 賴屹民

身為一個軟體工程師來看這本書

本書確實提供了一些很好的建議

作者將這38項法則，分做五大部分

1. 撰寫程式的法則

2. 軟體開發的法則

3. 個人的 mindset

4. 如何完成工作

5. 團隊合作

首先，在撰寫程式的法則部分

如果本身是有在寫程式的人，這邊提到的觀念應該多少都有聽過

像是良好的排版、有意義的命名

YAGNI原則 : You Aren't Gonna Need It，不用寫現在不需要的程式碼

不要忽略錯誤，做好 error handling

撰寫單元測試，來確保軟體的品質

推遲設計決策 : 在還沒有完全知道實際需求前，不要寫程式

這個部分所提到的法則，或許不能當做至上法則

但大致上，都是滿值得參考的法則

在軟體開發這個部分

這邊是用比較宏觀的角度，來看軟體開發這件事

像是 KISS 原則 : Keep it simple, stupid。在設計程式架構的時候

不要複雜化，但也不能過度簡化

例如不要做過多的假設、不要增加過多的中間抽象層，這樣只會讓程式複雜

但同時，也不能忽略需求，例如只關注主要狀況，而不處理錯誤的輸入

這樣就過度簡化了

而在軟體開發有一個很重要的觀念，「沒有事情是一成不變的」

軟體必須是活的，因為環境和需求是會變動的

這代表寫的程式是能夠被延伸、被修改的

然後要使用「版本控制」

這能避免程式因為一個錯誤，就整個崩壞

也能讓軟體開發的流程，更加明確以及更能被管理

而同時也要正確的使用版本控制的工具

像是只儲存該儲存的東西，例如個人IDE的設定，就不需要被儲存

以及應該要微量提交，且每次提交都是單一完整的修正

這個部分所提出來的法則，個人認為有在從事軟體開發的人來看

會很有感觸

個人的 mindset 部分

主要的觀念就是「學習」

軟體不斷在演進

新的語言、新的design pattern、新的 framework

如果身為一個軟體工程師，不具備不斷學習的精神

很快就會被淘汰的

至於如何完成工作的部分

著重在於，如何「聰明」的完成工作，而不是「辛苦」的完成工作

要懂得踩在巨人的肩膀上，不要每次都想重造輪子

開發軟體之前，先定義好「完成」所代表的意義

只需要先達到需求所要的，不要做過多的設計和重構

最後，軟體開發是需要團隊合作的

作者將軟體開發形容為一種社交活動

想要成為一位好的程式設計師

要懂得和別人溝通以及共事，對象可能是同事、QA或是客戶

要會從別人身上學習

程式設計不應該，也不能是孤獨的單兵作戰

如果是程式開發人員，這本書很值得放在身邊

過了一段時間後，翻翻書中的內容，來和目前遇到的狀況做個對照

會愈看愈有心得的

------ 精華摘錄 ------

1. 重構的目的，是為了提升程式碼的可讀性、改善內部結構、讓程式碼更易於維護，最常見

    的情況是爲了協助之後的功能提升而做好準備

2. 不要複製程式碼片段。將它們重構為共用的函式，使用參數來表達所有的差異

3. 不要在修改程式碼排版的同時調整功能。如果要做的話，先整理排版，提交你的程式碼，

    之後再修改功能。(但最好是保留既有的排版，除非它糟糕到會妨礙到你)

4. 盡力確保你的 "整理工作" 會保留既有行為

5. 唯有使用有效的單元測試組來包裝程式碼，才可以有效率地達成目標，所以要考慮是否要

    先寫一些測試程式來捕捉重要的程式碼行為

6. 任何笨蛋都可以編寫電腦能瞭解的程式。好的程式員會編寫人類可以瞭解的程式

7. 維護軟體設計的品質。不好的設計會導致更不好的設計

8. 良好的設計會考慮連結機制與元件間的連結數量與性質。系統的每一個部份都必須可以獨

    立存在。緊耦合會產生無法測試的程式碼

9. 推遲設計決策。早期只設計重要的東西，並延遲所有其他的決定，當我們明確地知道實際

    的需求，以及如何將它們完善地放到系統時再來做

10. 團隊的組織對它創造的程式有必然的影響力。當團隊是分裂的，程式碼就會笨拙地互動。

      當他們互相合作，結構就會整合得很好

11. 簡單過頭的程式是不正確的程式，因為它是一種病態，仔細想想，它的動作無法符合需

      求。通常它只會解決明顯的 "主要狀況"，忽略錯誤條件，或無法正確地處理較不常出現的

      輸入

12. 只編寫足夠解決問題的程式。不要編寫大量你「認為」將會用得到的程式。不會被用到的

      程式只是包袱，它是額外的負擔

13. 把軟體開發視為線性流程，是錯誤的看法

14. 記得QA屬於「同一個」團隊，他們不是競爭對手。我們需要培養一種整體的做法，以及

      健康的關係來培養健康的軟體

15. 最糟糕的釋出流程罪惡之一，就是當你到達專案的尾聲，終於需要執行公開軟體釋出，才

      去思考這件事 

16. 應該在非常早期就開始建構開發流程中的自動化組件與釋出管道。你應該經常使用它，來

      證明它是可以動作，而且是強健的。這也可以協助找出並消除任何程式碼針對安裝環境的

      邪惡設定(寫死的路徑、假設電腦安裝某些程式庫、電腦能力等等)

17. 好的程式員都是好的溝通者。他們會善加討論、書寫、寫程式、聆聽及閱讀

18. 在你知道成功的定義之前，不要開始寫任何的程式。如果你還不知道，第一個工作先定義

      什麼是「完成」。通常這不是由程式員來定義，而是產品負責人、系統設計師、顧客，或

      使用者

19. 沒有軟體是「徹底完成」。定義上，軟體是軟的，需求在明天就會改變，需要我們修改它

20. 跟其他的程式員回報你的工作品質，會大大地改善你的程式品質

21. 願意回答別人對你的程式品質提出的問題，會鼓勵你做到最好