整潔代碼湊談

湊談系列第二期…才不會告訴你湊談系列是用來刷SEO吸引潛在的ECO私服的白武士的哼

很多人知道代碼要寫得整潔,很多人知道有Clean Code這本書…
我不記得我有沒有看過這本書了,好像有,好像沒有,好像直到專程談一次整潔 代碼之道的一刻介於有和沒有之間… 好吧,你可以當我沒有。

篇幅有限。首先這本書的側重點不在於爭論花括號到底要不要開新行、用tab還是用space、縮進2格抑或是4格,老實說我很久以前真的以為是關於編排的。(如果 編排 = 整潔代碼,生活真是容易多了~)
GO語言自帶了編排器(formatter),然而編排好的代碼不代表它整潔(clena)。用上了再嶄新的工具,再尖端的框架,還是需要駕駛員(派駱駝)的。編排器充其量只是提醒的作用,一行是不是太長了? 括號是不是開太多了?

簡而明了的是,給所有東西起名,三思而後行。Think beyond twice for naming everything. 變量、函數、類別,統統要起名。如果起名實在起得太辛苦,那麼一定有東西是不妥當的,要打醒十二分精神重新檢視,十有九都是抽象(abstraction)問題。
名字不一定要短,嘗試使用縮寫只是逃避問題的一種手段,反而長的名字不一定壞。最後檢查一下拼字有沒有錯誤(還真有看過中國大陸人連github repo名字本身已經拼錯了XD)。印象中SagaECO的DB有一個名字就是串錯了,那要改回來是往往更費神的breaking change。

我的看法是註釋不一定要有,前提是有單元測試(unit test),有了的話只是更方便自動生成文檔(documentation generation)(特別是開源框架)。單元測試是一份不言而喻的約束。開源項目不懂用的時候,我習慣直接去github找對應的單元測試就知道回傳的特徵、副作用、哪些能做、哪些不能做,這樣做不必把邊界條件也寫進去註釋。
同時,如何調用這份代碼在單元測試的上下文中更為清淅。在寫測試的時候很明顯看到是從哪一層向下調用,有沒有跨層,代碼是不是安詳地躺在它該躺的位置。

我覺得註釋太長本身就是一種壞味道(bad smell)。如果要花很大的篇幅去註釋一個屬性、一個方法,不是這裡有問題就是其餘的代碼有問題。

除去文檔型註釋,我強烈建議使用TODO註釋,用來充當特性的進度條不提,立會時間很短暫,非必要的技術性問題,不需要每事寫進backlog。有時候若多於一人要碰那個區域的代碼,視情況寫在源碼搭配slack食用。
另外,如果因為有bug或者改動而註釋掉代碼,請附上解釋。看過有項目很搞笑,明明有版控卻不敢刪掉根本沒有用的代碼,大大加重日後重構時的工作量,拿石頭砸自己的腳。

暫且不談何謂整潔之道。更多時候,困境不在於整潔之道本身,心理反倒是一道坎。工作環境代碼本身很糟糕、同事很愛推卸工作、公司不尊重技術。要是把代碼寫得清楚,不出錯、容易修改,那麼失去價值的自己明天就會被辭退。是的,明天就會被辭退。嗯,如果我是你我寧願離開,這種公司沒必要待著~ 為甚麼? 對公司來說,你和公司腐敗的文化不合,失去了利用價值; 另一方面,你的技能價值卻提升了。

不過,從來沒有說過沒有code review就應該跑路。如果你從來沒有做過code review不要緊, 畢竟沒有那麼多的公司有。如果你真的很想嘗試一下,開源社區的門永遠為你打開。

雖然寫得很像嘩眾取寵的Medium文章一樣,You actually don’t need code review之類的,騙幾千個讚,讓無數公司繼續在壞代碼中沉淪。與上一篇八二定律湊談一樣,對於擅用知名字詞包裝和推銷歪曲觀念作出批判。

Code review僅僅是守尾門。與論文發布之前的peer review一樣,同行不會把你做過的實驗用自己的研發經費自己再重覆一遍去檢查你的論文的真確性。假若你是修改reviewer的代碼,reviewer對這裡很熟悉,必然會很警惕,可能會抓到包;
除此之外,LGTM不會告訴你如何把代碼寫得更加好。不是他人不告訴你,是其他人不懂你遇到的處境也不好給意見的呀。
所有進步的契機皆是自發的,自我要求要高

出道一年,見過兩位分別CS在讀和應屆畢業生寫過”DoXXXAndYYY”: 壞名字把糟糕的抽象表露無遺。花了一天的時間稍為pair programming指導過後者之後,後者雖然就職不久,代碼已經能pull到master裡去了。所以問題可能大半落在於到底要不要去帶而不是能不能帶得動。公司沒有人會carry你,你要carry自己。

殘酷的現實是沒有一份代碼是純潔的(參見ECO私服剖析:SagaECO深入淺出系列),沒有人會把房間整理好。每個人從新手階段以來必然會寫過很多糞作,初創公司的產品也必然是趕工做出來的殘次品。能出於污泥而不染,在於敢於正視、敢於面對、敢於重構、敢於重寫。除了hello word和fuzz-buzz,我記憶之中我沒有代碼沒有寫過第二次。即使不得已要寫壞代碼,代碼應有的本來面目要時刻映入心中。

Trackbacks & Pings

  • Fizzbuzz湊談 - AsAlma :

    […] 相信大家有聽過傳說中的Fizzbuzz問題,全地表最因難的問題。上一篇”整潔代碼湊談“的文末有提到不應在Fizzbuzz問題紏纏clean code,在此解畫。 […]

    5 years ago

Leave a Reply

Your email address will not be published. Required fields are marked *