有關你寫出的爛代碼的那些事
1.摘要
最近寫了不少代碼，review了不少代碼，也做了不少重構，總之是對著爛代碼工作了幾周。為了抒發一下這幾周里好幾次到達崩潰邊緣的情緒，我決定寫一篇文章談一談爛代碼的那些事。 這里是上篇，談一談爛代碼產生的原因和現象。
2.寫爛代碼很容易
剛入程序員這行的時候經常聽到一個觀點：你要把精力放在ABCD（需求文檔/功能設計/架構設計/理解原理）上，寫代碼只是把想法翻譯成編程語言而已，是一個沒什么技術含量的事情。
當時的我在聽到這種觀點時會有一種近似于高冷的不屑：你們就是一群傻X，根本不懂代碼質量的重要性，這么下去遲早有一天會踩坑，呸。
可是幾個月之后，他們似乎也沒怎么踩坑。而隨著編程技術一直在不斷發展，帶來了更多的我以前認為是傻X的人加入到程序員這個行業中來。
語言越來越高級、封裝越來越完善，各種技術都在幫助程序員提高生產代碼的效率，依靠層層封裝，程序員真的不需要了解一丁點技術細節，只要把需求里的內容逐行翻譯出來就可以了。
很多程序員不知道要怎么組織代碼、怎么提升運行效率、底層是基于什么原理，他們寫出來的是在我心目中爛成一坨翔一樣的代碼。
但是那一坨翔一樣代碼竟然他媽的能正常工作。
即使我認為他們寫的代碼是坨翔，但是從不接觸代碼的人的視角來看（比如說你的boss），代碼編譯過了，測試過了，上線運行了一個月都沒出問題，你還想要奢求什么？
所以，即使不情愿，也必須承認，時至今日，寫代碼這件事本身沒有那么難了。
3.爛代碼終究是爛代碼
但是偶爾有那么幾次，寫爛代碼的人離職了之后，事情似乎又變得不一樣了。
想要修改功能時卻發現程序里充斥著各種無法理解的邏輯、改完之后莫名其妙的bug一個接一個，接手這個項目的人開始漫無目的的加班，并且原本一個挺樂觀開朗的人漸漸的開始喜歡問候別人祖宗了。
我總結了幾類經常被艸祖宗的爛代碼：
3.1.意義不明
能力差的程序員容易寫出意義不明的代碼，他們不知道自己究竟在做什么.
就像這樣：
- public void save() {
- for(int i=0;i<100;i++) {
- //防止保存失敗，重試100次
- document.save();
- }
- }
對于這類程序員，我一般建議他們轉行。
3.2.不說人話
不說人話是新手最經常出現的問題，直接的表現就是寫了一段很簡單的代碼，其他人卻看不懂。
比如下面這段：
- public boolean getUrl(Long id) {
- UserProfile up = us.getUser(ms.get(id).getMessage().aid);
- if (up == null) {
- return false;
- }
- if (up.type == 4 || ((up.id >> 2) & 1) == 1) {
- return false;
- }
- if(Util.getUrl(up.description)) {
- return true;
- } else {
- return false;
- }
- }
很多程序員喜歡簡單的東西：簡單的函數名、簡單的變量名、代碼里翻來覆去只用那么幾個單詞命名；能縮寫就縮寫、能省略就省略、能合并就合并。這類人寫出來的代碼里充斥著各種g/s/gos/of/mss之類的全世界沒人懂的縮寫，或者一長串不知道在做什么的連續調用。
還有很多程序員喜歡復雜，各種宏定義、位運算之類寫的天花亂墜，生怕代碼讓別人一下子看懂了會顯得自己水平不夠。
簡單的說，他們的代碼是寫給機器的，不是給人看的。
3.3.不恰當的組織
不恰當的組織是高級一些的爛代碼，程序員在寫過一些代碼之后，有了基本的代碼風格，但是對于規模大一些的工程的掌控能力不夠，不知道代碼應該如何解耦、分層和組織。
這種反模式的現象是經常會看到一段代碼在工程里拷來拷去；某個文件里放了一大坨堆砌起來的代碼；一個函數堆了幾百上千行；或者一個簡單的功能七拐八繞的調了幾十個函數，在某個難以發現的猥瑣的小角落里默默的調用了某些關鍵邏輯。
這類代碼大多復雜度高，難以修改，經常一改就崩；而另一方面，創造了這些代碼的人傾向于修改代碼，畏懼創造代碼，他們寧愿讓原本復雜的代碼一步步變得更復雜，也不愿意重新組織代碼。當你面對一個幾千行的類，問為什么不把某某邏輯提取出來的時候，他們會說：
“但是，那樣就多了一個類了呀。”
3.4.假設和缺少抽象
相對于前面的例子，假設這種反模式出現的場景更頻繁，花樣更多，始作俑者也更難以自己意識到問題。比如：
- public String loadString() {
- File file = new File("c:/config.txt");
- // read something
- }
文件路徑變更的時候，會把代碼改成這樣：
- public String loadString(String name) {
- File file = new File(name);
- // read something
- }
需要加載的內容更豐富的時候，會再變成這樣：
- public String loadString(String name) {
- File file = new File(name);
- // read something
- }
- public Integer loadInt(String name) {
- File file = new File(name);
- // read something
- }
之后可能會再變成這樣：
- public String loadString(String name) {
- File file = new File(name);
- // read something
- }
- public String loadStringUtf8(String name) {
- File file = new File(name);
- // read something
- }
- public Integer loadInt(String name) {
- File file = new File(name);
- // read something
- }
- public String loadStringFromNet(String url) {
- HttpClient ...
- }
- public Integer loadIntFromNet(String url) {
- HttpClient ...
- }
這類程序員往往是項目組里開發效率比較高的人，但是大量的業務開發工作導致他們不會做多余的思考，他們的口頭禪是：“我每天要做XX個需求”或者“先做完需求再考慮其他的吧”。
這種反模式表現出來的后果往往是代碼很難復用，面對deadline的時候，程序員迫切的想要把需求落實成代碼，而這往往也會是個循環：寫代碼的時候來不及考慮復用，代碼難復用導致之后的需求還要繼續寫大量的代碼。
一點點積累起來的大量的代碼又帶來了組織和風格一致性等問題，最后形成了一個新功能基本靠拷的遺留系統。
3.5.還有嗎
爛代碼還有很多種類型，沿著功能-性能-可讀-可測試-可擴展這條路線走下去，還能看到很多匪夷所思的例子。
那么什么是爛代碼？個人認為，爛代碼包含了幾個層次：
如果只是一個人維護的代碼，滿足功能和性能要求倒也足夠了。
如果在一個團隊里工作，那就必須易于理解和測試，讓其它人員有能力修改各自的代碼。
同時，越是處于系統底層的代碼，擴展性也越重要。
所以，當一個團隊里的底層代碼難以閱讀、耦合了上層的邏輯導致難以測試、或者對使用場景做了過多的假設導致難以復用時，雖然完成了功能，它依然是坨翔一樣的代碼。
3.6.夠用的代碼
而相對的，如果一個工程的代碼難以閱讀，能不能說這個是爛代碼？很難下定義，可能算不上好，但是能說它爛嗎？如果這個工程自始至終只有一個人維護，那個人也維護的很好，那它似乎就成了“夠用的代碼”。
很多工程剛開始可能只是一個人負責的小項目，大家關心的重點只是代碼能不能順利的實現功能、按時完工。
過上一段時間，其他人參與時才發現代碼寫的有問題，看不懂，不敢動。需求方又開始催著上線了，怎么辦？只好小心翼翼的只改邏輯而不動結構，然后在注釋里寫上這么實現很ugly，以后明白內部邏輯了再重構。
再過上一段時間，有個相似的需求，想要復用里面的邏輯，這時才意識到代碼里做了各種特定場景的專用邏輯，復用非常麻煩。為了趕進度只好拷代碼然后改一改。問題解決了，問題也加倍了。
幾乎所有的爛代碼都是從“夠用的代碼”演化來的，代碼沒變，使用代碼的場景發生變了，原本夠用的代碼不符合新的場景，那么它就成了爛代碼。
4.重構不是萬能藥
程序員最喜歡跟程序員說的謊話之一就是：現在進度比較緊，等X個月之后項目進度寬松一些再去做重構。
不能否認在某些（極其有限的）場景下重構是解決問題的手段之一，但是寫了不少代碼之后發現，重構往往是程序開發過程中最復雜的工作。花一個月寫的爛代碼，要花更長的時間、更高的風險去重構。
曾經經歷過幾次忍無可忍的大規模重構，每一次重構之前都是找齊了組里的高手，開了無數次分析會，把組內需求全部暫停之后才敢開工，而重構過程中往往哀嚎遍野，幾乎每天都會出上很多意料之外的問題，上線時也幾乎必然會出幾個問題。
從技術上來說，重構復雜代碼時，要做三件事：理解舊代碼、分解舊代碼、構建新代碼。而待重構的舊代碼往往難以理解；模塊之間過度耦合導致牽一發而動全身，不易控制影響范圍；舊代碼不易測試導致無法保證新代碼的正確性。
這里還有一個核心問題，重構的復雜度跟代碼的復雜度不是線性相關的。比如有1000行爛代碼，重構要花1個小時，那么5000行爛代碼的重構可能要花2、3天。要對一個失去控制的工程做重構，往往還不如重寫更有效率。
而拋開具體的重構方式，從受益上來說，重構也是一件很麻煩的事情：它很難帶來直接受益，也很難量化。這里有個很有意思的現象，基本關于重構的書籍無一例外的都會有獨立的章節介紹“如何向boss說明重構的必要性”。
重構之后能提升多少效率？能降低多少風險？很難答上來，爛代碼本身就不是一個可以簡單的標準化的東西。
舉個例子，一個工程的代碼可讀性很差，那么它會影響多少開發效率？
你可以說：之前改一個模塊要3天，重構之后1天就可以了。但是怎么應對“不就是做個數據庫操作嗎為什么要3天”這類問題？爛代碼“爛”的因素有不確定性、開發效率也因人而異，想要證明這個東西“確實”會增加兩天開發時間，往往反而會變成“我看了3天才看懂這個函數是做什么的”或者“我做這么簡單的修改要花3天”這種神經病才會去證明的命題。
而另一面，許多技術負責人也意識到了代碼質量和重構的必要性，“那就重構嘛”，或者“如果看到問題了，那就重構”。上一個問題解決了，但實際上關于重構的代價和收益仍然是一筆糊涂賬，在沒有分配給你更多資源、沒有明確的目標、沒有具體方法的情況下，很難想象除了有代碼潔癖的人還有誰會去執行這種莫名其妙的任務。
于是往往就會形成這種局面：
不寫代碼的人認為應該重構，重構很簡單，無論新人還是老人都有責任做重構。
寫代碼老手認為應該遲早應該重構，重構很難，現在湊合用，這事別落在我頭上。
寫代碼的新手認為不出bug就謝天謝地了，我也不知道怎么重構。
5.寫好代碼很難
與寫出爛代碼不同的是，想寫出好代碼有很多前提：
理解要開發的功能需求。
了解程序的運行原理。
做出合理的抽象。
組織復雜的邏輯。
對自己開發效率的正確估算。
持續不斷的練習。
寫出好代碼的方法論很多，但我認為寫出好代碼的核心反而是聽起來非常low的“持續不斷的練習”。這里就不展開了，留到下篇再說。
很多程序員在寫了幾年代碼之后并沒有什么長進，代碼仍然爛的讓人不忍直視，原因有兩個主要方面：
環境是很重要的因素之一，在爛代碼的熏陶下很難理解什么是好代碼，知道的人大部分也會選擇隨波逐流。
還有個人性格之類的說不清道不明的主觀因素，寫出爛代碼的程序員反而都是一些很好相處的人，他們往往熱愛公司團結同事平易近人工作任勞任怨–只是代碼很爛而已。
而工作幾年之后的人很難再說服他們去提高代碼質量，你只會反復不斷的聽到：“那又有什么用呢？”或者“以前就是這么做的啊？”之類的說法。
那么從源頭入手，提高招人時對代碼的質量的要求怎么樣？
前一陣面試的時候增加了白板編程、最近又增加了上機編程的題目。發現了一個現象：一個人工作了幾年、做過很多項目、帶過團隊、發了一些文章，不一定能代表他代碼寫的好；反之，一個人代碼寫的好，其它方面的能力一般不會太差。
舉個例子，最近喜歡用“寫一個代碼行數統計工具”作為面試的上機編程題目。很多人看到題目之后第一反映是，這道題太簡單了，這不就是寫寫代碼嘛。
從實際效果來看，這道題識別度卻還不錯。
首先，題目足夠簡單，即使沒有看過《面試寶典》之類書的人也不會吃虧。而題目的擴展性很好，即使提前知道題目，配合不同的條件，可以變成不同的題目。比如要求按文件類型統計行數、或者要求提高統計效率、或者統計的同時輸出某些單詞出現的次數，等等。
從考察點來看，首先是基本的樹的遍歷算法；其次有一定代碼量，可以看出程序員對代碼的組織能力、對問題的抽象能力；上機編碼可以很簡單的看出應聘者是不是很久沒寫程序了；還包括對于程序易用性和性能的理解。
最重要的是，最后的結果是一個完整的程序，我可以按照日常工作的標準去評價程序員的能力，而不是從十幾行的函數里意淫這個人在日常工作中大概會有什么表現。
但即使這樣，也很難拍著胸脯說，這個人寫的代碼質量沒問題。畢竟面試只是代表他有寫出好代碼的能力，而不是他將來會寫出好代碼。
6.悲觀的結語
說了那么多，結論其實只有兩條，作為程序員：
不要奢望其他人會寫出高質量的代碼
不要以為自己寫出來的是高質量的代碼
