在說這個問題之前，可能需要先討論一下，什麼是好的代碼？什麼又是壞的呢？記得我聽過那麼一句話“衡量代碼質量的唯一標準是閱讀該代碼時說髒話的次數”，我覺得很有意思，從某一方面衡量，也說的很貼切，代碼的質量與閱讀時的皺眉次數，髒話次數成反比。什麼是好的代碼？ 這個問題可能是仁者見仁，智者見智。
就我來說，我一直以來衡量一段代碼是否好的方式是從兩方面來看，一方面是“道”，一方面是“術”。
簡單的來說“道”停留在系統設計層面，將實體良好的抽象出來，是對問題本質的洞察。我認爲好的“道”有兩個方面。一方面，一個好的系統設計是由幾個基本的概念組成，這幾個概念體現了系統的本質，形成了系統的骨架，他們非常地穩定，生命週期很長。系統的其他代碼，邏輯等圍繞着這幾個基本概念生長，變化，擴展，讓系統不斷地演進。另一方面，好的“道”就是一些設計原則，就是我們常說的一些“開閉原則”，“單一職責原則”之類的，就不會有僵化、脆弱、重複、晦澀等種種可以導致代碼難以維護，亂七八糟的問題。代碼就容易擴展，生命力就會長久。
但是吧，這些核心的、優美的設計很有可能在項目進度的壓力下出問題。我自己的切身體會，有的時候做個簡單粗暴的修改，就能省好幾天功夫，不用晚上加班了，往往對人誘惑很大，懶得一下去重構。 所以要堅決守住這些核心的設計，防止腐化。
“術”的話，個人覺得也應該從兩方面來說，一方面是指“使用技術”，使用的不一定是當下最流行，不一定是最新的，一定要是最符合應用概念場景的，這一點很重要。舉個例子來說微服務吧，在一個系統構思初期，可能還不知道服務分界呢，就爲了使用微服務技術草草拆分業務，往往是不合適的，大機率會產生大面積重構甚至重寫。不要爲了用而用某個技術。另一方面“術”也值得是“編程技術”，這個很好理解，就是寫出來的代碼質量，比如《編寫可讀代碼的藝術》和《代碼簡潔之道中》總結的技巧，例如“避免if嵌套的層次過深，形成“金字塔”代碼”，“儘可能用常量”，“拆分超長表達式”，“函數應該短小，只做一件事情”，“把過多的參數封裝成類”等等的吧，好的代碼一定是簡單易讀的。
當然在其中沒有說道的，什麼代碼註釋啊之類的，都是要寫的，但是不要太冗長之類的，大家心裏應該都十分的清楚。
相對於“術”，“悟道”就難得多，洞察問題本質，做出良好抽象，遵循設計原則，這都是內功，都需要不斷修煉。 但是這些“道”直接決定了系統的未來方向，設計得不好，再多的“術”也於事無補。願大家在這條路上多多提高自己，突破自己。
其實這篇文章只是想吐槽下現在很多初期很好的代碼，沒有被堅持下去，被改面目全非，編程爲某個業務訂製一樣，類似業務有了也沒重構，就複製一份過去改改接着用，這樣的現狀。可能幾次躲過了加班，但是缺爲以後買下了很多坑。唉，且行且珍惜啊。