本文是個人對書寫可維護程式碼的一點點思考。
（一）整潔程式碼的重要性
《程式碼整潔之道》、《實現模式》、《設計模式》、《重構》、《重構和模式》這些書中，都指出書寫可維護程式碼是十分重要的。想必每位開發者都能說出幾條原因吧，這裡我也梳理一下自己的邏輯。
什麼是好程式碼？概括地說就兩條：第一，能實現需求，第二，可維護性高。
1.1 能實現需求是第一要滿足的
程式設計師工作的本質是程式碼交付。這是我們工作的基本，若程式碼不能實現需求，肯定不是好的程式碼。這一點是無需置疑的，任何其他方面的工作，都需要為它讓路。因此有很多公司，把這一點作為績效考核的唯一要求。
1.2 書寫可維護性程式碼是老鳥和新手的本質區別
怎麼衡量自己成長了呢？有一個看似開玩笑的方法是，當你去看自己以前寫的程式碼，如果你覺得垃圾時，就表明自己進步了。
那麼，什麼樣的程式碼是可維護性高的程式碼呢？《程式碼整潔之道》給出的觀點是，程式碼可維護性與其整潔度成正比。當然也給出了整潔的程式碼是什麼樣的，並給出了原則和各種細則。在我看來，作者只是把“可維護”重新定義成了“整潔”而已。
我總結的可維護性程式碼的三大特點是：
- 可讀性高。
- 可擴充套件性高。
- 可複用性高。
1 程式碼要可讀性高
《程式碼整潔之道》中說，如果你把敲程式碼的過程進行錄屏，就會發現大部分時間都是讀程式碼的過程。
往往大部分程式碼都是自己最近寫的，因此沒有理解上的難度。此時，我們很少去關注程式碼是否具有高可讀性。變數名字叫什麼無關緊要，是否有註釋也無關緊要，是否有優化的空間更無關緊要。我們下意識的心理邏輯是這樣的：反正都是自己寫的程式碼，自己看得懂，明天看這個程式碼的人還是自己。而完成任務是首要的，畢竟公司看重的還是任務完成指標，因為這點是影響績效。
對待自己的程式碼是這個態度，而對待他人的呢？對於非自己寫的程式碼，比如要使用別人的介面時，基本上會問一下同事，“發起某某請求的方法，在哪個檔案，叫什麼名字？”，因為我們知道這樣做來得快，要自己去找，那可費勁了。
但是一直這麼做會有問題的。正如《第五項修煉》說的那樣，你要解決的問題，很可能於來自上一次其他問題的解決方案，其實它們原本就不該出現。
問題出現的場景一般都發生在維護時。自己寫的程式碼，半年後能會去讀它的人仍可能是你本人。屆時，你會想，自己當初為啥要這麼寫呢？那麼長的一坨，竟然還沒有註釋，當初的思路又是什麼呢？這個變數名是什麼意思呢？恨不能穿越回過去，告訴自己：你現在的偷懶，以後還會由你來買單的。
最可怕的是，當你去維護別人寫的垃圾程式碼，心裡罵著別人時。其實，很可能現在的你同樣會坑以後的另外一個人。當你每敲一段程式碼時，都要想一想那句名言：
程式碼是給人看的，只是偶爾執行一下。
2 程式碼要可擴充套件性高
寫出來的程式碼，不會一成不變的。在迭代過程中，可能會多次修改。所以寫程式碼時，不能只聚焦於眼下，只要完成功能就行了。想一想，如果一個月後，Boss說你要在某某功能模組裡新增一個小功能時，要怎麼能快速定位到你的程式碼。此時就要考慮程式碼的可讀性以及設計模式了。
這一點，其實目前流行的mvvm框架，本身就是為了解決此問題的。就跟畫畫一樣，別人畫好了輪廓，我們只需要去著色就行了。高內聚低耦合的程式碼，一直是我們追求的設計目標。封裝變化、多用組合等思想，良好的框架在這點上幫我們解決了不少問題。
3 程式碼要可複用性高
既然一些程式碼能夠複用，說明它們能解決一些通用的問題。比如流行的框架和庫，本身就是讓別人複用的。可複用也是設計模式存在的原因。你遇到的問題，大多少數時，前人就遇到過，並且給出了通用方案。而我們要做的就是“拿來主義”。
具體到專案時，專案結構必然要分層，底層程式碼自然要抽出來。這個道理我們都懂。《程式碼整潔之道》中說，重複是軟體一切邪惡的根源。所以，Dont repeat youself。
（二） 為什麼我們寫出的程式碼不是整潔程式碼
養成寫整潔的程式碼，需要形成習慣。但是新習慣的養成就是要克服掉舊習慣。大道理，誰都懂。難的是，知行合一。為何自己寫的程式碼那麼糟糕，我們能找到兩個常見的原因是：沒時間和沒反饋。
2.1 沒時間
最常找的理由之一就是，時間不夠。
我們前端工作的時間比例大致是這麼劃分的。書寫程式碼和除錯程式碼的比例大概是3：7。
想必我們都有這種經驗。要實現一個頁面，不到兩三個小時就能實現大部分功能，然後發現一些小問題，即那些難纏的bug，此時我們剩下的大部分時間都在對付這些可惡的“蟲子”，程式碼改來改去。有時一個問題的定位、技術調研和與人溝通時間就能佔據整個下午。真等到解決完這些小問題時，也差不多到下班的時間了。
這是我們常見的一天裡，沒有讓程式碼整潔的時間。
專案完事了，馬上開始又啟動下一個專案。當你愁眉苦臉地思考當前如何完成功能時，此時你被通知要維護一下之前的專案。再次修改自己之前的程式碼，你可能會感慨，以後這塊需要好好修正修正。可惜手裡專案太緊了，沒有時間。事實上通常是真沒有時間了。
這是我們專案週期間，沒有讓程式碼整潔的時間。
2.2 沒反饋
比寫糟糕程式碼的更糟糕的事情是：你不知道你寫的程式碼很垃圾。每個人都很忙，沒人幫我看程式碼，我也覺得自己寫得不好，但我又不知道如何改進。這是很多新人的困境，沒有反饋的練習，練習再多也成不了高手的。
（三） 如何書寫整潔程式碼
沒時間，會導致程式碼寫不好，程式碼糟糕，會導致更沒時間，這是一個死迴圈。
沒反饋，就不知如何提高程式碼質量，進而一直這樣持續下去。把第一年的經驗再重複幾年。這是一汪死水。
如何破這個局呢？
3.1 微習慣
其實，程式碼要保持整潔，就跟你屋子裡保持清潔的方法一樣。讓屋子清潔很容易，你只需要進行一次大掃除就可以了。但是要一直保持清潔，那麼需要養成微習慣。看完的書，不能隨便在桌子上一擺，要換洗的衣物，要放到固定的地方等等。每一個都是微習慣。
從小事做起，比如變數名或方法名。好的程式碼是不需要大量註釋的，因為好的變數名稱就起到了註釋的效果。《程式碼整潔之道》一書中，給出各個方面的整潔程式碼是什麼樣的。比如函式該怎麼寫，註釋該怎麼寫等等需要養成的微習慣。
3.2 清單思維
養成微習慣是重要的，但如何養成呢？答案是清單思維。
清單，除了我們熟悉的todo list之外，還又一種核查清單。在清單上列出哪些我們需要注意的地方，然後我們一條條去核對。做到了就打勾，這點對形成微習慣很有幫助的。
比如，我每次出門都不會丟三落四。因為我記住一句話，伸手要錢買菸火。
這裡，我建立了一個核查清單：身份證、手機、鑰匙、錢包、煙和打火機。同樣的道理，在我們日常程式碼的開發中，提交程式碼之前，拿出清單對一對，直到自己養成習慣。
3.3 code review
旁觀者清，當局者迷。從人性的角度來說，每個人或多或少都有雙向標準。相對於自己，要求別人就嚴苛一點。這一人性卻可以為我們所用。同事之間進行程式碼回顧，是對每個人都有好處的。開始時看似浪費時間，其實減少日後不該浪費的時間。也可以配合利用核查清單，畢竟每個人對一個個具體的核查點的理解程度是不一樣的，這樣能幫助彼此更快地成長。而不是你向他人請教時，只會得到”你去看某某書就行了“這樣的答案。
本文完。
整潔程式碼的核查清單： github.com/ryanmcdermo…
vue程式碼的核查清單： cn.vuejs.org/v2/style-gu…