盲目自信，自認為已經敲了幾年代碼，還看什麼整潔之道啊。我那可愛的書架讀懂了我的心思，很明事理的保護起來這本小可愛，未曾讓它與我牽手
最近項目中的 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的事？
- 你是怎麼應對那些不好的問題的？
歡迎在留言區讨論，你們項目中的情況，你是怎麼看待代碼整潔這個問題的