書寫可維護代碼的重要性

本文是我的對書寫可維護代碼的一點點思考。

（一）整潔代碼的重要性

《代碼整潔之道》、《實現模式》、《設計模式》、《重構》、《重構和模式》這些書中，都指出書寫可維護代碼是十分重要的。想必每位開發者都能說出幾條緣由吧，這裏我也梳理一下本身的邏輯。

什麼是好代碼？歸納地說就兩條：第一，能實現需求，第二，可維護性高。

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…