此系列文為閱讀完 「Clean Code 無瑕的程式碼 -- Robert C. Martin (Uncle Bob.)」及 Udemy 課程 ―「C# Developers: Learn the Art of Writing Clean Code -- Mosh Hamedani」，再加上一些團隊內部分享後的心得整理，請各位多多指教。
何為 Clean Code ?
「刪除程式碼？」
「需要被清除的程式碼？」
「乾淨的程式碼？」
老實說我剛開始接觸這個名詞時，也摸不著頭緒。
現在若要我用一句話囊括，那應該會是
閱讀程式碼像閱讀文章一樣容易，程式運行的結果跟你想的差不多，那就表示你正在 Clean Code 上工作。
Ps. 深深覺得「無瑕的程式碼」這個翻譯實在太棒了。
Clean Code 很重要嗎？
Clean Code 對我來說，是一門反璞歸真的藝術。當我們學習各種高深的程式技術，寫出運行正確的程式碼後，是否曾經想過這樣的程式碼，算是「好」的程式碼？在缺乏 Code Review、Pair Programming 的情況下，更難察覺這樣的問題。
所謂的「寫」程式，真的都是在「寫」程式嗎？撇除思考演算法不談，其實大多數的時間，是在操作 IDE 與 閱讀程式碼吧？閱讀程式碼與撰寫程式碼的時間比約莫為 10：1，既然花費這麼多的心思在閱讀，撰寫出容易閱讀的程式碼更顯重要。
往往有些團隊，一開始可以表現出極佳的生產力，但很快的，生產力急遽下降。可能是因為團隊不夠「敏捷」，無法應付經常異動的需求變更。另一個原因往往是因為隨著程式碼數量提高，軟體複雜度成指數上升，更大幅突顯可閱讀性、可維護性等技術債的缺陷，導致生產力急遽下降。如此集腋成裘的因素，往往不易被察覺，卻是致命可怕的主因。
怎樣是正確的 Clean Code 規範？是足夠整潔的程式碼？
武林門派眾多，各有各的道理，沒有所謂的最正確、最好的規範。最重要的是，是否意識到那些阻礙自己閱讀的細節，以及團隊是否有一致的共識？
換言之，你的程式碼不會永遠都是自己維護，別人也必須容易閱讀。就算都是自己維護，今天寫的程式，數個月後也往往發生閱讀困難的情況。
最可怕的不是你寫的程式只有你看得懂，而是連你自己都看不懂...
看完系列文之後呢？
工程師在撰寫程式碼時，僅僅專注於功能的正確性而忽略了整潔性。一次只專注一件事，這是非常正確作法。但在追求正確性之後，請務必回過頭讓程式碼更容易閱讀、維護。
看完這系列的規範，或許很多會覺得很有道理，但千萬別急著開始大興土木。建議建立完單元測試作為保護網之後再行開工。暫時不改也無妨，但請記住童子軍法則，確保每次修改後都比原來更好。
離開營地前，讓營地比使用前更加乾淨。
