Changelog - 軟體工程師的修鍊之道

"The Pragmatic Programmer" 在 1999 年第一次出版, 事隔20年後出了第二版, 主要是更新一些例子, 書中一些建議的方法已經過時, 需要淘汰; 有些則是作者找到更好的方法來闡述想法; 過了 20 年, 業界也有些新的問題, 例如cocourency, security的問題 需要面對.

40年前的"人月神話"一書裡面提到的技術現在都已不復存在, 但它所講的問題, 擺在今日還是存在. "The Pragmatic Programmer"第二版裡有75%的內容都更新了, 但不變的是, 依舊在討論怎麼處理人的問題. 很多章節的主題雖然看似跟人無關, 例如"naming", 但它其實還是關於"人", 怎麼命名影響人怎麼去分類, 怎麼去思考.

現在的車子的複雜度已經遠遠超過我們的理解, 但我們不會擔心, 因為它裡面的每個元件都非常的成熟. 但軟體界裡面的元件還沒有這樣的成熟度, 或是我們都還沒有等到它成熟就丟棄了. 業界裡有一個笑話: "今天是星期三, 這代表又有 47 個新的 javascript framework 出現了". 大家總是覺得新的比較好, 自己做的比較好. 大家為了解決一個問題, 而新寫一個 library 或 framework, 它的確解決了新的問題, 但它是否有解決舊的問題, 沒有人關心. 甚至沒人知道有什麼舊的問題被解決過, 結果就是我們一直在同樣的一堆問題裡打轉. 如果一個人要寫作, 他首先要閱讀大量前人的作品, 但軟體界中, 很少工程師會看前人的 code (除非自己要去修改, 不得不看), 這跟"Why Smart Engineers Write Bad Code"的作者想法一樣, 我們應該去讀讀大型專案的 code, 了解過去的架構設計理念, 才有可能融會貫通.

訪問的最後, 主持人請兩位作者挑出他們心中最有用的tip, Dave 挑了一個 "It's your life": 很多工程師都像自動導航的車子, 他們接下工作, 使用公司指定的程式語言, 邊抱怨邊做, 直到再也做不下去為止. 他沒有去思考是不是有更好的做法, 不以自己寫的 code 為傲, 當然也不想為自己的產品負責, 所以覺得測試不重要, 沒有必要重構, 但這是你的人生, 嘗試做出改變吧. Andy 挑的是 "Don’t outrun your headlights": 不要想要一步登天, 就像攀岩, 永遠是三點不動, 一點動, 這也是 Agile 的精神, 做一點, 看看產出, 收集回饋. 軟體工程師普遍沒有"謙遜"的心理, 這是個年輕人意氣風發的產業, 但在做了工程師十幾年後, 我越發覺得心態遠比技術還要重要得多.

Reference Source:
https://changelog.com/podcast/352