程式設計師的美德

程式設計師的美德,真是一個值得每個程式設計師釘在牆上的經典,所以決定要寫篇文章讓自己不要忘了。

「程式設計師的美德 (The Virtues of Programmer)」是Perl的發明者之一的Larry Wall在歐萊禮的駝峰書 Programming Perl中提到的,他列了三項美德分別是:懶惰(Laziness) 、沒耐心(Impatience)、自大(Hubris),這三項ㄧ般都是用在負面的地方的詞,為什麼又會變成程式設計師的美德呢?讓我們細說從頭。

↓ 大咪眼睛大大的超可愛的~沒表情還真是個小帥哥阿
IMG_6795.jpg

程式設計師的美德

以下是我大略的原文翻譯,原文可以在wiki中找到。如果有不正確或不精準的地方,也麻煩給我feedback。

  • 懶惰(Laziness):懶惰的程式設計師會為了減少整體開發所消耗的心力而撰寫高品質的程式碼。而且撰寫文件讓你不需要回答許多問題。[註:所以懶惰的程式設計師會減少重複的程式碼(redundant code)、會考慮可重用的架構(reusable)]
  • 沒耐心(Impatience):怒氣讓程式設計師覺得電腦程式實在跑太慢了。這讓程式設計師撰寫程式不單單只考慮程式的需求,而是考慮得更深遠。[註:所以沒耐心的程式設計師,會考慮程式的運行效率等非功能性的需求]
  • 自大(Hubris):這種極端過度的自信讓程式設計師不想讓別人看到他所撰寫或維護的程式有任何缺點。[註:所以自大的程式設計師,會撰寫讓人無可挑剔的程式碼]

以下開始抱怨…可略過…

失德的程式碼

我眼睛盯著專案的重複了幾十處的程式碼,抓狂的對著螢幕怒吼著:「這就是這個程式設計師不夠懶阿!」。工作上看到了某個案子的程式有著大批大批的redundant code、可以想見當初的狀況就是完全沒有考慮重用就直接把package裡面的source複製貼上,然後再改裡面的code。也許,當初是為了「快」所以複製了第一段程式碼。這樣只要修改一下設定檔就可以使用了,第一時間感覺起來好像「比較快」,所以有第一個、第二個到十幾個,當第一扇窗戶破掉的時候不快點處理,接著旁邊的窗戶很快就會開始破掉! (請參考破窗理論),不斷複製貼上的結果很快其他窗戶就全破掉了。

這個程式設計師不但不夠懶,沒考慮自己後續維護的時間、只想到眼前這樣修改比較快,可是麻煩的垃圾全部都在後續維護的時候才慢慢發酵。而且也不夠自大,所以編寫出來的程式讓我看了很怒。而且也太有耐心,這個程式跑得真的慢透了,啟動要跑三小時以上,難道都沒有人覺得討厭嗎?(註:而且三小時是我turing過系統的效率之後,沒turing過之前跑一跑會自己自動葛屁)。

破窗之後?

由於程式非常分散,每個package的code有點像又不大像,所以想要merge也是很困難的任務,所以現在要改邏輯或turing performance都非常困難,修改起來也相當沒有信心。此時我會陷入一種兩難,一個就是想要先把程式的架構搞好,即重構(refector),但是怕又弄出了一堆Bug,因為程式會改有差異一是有原因的,不過不是你改的也很難確定到底是什麼原因,就算是自己弄得日子久了怕也忘光了。這麼多分散的程式,全部無腦的merge起來也可能會出更多的trouble,再說要整理所要多花的時間究竟有多久實在很難評估。所以大部分的時候,我還是選擇依照這個個亂搞的架構繼續亂搞,減少變動的幅度也減少出trouble的機會。所以像我現在要改一個邏輯就必須改幾十個地方,但是就算是這樣也還是比我把整個架構翻掉重改還快。

出了什麼問題

也許,有先前弄過這個專案看到會很不滿,在此深深的一鞠躬,我不認為這是哪個個人的錯,至少不全然是。我沒有責怪的意思,而且我也是繼續把窗戶弄破的幫兇,而且我剛剛也說了,通常我會選擇繼續沿用糟糕的架構把功能做完,而不是改善架構。也許後來維護的人,也許也會同樣的對我有怨念。我認為,會出現破掉的窗戶的理由只有兩種:

  1. 技術能力不足:先前波波醫師吵得沸沸揚揚之際,有人說「沒有醫術、哪來的醫德」,當程式設計師的技術能力不夠的時候,要完成功能已經是不容易了,哪還有的心思去思考什麼其他的問題呢?當然無法撰寫出有品質的程式!更無法能有什麼德行了。首先是一個地方破了一個窗,之後整個系統都有可能崩潰。
  2. 這是組織的政治與文化的問題:對許多程式設計師而言,撰寫更精巧、更漂亮的程式碼也是一件振奮人心的事情,有些人甚至將之視為一種「修練」,然而去實作或修改某些功卻並非總是那麼的有趣。所以,程式碼的品質變取決於組織的文化,而組織的文化又是因為高層的態度而形成的。有些組織高層很注重程式的品質,甚至在政策上訂有各種規範與標準,由此形成的文化就會趨向高品質邁進(當然阿,也有規定太多寫東西綁手綁腳的,這又是另一個問題了)。然而另一個極端,如果組織高層根本就不管你怎麼做到的,形成「花時間去提高程式碼的品質」這件事情變成曲高和寡,而變成「要多花時間弄出好程式的請自己多花時間加班」在沒有胡蘿蔔更而有木棒的情況下,大多數的人趨向用quick & dirty的方式把功能delivery,這樣又有多少人可以真正的成為有德之人呢?如果文化已經形成,旗下的程式碼普遍都是亂寫的時候,想要改善恐怕也來不及了吧?當組織所累積的所謂資產都是這種破窗,那所謂的實力到底是什麼?

嘮叨了一堆,事實上是抱怨的成分居多,一方面也警惕自己千萬不要把自己的基礎建設搞得窗戶全破了。