程式設計寶典（ㄧ）無瑕程式碼
前言
或許你曾看過有人說程式碼總有一天會消失，那時會出現一台機器，它能夠猜出人類心中想要什麼，而不人類說什麼才做什麼，這些機器會具備理解人類的能力，能夠將我們心中模糊不清的需求轉化成為我們需要的結果，進而達成我們的目的
但是，這種情況，你認為可能嗎？
上述的情況永遠不會發生，即使人類有著直覺與無與倫比的想像力，我們都不一定能保證將所有想法產生一個對應的成功系統，因此你只需要記住程式碼是人類用來闡述需求的語言，我們也許會創造一些類似需求的語言，或許會開發一些工具來幫助我們解析或組合這些需求，並將這些需求轉化爲正式的結構。然而，作為上述幾種方法的本質，我們永遠無法省略必要的精確性，以大致的模型來取代能夠客製化處理需求的程式碼，因此程式碼會一直存在，我們永遠不可能完全不用寫程式碼來達成所有需求。
「劣質」的程式碼
既然程式碼的重要性不可言喻，如何寫出好的程式碼，便是所有程式設計師夢寐以求的能力。在詳細說明何謂好的程式碼之前，我想先讓你知道何謂劣質的程式碼，而劣質程式碼又會帶來什麼樣的影響。
《Clean code》也提到曾經有一家公司在 80 年代開發了一個殺手級的應用程式，它非常火熱，很多專家也很常看好這個程式，但隨著發行的週期開始拖長，程式裡的錯誤也無法在下次發行之前修復，這導致程式崩潰的機率越來越高，也越來越多人失望的放棄使用這個應用程式。
而造成如此結果的最根本原因也在 20 年後被公司早期的一位員工爆出來，他說因為他們急於將產品上市，導致他們的程式碼變的一團糟，而當他們基於這個混亂繼續加入越來越多產品特點時，他們再也無法控制這些混亂，進而導致了公司的倒閉。
你是否曾經被不好的程式碼所阻礙呢？如果你是一位有經驗的程式設計師，你必定感受到過多次這樣的阻礙，解決這些阻礙就像艱難的在佈滿荊棘和陷阱的泥潭上行走，你努力的尋找出路，希望得到一些提示與線索，最終看到的卻是越來越多無意義的程式碼。
假設你已經認可雜亂的程式碼是開發的一大阻礙，假設你已經承認有效率開發的必要因素就是保持程式碼整潔與無瑕，那勢必非常想知道如何才能擺脫劣質的程式碼？即寫出所謂「無瑕的程式碼」。
何謂「無瑕」的程式碼？
Ron Jeffries（羅恩·傑弗瑞），《Extreme Programming Installed》和《Extreme Programming Adventure in C#》的作者，Ron 幾乎使用每一種程式語言來寫程式，也在許多種類的機器開發過程式，我非常喜歡 Ron 講的一段話：
近年來，我開始使用 Beck 的簡單程式碼規則（Beck’s rules of simple code），以下依優先順序，列出幾項優質程式碼的特質：
- 能通過所有的測試
- 沒有重複的程式碼
- 充分表達系統設計的構思
- 具有最少數量的實體（entities）
💡 實體包含類別（class）、方法（Method）、函式（function）等等。其中，Ron 最強調的部分在於重複程式碼的部分。他認為當同樣的事情重複地一做在做，是一個徵兆，代表你的想法並沒有被適當的表達在程式碼中，你應該試圖弄清楚那是什麼，試圖將想法表達的更清楚。
這邊提到了「表達力」的概念，表達力對他而言，或說對所有程式設計師而言，包含了**有意義的命名、清楚表達且切割明確的方法、有益的註解、良好的編排、完善的物件及資料結構與真正幫助你了解程式運行的錯誤處理，**也是我們在此系列教學文中，會一一探討的主題。
但其實不用看得那麼複雜，在他看來，所有的程式都是由非常相似的元素所組成，例如「在一個集合裡找東西」，不論是你擁有一個資料庫或是鍵與值構成的雜湊映射表（hash map），甚至是一個陣列，我們都可以發現，我們是想在一個集合裡面找出一個特定的東西，而當他發現這類型的功能需要實作，他通常會把具體的實作包裹到一個更抽象的方法或類別中，而這樣做也給他帶來了莫大的好處。
💡 雜湊映射表（hash map, hash table）： 根據鍵（Key）直接查詢內存存儲位置的資料結構，通過計算一個關於鍵值的函數，將所要查詢的數據映射到表中一個位置來查詢的技術。最後，他再次強調減少重複的程式碼是具有高度表達力的重中之重，它能幫助你及早建立簡單抽象概念，而對他來說，這就是撰寫無瑕程式碼的方法。
結論
本系列教程不能保證讓你成為一位頂尖的程式設計師，也無法保證賦予你最好的程式能力，但本系列能做到的是讓你了解頂尖程式設計師的思維，帶你透過一些簡單的開發實例接觸他們所使用的程式技巧、技術以及開發工具。
你會在本系列教程陸續看到許多優質的程式碼，也會看到一些劣質的程式碼，你將會看到一連串的啟發、規則與技巧，但最終決定如何編碼的人還是你，希望你能透過本系列教程總結出最合適你的編碼方式，如果有任何關於本系列文章的問題，歡迎於留言區留言。
參考資料
《Clean Code 無瑕的程式碼》
