盲目自信，自認為已經敲了幾年程式碼，還看什麼整潔之道啊。我那可愛的書架讀懂了我的心思，很明事理的保護起來這本小可愛，未曾讓它與我牽手

最近專案中的 bug 有點多，改動程式碼十分吃力，每看一行程式碼都帶一句“這是什麼XX程式碼啊，真XX難改”，這樣持續了好幾天，有天晚上坐在書房回想這幾天發生的一切，仰頭定睛思考，我終於和它重新確認了眼神

股票見漲你知道買了, 汽車撞牆知道拐了, 孩子死了你來奶了, 大鼻涕到嘴你知道甩了, bug難改知道憤慨了

馬上翻開書，前言章節，映入眼簾的就是下面這一張圖

程式碼質量的唯一有效度量是：WTFs（what the fuck）/minute

真的太精闢了，這不就是這幾天我白天經歷的嗎？程式碼已然是 bad code 了，我們應該怎麼面對這種情況呢？

每個公司的規範還不一樣，本文是讀書筆記，不會說明太多的程式碼規範，只是闡明我們應該怎樣做或者抱著什麼樣的心態來寫程式碼吧

如果你看到這裡，我要引用書中的一句話：

第一，你是個程式設計師；第二；你想成為更好的程式設計師。我們需要更好的程式設計師

專業的態度

做國內專案/產品，通常都是指明deadline的，但是截止到deadline之前，需求量的多少是不固定的，說白了是“以deadline不變應需求萬變”，美其名曰「敏捷」

我們經常要面對短期內開發出大量需求的請求，很可能為了快速完成這些需求，胡亂的堆疊程式碼，上線之後一聲長嘆慶幸這個功能開發的結束。過了好久，有關這個功能的需求有所變化，重新檢視程式碼時，直接就 WTF 了......，再一看是自己寫的，你說尷尬不？

如果是因為任務多胡亂疊加程式碼，我們就應該在接受需求的時候提出我們的看法：

過多的需求在短期內上線的程式碼質量不能得到保證

假如你是醫生，病人要求你不用洗手就可以給他做手術，因為洗手浪費時間，你會答應嗎？醫生絕對會拒絕，因為你比病人更瞭解疾病和感染的風險。如果醫生照做，那是絕對不專業的做法

作為程式設計師，如果遵從了不瞭解混亂風險經理的意願，也是不專業的做法

“你以為可以不聽經理的？不聽經理的，是會被炒魷魚的”，經理能否聽的進去，我們都要提出我們的看法。提出多次還被無視，也不要灰心喪氣，繼續提出我們專業的看法... untile die, 為了部落

如果你有底線，守住就好；如果沒有，適應就好。只為很久之後看到程式碼說 WTF 時，避免主角是自己的尷尬

我們是作者

Javadoc 中的@author欄位告訴我們自己是什麼身份，我們是作者。如果類上沒有標註日期和作者，alibaba程式碼檢查工具會給出提示，就像這樣：

這裡建議大家在 IDE 中安裝該外掛，如果你不知道作為作者應有的規範，那就讓這個外掛輔助你吧

據統計，讀程式碼與寫程式碼花費的時間比例超過 10:1， 因為我們在寫新程式碼時會一直在讀舊程式碼，專案越到後期這個比例越明顯

我們是作者，就有責任和讀者做好溝通。每次寫程式碼的時候，記得自己是作者，要為評判你工作的讀者寫程式碼.

這些讀者可能是你現在組內的夥伴，也可能是將來要接管你的任務的新夥伴，避免別人嘴裡 WTF 的主角是你，定期 Review 自己的程式碼，你定會發現可以改善的地方，比如用策略模式更改過多的 if else等，程式碼整潔了，又學會了設計模式，豈不是兩全其美

心有餘，力要足

很多朋友說，我也想寫出整潔的程式碼，但是目前實力不允許啊。

寫出整潔的程式碼的功力不是一蹴而就的，需要持續不斷的學習和修正

學會設計模式，瞭解 RESTful 介面規範，瞭解命名規範，註釋，函式大小等等太多的東西都是書寫出整潔程式碼必不可少的知識，我們該怎麼辦？

還記得小時候寫作文的詞藻不夠用，老師讓摘抄好文好句。如果程式寫的不夠整潔，我們可以慢慢學習和模仿好的寫法與設計，慢慢改善和積累，有朝一日肯定能寫出高分作文的

不做破窗效應第一人

不要說現在的程式碼很爛了，沒必要再改善了，如果你是這樣的心態，即便一個全新的專案開始讓你去做，你也很可能會成為第一個打碎玻璃，帶來破窗效應的人。

如果嚴重一點說，大家都知道你寫的程式碼帶給別人的是一種負擔，你可能很難有開始一個全新專案的機會了

如果同事因改善你的程式碼帶來了一些意外的影響，請你不要抱怨甩鍋，這些改善就是修復玻璃的開始，終將會給團隊帶來極大的好處

總結

編寫整潔程式碼的路途漫漫，我們一起求索，推薦大家看下面這兩本書，你一定有有自己的發現，讓我們悉心照料我們寫的每一行程式碼

• 《程式碼整潔之道》
• 《阿里巴巴Java開發手冊》

靈魂追問

1. 工作上你接到過什麼奇葩要求？
2. 工作中遇到了哪些無奈或者你覺得XX的事？
3. 你是怎麼應對那些不好的問題的？

歡迎在留言區討論，你們專案中的情況，你是怎麼看待程式碼整潔這個問題的

---

相關推薦