先貼幾張代碼截圖，看一下這個重病纏身的項目的病灶和症狀：
這是該項目中一個最核心、最複雜也是最經常要被改動的 class，代碼行數 4881；
結果就是冗長的 API 列表（列表需要滾動 4 屏才能到底，公有私有 API 180 個）；
還是那個 Class，頭部的 import 延綿到了 139 行，去掉第一行 package 聲明和少量空行總共 import 引入了 130 個 class！
還是那個坑爹的組件，從 156 行開始到 235 行聲明瞭 Spring 依賴注入的組件 40 個！
這裏先不去分析這個類的問題，只是初步展示一下病情嚴重程度。
我相信這應該不算是特別糟糕的情況，比這個嚴重的項目俯拾皆是，但是這也應該足夠拿來暴露問題、剖析成因了。
//
作者後面對問題給出藥方，並給出了一般性的方案，並總結：
我認為程序員最大的聲譽、最重要的職業素養，就是通過寫出高質量的代碼做好一個個項目、產品，來幫助團隊、幫助公司、幫助組織創造價值、增加成功的機會。
這難道不是程序員的本分嗎？？？
持不同觀點的朋友典型意見如下：
A老師：
這個觀點我覺得是技術硬給自己找存在感。
業務方向，運營方法才是關鍵，技術只是保底。
某千萬日活產品，從百萬到千萬的過程中，代碼被外來和尚説是垃圾，但暴發增長了，然後全面重構了，代碼質量也高了。可讀性也好了。擴展性也強了。但日活停止增長了。
老G觀點：
如果業務增長停止了，是市場的原因，技術不背這個鍋。 代碼重構也不背鍋。如果重構代碼的過程中，因為沒有精力去支持業務，技術團隊不能響應業務，那自然是不ok的。
這個文章在敏捷成都羣也有廣泛討論，比如
一位老闆説團隊某員工“追求極致” 結果在讓中小企業“負擔”更重了，這個罪名不可謂不大。但試問是追求質量的問題，還是學藝不精的問題啊。
B先生觀點：
如果甲、乙兩家公司的代碼都滿足了客户的需求，那這個質量好一些的是不是從客户那邊就看不出來了？
熊節老師回應：
如果少打幾根鋼筋也能把樓蓋起來，從客户那邊是不是就看不出來？一樣的道理。
ke先生觀點：
客户後期發現代碼可維護性太差，還會給你單麼？
老G先生現身説法：
曾經在某行業做單，是關係型銷售，老闆和甲方信息部的關係，反正多少錢他們談的差不多。然後幹活的時候甲方項目經理不斷加需求，然後在項目維護期間儘量讓乙方免費幹活。乙方的投入就要精打細算了。有可能犧牲部分功能，再跟甲方談判。求仁得仁！
小海同學説：
大部分團隊前期不怎麼管代碼質量，等大再做，結果已經遲了。
萬里兄弟説：
優質的代碼首先要遵守開發原則和規範。然後就是測試，除了測試，沒有第二種辦法。代碼質量是無論何時都必須要保證的。
kane：現在很多人寫代碼不做設計的，想到哪寫到哪。
馮先生：追求質量，屬於高級程序員的論點。如果是初中級不一定使用，某些公司開發初中級佔很大比例。大部分公司都處於求生存狀態。