軟體工程的實際體驗

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

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

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

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

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

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

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

圖片來源

相關文章:

廣告

About Weicheng Chu

創業中,微碧愛普科技 (www.weibyapp.com) 已婚, 有一對雙胞胎兒子, 現居住在美國加州、台灣台中
本篇發表於 軟體工程 並標籤為 , , , , , 。將永久鏈結加入書籤。

2 Responses to 軟體工程的實際體驗

  1. Ben Chen 說道:

    『更讓我好奇兩三個人的小公司要如何維持軟體的品質?而如果整個系統由我一人包辦會有什麼後果?還是說那些小公司都是由天才程式員組成,寫出來的程式碼又快又好又不會有 bug ?』

    哈,這就和你在rework工作大解放筆記3 – throw less at the problem裡面提到的一樣。『投入過多人力對一個產品所造成的影響幾乎可以用「災難」來形容』。

    一個點子比較好的做法會不會是由少數人一直不斷修改、精進改善。因為從頭寫到尾,產品和概念會非常的一致和完整。等這些基本的東西都確立後,規模化在加人。這個理論也不是我提的,其實在Peopleware就有提過軟體團隊最適合是外科手術團隊,只有一個人操刀,其實是可以看成只有一個人寫core code,像是Linux也是這樣Core一向都是由很小的團隊做。MacOS X / iOS的祖先freeBSD到目前也都還是維持在幾個人的小團隊。

    那種數千人的公司,產品都超難用、又貴。

  2. Weicheng Chu 說道:

    外科手術團隊好像是「人月神話」提出來的吧?
    我記得在某個地方有看到過 (好像是 Inside Apple),Mac OS 裡面的某個軟體是由兩個人負責的,我當時第一個反應是這麼複雜的軟體居然是兩個人寫的,可是後來想想也對,就是這麼複雜才應該少點人來弄,不然光是溝通就沒完沒了。

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s