好書推薦⏤The Pragmatic Programmer

前言

忘了什麼時候開始，想說搭捷運通勤的時候都沒事做，不如就來看書好了。前陣子逛Google Play圖書的時候看到「The Pragmatic Programmer」，想說久仰此書大名，自己其實也早就想看這本名著很久了，剛好手邊又有優惠折扣碼，就不小心給他刷下去了XD。這幾天終於把「The Pragmatic Programmer」閱畢，覺得獲益良多，心想好的東西不能只有我知道，所以在這邊分享、推薦給大家。

不過先說明一下，這次「The Pragmatic Programmer」我看的是原文版，為什麼呢？其實很多外文書的中文翻譯版都有一樣的問題，就是對於某些特定的詞彙總是會翻譯得不夠好，比較嚴重一點的甚至會偏離原意，我是覺得啦……有些詞其實直接使用原文不就很好了嗎？為什麼一定要非得把一本好好的書弄得整本都是晶晶體呢？看完了阿滴拍的這則YouTube影片，你可能會更懂我的幹在哪裡。

因為已經被中譯本雷怕了QQ，加上這一本是經典中的經典，想要好好體會作者想表達的精神，所以只好咬著牙看原文版了。

What is “Pragmatic” ?

如果直接把Pragmatic丟到Google翻譯的話，應該會看到翻譯的結果是「務實」，大家對於務實這個概念應該不陌生，但感覺上好像還是有點抽象？

來看一下牛津辭典（用英文解釋英文的辭典）對於Pragmatic的解釋吧：

solving problems in a practical and sensible way rather than by having fixed ideas or theories

在中文裡的意思大概是說：

「用合理、實際的方式來解決問題，而不是去找一個剛好可以解決問題的辦法。」

而謂「合理、實際的方式」，我覺得在軟體開發中，可以被解讀為設計模式（Design Patterns）與架構方法（例如SOLID、DRY），而「剛好可以解決問題的辦法」就是那些萬惡的workaround了。

所以說如果要字面上用最簡單的方式來定義一個人是不是「 Pragmatic Programmer」的話，可以從他做事的行為來觀察：

• 這個傢伙是不是做到功能達成需求做完就算了？
• 如果是對舊有的功能進行擴充，是不是抱持過去的架構不了解也沒差的心態？
• 明明要解決的問題已經有被認定是best practice的solution，有試著去survey過嗎？
• ……blah blah blah 還有很多很多之類之類的。

本書涵蓋範圍

雖然這本書初版已經是1999年的事了，雖然國外沒有行天宮，但真的很難想像在當年本書探討的內容就已經可以從內子宮聊到外太空了。內容涵蓋了身為一名「 Pragmatic Programmer」你該有的心態、該如何做好你的角色、你可以善用的工具……等等的（e.g. Abstraction, Decoupling, Separate Views From Models, Refactoring, Exceptions, Testing, Don’t Program by Coincidence, Know When to Stop Adding Paint, Communication, etc.），本身也搭載了非常多的案例與寓言故事（e.g. The Cat Ate My Source Code, Stone Soup and Boiled Frogs, etc.），讀起來也是滿有趣的。

節錄與筆記

在這邊分享幾個我在本書私心收藏的節錄部分：

當建築物中有一扇破掉的窗戶，且年久失修時，從外觀上可以讓人感受到一種「被廢棄」的感覺存在⏤⏤就是一種「沒人care這棟建築物」的感覺。慢慢的，接下來也會有其它窗戶破了。再過沒多久，垃圾開始出現了，塗鴉也跟著出現了，再來甚至連建築物的本體也會開始有被破壞的狀況產生。

不要留下任何破掉的窗戶（可能是不好的設計、錯誤的決策，或是一團亂的程式碼）。盡量在發現問題後把它用最快的速度處理掉。如果沒有時間，至少也將它記錄起來吧！例如留下註解或是用些別的方式，預防在未來可能因為一些已知的問題而去蒙受更大的損害。

