業餘大叔程式心得筆記#6:程式碼的風格與個性/葉光釗

年輕時加入這一行之後,很快就看出「寫程式碼」跟「寫文章」其實是很類似的心智活動;變數的命名、區塊的縮排、甚至是關鍵字的選擇,都反應著作者的行事風格。

看程式碼看久了,會有一些有趣的觀察。

有的人敷衍了事(變數都是i、j、k、m之類,也不縮排)、也有的規矩謹慎(每個區塊都排得整整齊齊);到後來經驗夠了,甚至可以從第一眼看到的程式碼,就判斷出你面對的是多大的麻煩。

還有一種情況,是天才型的程式碼(正確說法應該是「天才工程師寫出來的碼」);它的特點是超級簡潔,即使是你已經很熟練的語言,都會簡潔到「不努力想想就實在不知道它的作用是什麼」的程度。

不過看懂了之後,你會不由的稱讚他的聰明才智;這些人可能平常走在路上都在想「路要怎麼走會比較近」。

還有一種也是讓人讚嘆的,是將程式結構環環相扣到緊密無比;你要將整個程式或大模組看通,才知道他的某個細節為什麼這樣設計。好像在看推理小說,直到看到結局才恍然大悟:原來是這樣!

到了後來,看的程式碼大部分是多人分工寫的。原本以為大公司對風格要素要求比較嚴謹,所以碼的結構應該都很相近;但我看到的反而不是這樣,一看就知道是很多不同人寫的。

後來想想,也許是因為公司組織以產出為第一優先,並不侷限不同性格的人進來寫碼,只要程式能正常運作就好。

另一方面,最近常常觀察到一些開放原始碼專案,雖然有很多人參與,但程式碼調性反而很統一;完全看得出來,這些是志同道合的人一起寫的。

我的心得是,入行時總認為應該是「工作影響人的性格」,這樣看來反而是「不同個性的人會選擇不同的領域」呢。

這樣簡單的道理花了我幾十年來體認,不得不自承魯鈍。

Code Review的愛恨情仇

關於code review(程式碼審查)的觀念,只要是程式設計師應該都懂:即使你已經完成九成九的程式碼,一定有些地方沒注意到、邏輯不夠完整、或是有流程走不到的盲點。

這時候,必須有一個客觀公正的資深人員將這些地方點出來,才能讓我們的程式趨於完美、無可挑剔。

聽起來這是一件重要、而且必要的事情,應該每個以寫程式為工作的人都會欣然接受。可是在現實生活中看到的開發者(其實包含我在內),對code review要不是能躲則躲,不然就是盡量拖延,不到最後一刻不會去面對,就好像小孩對紅蘿蔔莫名的討厭一樣。

有的開發者會說,「用程式做code check檢查就好啦」。這真是自欺欺人:明明知道機器只能做最粗淺的檢查,還要這麼想;我還沒看過哪個厲害的編譯器,有辦法將程式中的邏輯錯誤揪出來的。

另外有些人說,「什麼時代了,何必做面對面的code review,遠端看就好啦,當面做真是沒效率!」

可是就我的觀察,找出關鍵問題的code review,都必須一來一往、雙方一同瞭解程式碼的時空背景、來龍去脈,才能對症下藥;單方面的檢查並不會節省多少時間,可能反而更耗時。

依我之見,會有這樣的情形,多半肇因於「NIH症候群」(「not invented here」);用白話說,就是「武無第二,文無第一 」[footnote]關於「NIH症候群」,請參閱〈文化差異如何影響企業融合──惠普併購阿波羅電腦的故事〉一文。[/footnote]。

不管是資深還是資淺,只要是人,都會高估自己產出的價值;尤其越聰明的天才,這種情況越明顯。所以有的時候會越review越火爆,要不是「你是誰啊,居然對我寫的程式有意見?」,就是 「你也太遜了,居然把程式寫成這樣?」。

不用多,只要碰到一兩個這樣的案例,我就不信有人還會對code review會有好感。

我的心得:要寫出好程式,就得跟所有的成功人士一樣:EQ 要高、要有耐心。

若我是review的那一方,點到就好、得饒人處且饒人;如果我是被review的那一方……唉,不就是一份工作嗎?