軟體工程的實際體驗

上星期工作上出了一個包，牽連範圍之廣超乎了我的想像。由於這和我平常對自己的期許相去甚多，所以我對這件事的前因後果仔細地想了一下，我想在這裡我分享一下我的想法。

首先是關於態度的問題。這次出包的原因是在於我沒有對改動過的函式做實際的測試，只有用 code review 的方式來做驗證，以致於雖然之後有另一個工程師幫我重覆驗證過程式碼，但還是沒能抓到問題。我想這是我個人觀念上的偏差，我認為改動的範圍只有一兩行而已，所以不用做上機測試。但是這樣的危險在於，就算改動範圍再小，很有可能整個運作流程或是程式邏輯都會因此改變，因此光用眼睛是不可能確定沒有問題的，只有實際去跑跑看，才有辦法大致確認沒有問題。而更深一層來看這個態度的問題，我認為是因為我根本不覺得這個 project 的成敗和我有什麼關係，這真的是一件很可怕的事情。當然我不是說我在亂搞，而是說我沒有盡 100%的力氣來確定 project 的成功。俗話說：「當一天和尚敲一天鐘」，我想如果你沒有誠心誠意的話，那個鐘聲絕對不會響亮。換到軟體工程上來說，就是如果你對自己的工作沒有熱情、熱誠，沒有把這個程式當成是你兒子一樣看待的時候，那你的工作註定是個失敗。

其次是關於系統複雜度的問題。程式出錯的原因是在於少改了一行程式碼，以致於程式的邏輯不對，沒辦法執行某個命令。以前每次我碰到 bug 的時候，我都會想該如何用天然的方法避免以後犯類似的錯誤，當然 peer programming, unit test, code review 都是很好的方式，但我覺得那些都是被動式的避免錯誤，我認為主動式的避免錯誤應該是讓程式員幾乎沒辦法寫錯，或是說不用到執行的階段，早在 compile 的時候就可以抓到問題。如果應用到系統複雜度上而言，我覺得 Refactoring 就是一種主動式避免錯誤的方法。譬如說現在要修正一個功能，如果在系統內必須要同時在三個不同的地方做修正，那出錯的機率一定比只需要修正一個地方來得高，而如果一次必須要修正五個以上的地方，那幾乎保證一定會有錯誤了。所以盡量簡化系統的複雜度，我覺得是避免人為疏失的一個根本之道。當然這不是說程式員本身不用對錯誤負責，就像出了車禍，你不能只怪道路動線設計不良是一樣的道理。

再來是影響範圍的問題。我現在似乎有點理解為什麼我們系統的程式碼會長成現在這個樣子，我覺得原因在於沒有人想去更改現存的程式碼。為什麼呢？因為現存的程式碼雖然難看，但它是通過測試的，不管是公司內的測試部門，或是客戶的測試部門。而如果一旦你更動了其中的程式碼，你最好保證你變動的部分沒有問題，否則一旦出了差錯，所有人的第一句話一定就是「這個功能以前不是正常的嗎？為什麼現在不能用了？」這個時候你最好有很棒的理由說明為什麼你要更改原來的程式碼，而很顯然的，「我覺得原來的程式碼很難看」，不是一個很棒的理由。這種氣氛無形中便壓抑了程式員把現存程式碼修改得更好的動力。坦白講，一個公司在開發新產品的過程是很漫長的，越到開發的後期，牽涉其中的人便遇多，時間上的壓力也越大，而這種「程式碼沒有錯就不要改」的氣氛也就遇來遇濃厚，所以我想我們也許不能怪老程式員有這種心態，因為那也只是這種氣氛下的自然產物罷了。

最後是對於軟體工程的理解。一直以來，一些軟體創業成功的報導都說，一個公司只需要幾個軟體工程師就可以做出很棒的產品，像是最近被 Facebook 以十億美金收購的 Instagram ，一開始時只有四個工程師，而現在估值40億美元的 Dropbox ，更是從只有兩個人開始茁壯，這和一般軟體公司動輒上千人、上萬人，鉅細彌遺分門別類的設立各種職位，實在有天壤之別。對我而言，雖然這兩種公司都是靠軟體賺錢，但它們好像在不同的世界。而上星期我出包之後，更讓我好奇兩三個人的小公司要如何維持軟體的品質？而如果整個系統由我一人包辦會有什麼後果？還是說那些小公司都是由天才程式員組成，寫出來的程式碼又快又好又不會有 bug ？

附帶一提，我覺得「现代软件工程系列 软件 = 程序 + 软件工程」這篇文章寫得很好，讓我對所謂的「軟體工程」有更進一步的認識，尤其是其中的一段描述，根本就是在說我：

我来到软件公司上班后，发现公司以前同事写的程序真是垃圾，根本无法维护。我要推翻重写！后来一个老员工笑嘻嘻地告诉我，我们现在看到的程序，就是去年的新员工愤怒地推翻重写之后的结果，大家反映还没有以前的版本好用呢。

圖片來源

相關文章：

• 06/08/12 軟體工程的實際體驗 3
• 06/04/12 軟體工程的實際體驗 2
• 05/09/12 你的濃湯好喝嗎？
• 03/09/12 在屎堆中奮戰！