業餘大叔程式心得筆記#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的那一方……唉，不就是一份工作嗎？