被人從頭到腳看一遍總比被人視而不見的來得好。應該要去學習如何溝通，學習如何讓自己意見能被聽見，但是要分清楚，什麼是communicating，什麼是annoying。

運用orthogonal（暫譯：互不相干）的方法可以將開發中的風險降低。模組就像身體中的器官一樣，當一個器官中的癌細胞開始萌芽，是很有可能擴散到身體的其他地方的。程式碼也是一樣，當把耦合降得越低（isolated），我們越容易去針對「生病的」部分去進行整理，或是直接換一個新的。

當你開發完一個新元件後，可以試著問自己：如果需求稍微改變了一下，會影響到多少模組？

要如何去維護所謂的Orthogonality呢？可以試著：
- 降低程式碼的耦合
- 避免使用全域的資料
- 避免功能相似的方法
- 進行測試

Debug的心態：莫慌莫急莫害怕，別急著將目前看到的症頭解決。解決bug最好的方式就是讓它可以重覆出現。

我們認為寫出「害羞的程式碼」（shy code）好處多多。而所謂的「害羞」是這樣子的：別太去展露真實的自己，也別去別人有太多的互動。
（註：應該就是在說封裝與降低耦合）

與其說軟體開發是在「蓋房子（building construction）」，感覺上「做園藝（gardening）」會是個比較好的比喻。在一開始時，可能就依照計畫種了一堆有的沒的。而日子一天一天的過，有些植物會成長茁壯，而有的到頭來還是變成了肥料。為了去適應風吹與日曬，你也會需要不停地移動植物到它們適合的地方。當有植物漲得太快，可能會需要分枝與修剪。如果地上有雜草，會需要你來拔除。當有植物奄奄一息的時候，就會需要澆水與施肥了。軟體開發就像花園一樣，需要你持續不斷的悉心照顧，並且在需要的時候幫忙施肥與修剪。

什麼時候需要重構？
- 有重複的程式碼時（Duplication）
- 不是互不相干的設計（Nonorthogonal design）
- 過時的知識與用法（Outdated knowledge）
- 效能問題（Performance）

有時候你可能會遇到一個比你原先想像還要難得更多的問題。這很有可能是你走錯路了！一定會有其它更簡單的方法！

很多開發人員討厭測試，但Pragmatic Programmers是不同的。我們巴不得在當下就找出我們自己的bug，不然之後被其他人找出我們的bug是一件很丟臉的事情。而說到找出bug，彷彿就像是用魚網捕魚一樣，我們用小網（unit tests）來捉小魚，用大網（integration tests）來捉大魚。雖然有時候會不小心讓幾條魚溜走，但我們會盡量將魚網上的洞補好，以期缺陷能出現得越少越好。

當你的系統fail時，會是優雅的fail嗎？（當你跌倒時，你會優雅且華麗的跌倒嗎？）

如果我們對自己的設計與寫的程式碼是負責的，那我們就會對我們自己所做過的，感到驕傲。

讀後心得

很難想像在二十年前此書就涵蓋了非常多的應用實例，其中有許多規則在今天仍然還是適用的。雖然還是很怕被中譯本雷XD，但我認為這本書「The Progmatic Programmer」的中譯版本標題「程序员修炼之道」翻譯得非常貼切，這本書的內容比較像是在闡述軟體開發的藝術、禪（?）以及身為一個軟體開發人員所必須擁有的心態，雖然本書雖然沒有針對提及的各個主題有多深入的探討，但至少都有點出方向，讓我們可以針對有興趣的部分再自己去進行補強，整體來說還是值得一探究竟。

雖然每次看一本書的第一次都會有地方看得矇懞懂懂，在日後實戰演練後才會突然回想到原來書上說的是什麼，然後再過一陣子重新回味書本內容時，才又會頓悟之書中真正想表達的意思，但我想這就是成長吧！真所謂看山是山、看山不是山、看山還是山啊～