盲目自信,自認爲已經敲了幾年代碼,還看什麼整潔之道啊。我那可愛的書架讀懂了個人心思,很明事理的保護起來這本小可愛,不曾讓它與我牽手程序員
最近項目中的 bug 有點多,改動代碼十分吃力,每看一行代碼都帶一句「這是什麼XX代碼啊,真XX難改」,這樣持續了好幾天,有天晚上坐在書房回想這幾天發生的一切,仰頭定睛思考,我終於和它從新確認了眼神
設計模式
股票見漲你知道買了, 汽車撞牆知道拐了, 孩子死了你來奶了, 大鼻涕到嘴你知道甩了, bug難改知道憤慨了
立刻翻開書,前言章節,映入眼簾的就是下面這一張圖ide
代碼質量的惟一有效度量是:WTFs(what the fuck)/minute
真的太精闢了,這不就是這幾天我白天經歷的嗎?代碼已然是 bad code 了,咱們應該怎麼面對這種狀況呢?函數
每一個公司的規範還不同,本文是讀書筆記,不會說明太多的代碼規範,只是闡明咱們應該怎樣作或者抱着什麼樣的心態來寫代碼吧工具
若是你看到這裏,我要引用書中的一句話:學習
第一,你是個程序員;第二;你想成爲更好的程序員。咱們須要更好的程序員
專業的態度插件
作國內項目/產品,一般都是指明deadline的,可是截止到deadline以前,需求量的多少是不固定的,說白了是「以deadline不變應需求萬變」,美其名曰「敏捷」設計
咱們常常要面對短時間內開發出大量需求的請求,極可能爲了快速完成這些需求,胡亂的堆疊代碼,上線以後一聲長嘆慶幸這個功能開發的結束。過了很久,有關這個功能的需求有所變化,從新查看代碼時,直接就 WTF 了......,再一看是本身寫的,你說尷尬不?
3d
若是是由於任務多胡亂疊加代碼,咱們就應該在接受需求的時候提出咱們的見解:代碼規範
過多的需求在短時間內上線的代碼質量不能獲得保證
假如你是醫生,病人要求你不用洗手就能夠給他作手術,由於洗手浪費時間,你會答應嗎?醫生絕對會拒絕,由於你比病人更瞭解疾病和感染的風險。若是醫生照作,那是絕對不專業的作法
做爲程序員,若是聽從了不瞭解混亂風險經理的意願,也是不專業的作法
「你覺得能夠不聽經理的?不聽經理的,是會被炒魷魚的」,經理可否聽的進去,咱們都要提出咱們的見解。提出屢次還被無視,也不要灰心喪氣,繼續提出咱們專業的見解... untile die, 爲了部落
若是你有底線,守住就好;若是沒有,適應就好。只爲好久以後看到代碼說 WTF 時,避免主角是本身的尷尬
咱們是做者
Javadoc 中的@author字段告訴咱們本身是什麼身份,咱們是做者。若是類上沒有標註日期和做者,alibaba代碼檢查工具會給出提示,就像這樣:
這裏建議你們在 IDE 中安裝該插件,若是你不知道做爲做者應有的規範,那就讓這個插件輔助你吧
據統計,讀代碼與寫代碼花費的時間比例超過 10:1, 由於咱們在寫新代碼時會一直在讀舊代碼,項目越到後期這個比例越明顯
咱們是做者,就有責任和讀者作好溝通。每次寫代碼的時候,記得本身是做者,要爲評判你工做的讀者寫代碼.
你這服務的我要給差評
這些讀者多是你如今組內的夥伴,也多是未來要接管你的任務的新夥伴,避免別人嘴裏 WTF 的主角是你,按期 Review 本身的代碼,你定會發現能夠改善的地方,好比用策略模式更改過多的 if else等,代碼整潔了,又學會了設計模式,豈不是一箭雙鵰
心有餘,力要足
不少朋友說,我也想寫出整潔的代碼,可是目前實力不容許啊。
寫出整潔的代碼的功力不是一蹴而就的,須要持續不斷的學習和修正
學會設計模式,瞭解 RESTful 接口規範,瞭解命名規範,註釋,函數大小等等太多的東西都是書寫出整潔代碼必不可少的知識,咱們該怎麼辦?
還記得小時候寫做文的詞藻不夠用,老師讓摘抄好文好句。若是程序寫的不夠整潔,咱們能夠慢慢學習和模仿好的寫法與設計,慢慢改善和積累,有朝一日確定能寫出高分做文的
不作破窗效應第一人
不要說如今的代碼很爛了,不必再改善了,若是你是這樣的心態,即使一個全新的項目開始讓你去作,你也極可能會成爲第一個打碎玻璃,帶來破窗效應的人。
若是嚴重一點說,你們都知道你寫的代碼帶給別人的是一種負擔,你可能很難有開始一個全新項目的機會了
若是同事因改善你的代碼帶來了一些意外的影響,請你不要抱怨甩鍋,這些改善就是修復玻璃的開始,終將會給團隊帶來極大的好處
總結
編寫整潔代碼的路途漫漫,咱們一塊兒求索,推薦你們看下面這兩本書,你必定有有本身的發現,讓咱們悉心照料咱們寫的每一行代碼
靈魂追問
你是怎麼應對那些很差的問題的?
歡迎在留言區討論,大家項目中的狀況,你是怎麼看待代碼整潔這個問題的
tan日拱一兵轉發在看也很贊