照著書中的順序，今天應該會進入第 13 章： 平行化。
平行化的概念有點類似異步，而該章節在講述在關於如何撰寫出平行化的程式，包括限制資料視野、使用複本等方法，去避免多執行緒會遇到的問題。
只是當我讀完三分之一後，猜測許多人所撰寫的程式可能不會接觸到相關領域，內容也不容易吸收，因此有悖於我參加這次鐵人賽的初衷：想要去學習關於程式最基礎的根本，能夠在各種領域都用上而不會被淘汰的核心技術。
所以，我接下來將跳過平行化章節，以及 14 到 16 章滿滿程式碼的案例解析，直接分享第 17 章：「程式碼的氣味及啟發」。
而接下來的這章是細節中的細節，也許就會一路分享到鐵人賽完結。
開始寫程式一段時間後，應該多多少少聽過這個詞： Code Smell \ Bad Smell，中文翻譯作程式異味、代碼異味或壞味道等等近似義的詞。而這個概念，最早應該是在 Refactoring (重構) 一書中被提出。原書我沒讀過，但「異味」一詞，意義上大抵是指程式碼中不恰當，需要被重構、改善之處。這篇的內容就是作者整理 Refactoring 及自己的案例與啟發後，所彙整而成的清單。
接下來，就讓我們一一來學習及複習吧：
不適當的註解：註解當中如果包含了更適合儲存於他處的註解，那就是不適當的註解。例如程式檔的修改紀錄、軟體效能報告序號之類的詮釋訊息，這些註解只會混亂程式原有的資訊。註解應該保留給技術性紀錄，如程式或設計方面的資訊。
多餘的註解：當程式碼本身已具備表達能力，就無需再多做註解。例如：
i++ // increment i
註解應該要說明的是，程式本身無法表達的意圖。
寫的不好的註解：我們曾說過，註解只是用來彌補我們用程式碼表達意圖的失敗，若我們實在不得已需使用，就要妥善書寫，簡潔有力。
廢棄的註解：先前也提過，註解很常說謊。當它沒有跟上程式的演變而留在原地，那它很容就會成為一種誤導。因此若看見廢棄的註解，就該盡快更新或移除它。
被註解掉的程式碼：這可能是最常見的註解異味。請不要再遺留或不捨刪除一段程式碼，而選擇使用註解。沒人知道誰會使用到這段程式碼，甚至不知是哪個年月遺留的程式碼，裡面的函式或變數也可能早已改變或消失。永遠記得，讓版控系統做版控的事。
需多個步驟建立專案
需多個步驟進行測試
這兩項應可合併來說。建立專案應該是一個簡單的行為，而非需一連串神秘的指令才能完成。同樣地，測試也是如此。測試功能是重要且基本的需求，如果我們需要耗費大量心力才能完成它，將會大大減少我們測試的意願，進而傷害到程式的健康。
因此，盡量讓我們的環境能夠簡單、快速的運作。
iThome鐵人賽
看影片追技術