盲目自信，自認為已經敲了幾年代碼，還看什么整潔之道啊。我那可愛的書架讀懂了我的心思，很明事理的保護起來這本小可愛，未曾讓它與我牽手
最近項目中的 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 接口規范，了解命名規范，注釋，函數大小等等太多的東西都是書寫出整潔代碼必不可少的知識，我們該怎么辦？
還記得小時候寫作文的詞藻不夠用，老師讓摘抄好文好句。如果程序寫的不夠整潔，我們可以慢慢學習和模仿好的寫法與設計，慢慢改善和積累，有朝一日肯定能寫出高分作文的
不做破窗效應第一人
不要說現在的代碼很爛了，沒必要再改善了，如果你是這樣的心態，即便一個全新的項目開始讓你去做，你也很可能會成為第一個打碎玻璃，帶來破窗效應的人。
如果嚴重一點說，大家都知道你寫的代碼帶給別人的是一種負擔，你可能很難有開始一個全新項目的機會了
如果同事因改善你的代碼帶來了一些意外的影響，請你不要抱怨甩鍋，這些改善就是修復玻璃的開始，終將會給團隊帶來極大的好處
總結
編寫整潔代碼的路途漫漫，我們一起求索，推薦大家看下面這兩本書，你一定有有自己的發現，讓我們悉心照料我們寫的每一行代碼
靈魂追問
- 工作上你接到過什么奇葩要求？
- 工作中遇到了哪些無奈或者你覺得XX的事？
- 你是怎么應對那些不好的問題的？
歡迎在留言區討論，你們項目中的情況，你是怎么看待代碼整潔這個問題的
