作為程序員，寫代碼是我們工作的主要內容。最初，看到代碼庫有些代碼寫的混亂，我也會有些反感，甚至是埋怨前輩為何不寫好點。后來我發現我太天真了，寫出高效整潔代碼真不是一件容易的事情，寫代碼就是在挖坑，給后人和自己踩的坑。

寫了一年代碼，我以親身經歷在此告知后輩，有整潔強迫癥的人慎當程序員。為什么這么說呢？是什么讓程序變得混亂呢？

1、歷史遺留問題

之前見到有人吐槽12306的前端代碼，吐槽他們用Jquery版本是1.4.2，Jquery最新版本是2.1.1（2014.9.12）。若是去扒代碼的話，你會發現很多公司用的Jquery版本都不高，京東主頁用的是1.2.6（2014.9.12）。這就是歷史遺留問題，由于版本之間多多少少會有些差別，升級版本有著不可估量的風險，且項目越大風險越大。為了規避風險，再加上代碼跑著沒問題，一般來說負責人也就不愿去冒險升級了。不去升級會導致什么問題？一些比較新的方法不能用，這對開發人員來說有時是挺痛苦、挺無奈的。

上面只是歷史遺留問題的一種情況，實際中還有很多，比如公用的方法邏輯雜亂冗余卻沒人敢去清除整理、系統架構過時、APP升級后對歷史版本的兼容支持與維護等等。總之，寫代碼時你會遇到各種歷史遺留問題。

2、系統架構的問題

實際來看，系統架構最初就考慮全面挺難的，需要經驗極其豐富的架構師，即便是這樣也只能保證在一定時期內架構滿足需求。

拋開業務增長致架構無法滿足需求不談，有多少公司敢站出來說自己系統架構完美呢？一來，很多事都是需要權衡后取舍，技術也不例外，會出現為了解決一個問題引入另一個問題的情況。二來，互聯網公司整體的浮躁，恨不得有想法就開始做，且新的技術不斷出來，有些人管理為了追新不調研清楚就開始用，引入到系統架構之中，但新技術的引用往往會帶來未知的風險。一旦引入的新技術在系統架構中出現了問題，造成的后果是極其嚴重的。這里不是說新技術不能用，是要慎用。

總結來說，系統架構問題主要原因有三點。一是有些系統架構搭建時需要根據項目需求做一些取舍，致在項目中做部分處理時較麻煩。二是系統架構師經驗不足。三是有些項目管理者不夠負責，想一出是一出。

系統構架問題也是代碼混亂的原因之一，且問題一旦出現就不是幾個程序員能夠扭轉的。

3、需求本身復雜

有些需求本身就很復雜，需要眾多人分工協作來完成。這種大項目的代碼邏輯注定不會簡單，加上是由多人完成，也就很少有人懂得所有邏輯。

對于互聯網企業來說，人員變動頻繁，項目開發完，甚至是開發一半是說不定就有人走了，最恐怖的是走的人離開時連文檔都沒有留下。

遇到這種情況，接手的人只能的去扒代碼找邏輯。非碼農絕對不會了解扒代碼找邏輯的痛苦。若是代碼寫的規范還好一些，若是寫的不規范，再加上不是出于一個人之手，那對接手的人來說絕對稱得上災難了。

4、項目催得緊

互聯網講究的是快，仿佛不快就會死。對于這種情況，不知道真的是‘天下武功唯快不破’，還是老板壓榨員工勞動力的借口而已。

快，必然導致項目迭代速度快，需求被催來催去，產品、測試以及經理都在后面催。遇到這種情況雖心里不爽，但我知道產品、測試以及經理也不容易，能夠理解就理解，畢竟大家也都是為了工作。

需求被催的緊會導致代碼質量完全沒有保證。由于時間不夠，看到需求想到實現方案就要開始動手寫，根本沒時間去考慮是不是最優的，后續的擴展性，這樣寫了會不會引起其他的問題等等。

由于最初沒有時間考慮周全，開發時有可能會遇到一些完全沒有預料到的問題，但仍舊是由于沒有時間，根本沒法返工重新設計，只能隨便找一個能夠解決問題的hack方法解決了。

由于項目時間緊，開發文檔幾乎不會有。一來可能是項目一個挨著一個根本沒時間寫。二來是需求做完了，開發都不清楚代碼為何要那樣寫了。因那段代碼可能是開發連續高負荷工作十幾個小時下寫出來的，那段時間開發的精神是恍惚。也許有人會說精神都恍惚了，為什么還不去休息啊，只能說需求不允許，開發比較敬業，不是老油條。

