不知道看這篇文章的人有沒有想過，一個遊戲引擎的程式碼是怎麼讓我們這些使用引擎的程式也能理解怎麼使用它們的引擎？更進階的話，他們是怎麼維持有一百萬以上的程式碼運作又不會出現奇怪的bug？
不管怎樣，程式的品質肯定是一定要擁有的條件之一，那甚麼東西會被視為維護品質的重要因素呢？這邊我提出十點我在Clean Code兩本書籍裡認為重要的部分，其他內容有興趣可以自己去翻翻看。
以初學者來說，我會覺得就算功能真的拆不太開，那至少也要把名稱取好，才不會隔天早上醒來忘光之前的程式碼到底是在做什麼。更何況現在重構的工具很方便，只要一個按鍵就可把整個專案的名稱全部改掉，何必為了一時的偷懶到導致後來程式碼的改動困難。如果有取名困難症的話，可以多翻點相關領域的名詞有助於取名。以遊戲來說，翻閱這次製作的相關類型遊戲可能會在這些方面的功能取什麼名字，是一個蠻有幫助增加自己取名的方式。
把自己辛辛苦苦打出來的程式碼刪除確實是個會令人感到心痛的事情。不過相信我，你根本想不起來你刪除的程式碼樣子。更何況現在有git這種工具，只要commit的註解不要亂打的話都可以知道當時改了什麼東西，真的有天想回去看時再用那個回朔到當時的版本就好了。
雖然Clean Code裡的主張是與其打註解去解釋這段功能的意思，不如在取function的名稱的時候就努力把名稱取好，讓人一看就知道這個功能是甚麼意思。不過隨著程式碼的數量增加，有些時候就算名稱已經取的很清楚，還是會有對於此功能誤解的時候。所以還是會需要有summary這種註解方式的存在，但也因此註解的內容更要發揮名詞解釋的有限，去讓使用者可以清楚知道這個功能的意思。
因為要是功能都混再一起的話，要是今天只想使用一部份功能的話就會很麻煩，沒辦法做到重複利用的效果。一開始寫程式可能比較難去分辨有哪些功能是可以拆開來的，可以先從有什麼段落的程式碼是其他地方需要的，而有沒有個名稱可以代表這個功能去拆解看看。
因為要是重複的程式碼散在四處，而bug剛剛好出現在這之中，但有十幾處都是相同的程式碼，這時不就要一一去尋找當時這些重複程式到底被放在甚麼地方，這不是很麻煩嗎？當然要是太過極端的去消滅重複其實也不是個好做法，還是要去思考說目前的重複是不是真的在重構上會有問題出現在去做統合的動作，我個人是會以此種重複的程式碼有沒有出現三次以上時，才開始去考慮是否要重構這樣。
我是以該class有沒有做出超出職責範圍的內容去分別，當然要是有點分不出來的話，一開始我建議以比較簡單的方式去分類，像是把資料、邏輯、視覺這幾個拆開來放，與此同時會有一層是將這三個功能結合再一起的地方。後面會有一篇會比較詳細的去講這個部分。
程式這個工作應該是最無法快速做出東西的職業了吧，雖然重構才是寫程式的常態，不過要是在專案前期可以好好想想整體來說程式的架構大概要長怎麼樣、甚麼插件可以幫助開發更加迅速、企劃本身可能有疑慮的部分先提出來給對方知道，才比較不會發生功能做一半才驚覺設計上有問題，最後做下來走了許多冤妄路。
有些問題可能Google大神也一時救不了你，或者你在煩惱目前的架構有甚麼地方可以更好時。不要去糾結在那個問題上面，可以先嘗試離開電腦一下，喝個水或上個廁所，或隨便小散個步都行，可能靈感就忽然飛過來了。
程式跟其他領域的工作可能有個很大的差別是程式碼最後都是很有可能公諸於世，程式的世界是沒有祕密的，只有你找不找的到相關資源。與其閉門造車，不如多出來分享自己的作法，能力會進步得更快。當然覺得自己火侯不夠，還寫不出什麼有技術性的文章，那分享看起來有價值的文章也是不錯的做法。
雖然這點已經聽到爛了，不過講真的，科技的發展速度是非常驚人，蠻常發生技術過了幾年就不再堪用的事情發生。所以平時還是要注意一下有沒有什麼最新技術的出現，或出現實用的工具可以使用。
以上就是我自己對於Clean Code的想法，要是有任何其他的建議也歡迎說出，下個章節我們就要來說更加上層的部分—也就是架構的部分啦。
無瑕的程式碼：敏捷軟體開發技巧守則
無瑕的程式碼 番外篇：專業程式設計師的生存之道
iThome鐵人賽
看影片追技術