由于記不清當時為什么那樣寫，加上人都是有惰性的，沒有人催促自然就不會去從倉促趕出來的垃圾代碼扒邏輯了，況且一般來說開發根本沒有完全的清閑時光，自然也就不會去補文檔了。

除了文檔，項目需求被催得緊也會導致代碼注釋不全。編碼習慣好的可能會隨手寫些注釋，編碼習慣一般的就極有可能由于時間倉促而不寫注釋了。

項目需求被催得緊也會造成代碼review形同虛設。因代碼還未提交就有一幫人在后面催，想一想這樣的情況還能愉快地走代碼review嗎？但對于新人來說，代碼review是規范代碼風格的必要步驟，是從師父的review中學習編碼技巧的重要途徑之一。

前三種令代碼不整潔的情況在一定程度上不可避免，只能做到盡量的減少其對代碼的影響，但催促項目需求這一點完全可以避免。

雖可避免，但從實際來看很少有互聯網公司去注意這一點，似乎大家仍舊覺得只有快才能在‘拼殺’中勝出，根本不去考慮代碼一旦混亂，后續的維護以及二次開發增加的時間、人力以及財力成本。

混亂的代碼爛賬也是跳槽的誘因之一，面對一份雜亂的代碼時間長了會覺得惡心，惡心到受不了也就走了。

有時快是勝出的關鍵，但盲目的追求快也就是急功近利了，而急功近利往往是在自掘墳墓。

5、特殊需求

有時業務或產品會提出一些常人難以理解的邏輯。這可能是由于業務或產品想要實現某個功能，但當前的系統架構、技術實現或開發時間不允許，他們又非要想實現該功能，于是便整出了一個最初需求的閹割版，馬不像馬牛不像牛的閹割版需求。

一般來說這種需求會擬定后續版本，但這就猶如程序員說這個方法先實現了，后續有時間再優化一樣，很少有下文了。造成這種現象的原因之一還是項目迭代快、時間不允許，另一點就是人的惰性。

除了閹割版需求稱得上特殊需求，還有可能是想一出是出，但根本不了解實際情況的老板，或者高層提出來的需求，一般來說由于提需求的人地位在那里，做事的開發與產品等也就很難拒絕做了。

6、好代碼需經驗：

寫出高效整潔的代碼一來是程序員需要很高的素質、很好的習慣，二來真的需要經驗。由于程序員缺口眾多，新人不斷的涌入近來。想一想網上之前的嘲諷段子“我們有一個非常好的idea，什么都準備好了，就缺一個程序員了”。從這一段子可以看出，有想法的人很多，但能夠將想法實現的程序員很缺。

指望著沒有經驗的新人能夠寫出高效的，邏輯性非常強、沒有任何冗余邏輯的代碼我覺得不現實。新人代碼風格不錯就是比較好的了。其實，這個時候若是有一個好的代碼review機制就非常好了，可是上面也提到了，由于種種原因，不知道多少公司的代碼review根本形同虛設。

7、代碼風格因人而異：

每個人的編碼風格都不一樣，習慣閱讀的編碼風格自然也就不一樣了。實際項目開發往往又是由多人共同完成的，也就造成代碼庫內會包含各種風格的代碼。風格一多，就自然有了與自己習慣風格不符的了。

雖這也算是閱讀代碼的一個障礙，但相對于上面的問題來說，它似乎不是什么大問題，除非遇到寫代碼完全不注意的人，再加上第四條提到的沒有人review。

總結：

以上算是介紹了代碼之所以雜亂的七點原因。說到這里，對代碼多多少少有些認識的人，你們應該了解我最上面的“有整潔強迫癥的慎當程序員”絕非危言聳聽了。

在這里，我再次告誡所有后輩們，若是你有整潔強迫癥，或者說你屬于急性子，慎入程序員這一條路。否則會被代碼虐千百次，虐的你心力憔悴，牙口胃口都不好了，心情也不好了，覺得整個世界都是灰暗的，人嘛，何必那么自找沒趣，對不起自己呢？

最后，說點工作中的感悟。工作大家誰都不容易，部門不一樣工作中考慮的出發點也就不一樣，所以相互理解非常重要。若是真的遇到強橫無理、不可以商量的，我會選擇離開，省的整天與這種人生氣添堵。工作畢竟是工作，令工作太過影響心情真的劃不來。