Posted by Mr. Saturday

http://www.chrisrue.com/funcave/graphics/broken_window.jpg

Image from Funcave

最近寫程式明顯感覺到自己的 productivity 下降了點, 檢討一下, 發現自己很多的時間花在 code reading 上面, 開發的時間相對減少, 主要還是因為最近接到一些亂七八糟的 code, 幾乎沒有註解和文件可以看. 就算好不容易看懂了 code, 有時還要繼續往下猜, 原作者為什麼有這樣奇怪的 design decision. 結果就是在心中累積了滿滿的問號. 更糟的是, 直接問原作者, 他們也忘記自己為什麼當初要這樣子寫, 因為時間久了, 沒有文件和註解, 連原作者自己都忘記以前寫過什麼東西.

這讓我想起 “Clean Code” 這一本書裡面有談到破窗理論: 街旁大樓的一扇窗子破了, 路過的人不以為意, 窗子也始終沒有被修補好, 結果久而久之, 大家都習慣了那個破窗子, 路過的人開始往裡面丟垃圾, 調皮的青少年在旁邊的牆壁塗鴉, 甚至於連隔壁大樓的窗子也開始被打破了, 原本只是不在意的路人, 居然因此都紛紛加入了破壞者的行列.

我接到的這個東西就像是破窗戶一樣, 一開始就有些破洞了, 有大有小. 有趣的是, 這個產品後來有一些人嘗試加入新的東西, 其中一位工程師我從未見過, 他想要加入一項新的功能, 所以開始寫一些新的 code, 但是還沒加完就被拉去做其他的 project 了, 這項功能至今沒被完成. 我看了看他加的東西, 發現整個產品的原始碼品質更加惡化, 因為他照著原本就已經有瑕疵的設計和不良習慣, 繼續往上堆, 繼續寫新的 code, 繼續不寫註解和文件. 一大堆交代不清的 “TODO”, 好幾陀尚未寫完的 code, 就依附著整個產品這樣子存活下去. 我發現這個時候拿破窗理論來解釋這種現象真是再適合也不過, 這個工程師原本只是一個路人, 結果最後卻變成一個打破更多窗戶和丟垃圾的加害者角色.

文件和註解是一個軟體工程師最起碼的素養, 在這上面花的時間比 code 本身還要多是很正常的事情, 很多 coder 以炫技自豪, 心中隱約存著一種 “別人看不懂我寫的程式代表我很厲害, 要不然就是看的人太笨又懶惰” 的心態, 殊不知把程式寫得易讀易懂易維護才是真功夫, 才是真正寫出對世界有貢獻的東西. 無奈同樣的情況到了今天還是屢見不鮮, 究其原因還是人性, 對於維護者及後繼者的不貼心, 略過文件和註解以節省自己的時間, 讓自己很舒服地當個加害者的角色. 程式只要能跑, 就覺得可以交差.

最後付出成本的就是整個公司, 因為專案的交接因此付出巨大的成本, 軟體工程師把大部分的時間花在閱讀程式和溝通看不懂的地方, 而這些時間和溝通成本原本都可以透過最簡單的文件和註解來解決.

如果你發現自己的產品漸漸像是一扇破窗戶, 那麼是時候找一段時間, 把該補的東西補齊了.

喜歡這篇文章嗎? 給作者一點鼓勵吧!


  • http://topsy.com/mmdays.com/2010/09/25/broken_window_theory_in_software/?utm_source=pingback&utm_campaign=L2 Tweets that mention 軟體開發的破窗理論 – MMDays — Topsy.com

    [...] This post was mentioned on Twitter by 麒麟, 肯高同學, Dan Chen, gene7299_ipad, gene7299_ipad and others. gene7299_ipad said: 軟體開發的破窗理論: Posted by Mr. Saturday Image from Funcave 最近寫程式明顯感覺到自己的 productivity 下降了點, 檢討一下, 發現自己很多的時間花在 code readi… http://bit.ly/9vOnEp [...]

  • http://hermitmark.blogspot.com/ HermitMark

    在 The Pragmatic Programmer 的 Software Entropy 裡
    http://pragprog.com/the-pragmatic-programmer/extracts/software-entropy

    有另一極端的例子~ XD
    “But before they dragged their big, dirty hoses into the house, they stopped—with the fire raging—to roll out a mat between the front door and the source of the fire.
    They didn’t want to mess up the carpet.”

  • http://facebook.com/ChrisTorng1 ChrisTorng

    如果看「重構」的書的話,它說把程式碼寫得易讀,易讀到不需要加註解才是更好的方向。註解多的程式碼,有可能代表它真的很差…應該花時間重構該程式碼至易讀易維護,而不是寫註解說明該段程式碼有多差…

    換個方式講,一段不易理解的程式碼,優先要做的是重構成不需註解就能理解的優良程式。最後無法重構成容易理解的小部份程式,才需要加註解說明…比如說為了避掉某個無法控制的外部 bug,才把原本很容易直覺的寫法改成繞道迂迴的寫法…此時就必須寫註解,說明為何要這麼寫…

    該養成的好習慣,是寫易讀易維護的程式碼,而非寫更多的註解…

  • http://www.facebook.com/people/Hai-Feng-Kao/1208469573 Hai Feng Kao

    以一個工程師的角度而言,重構的確可以省下日後不少維護的工夫。
    但是以一個主管的角度來看,重構真的是必要的嗎?
    如果這個程式已經很穩定,那重構之後會不會產生新的bug,反而引起客戶的抱怨?
    如果這個程式的已經病入膏肓,要砍掉重綀,就需要考慮所花的時間和成本是不是真的值得?

    如果是已經很穩定的專案,客戶的要求的改動不大,那我會對破窗戶視而不見。
    但如果是要加一個大的功能進去,我會先把「相關的破窗戶」先補好再開始加新的功能,
    因為這樣做能讓我用更快的速度完成工作。
    為了重構而重構是沒有意義的行為。每個軟體都有破窗戶,重要的是學習何時該補窗戶,
    何時該和破窗戶共存。

  • ChrisTorng

    重構的書說,需要全面的自動化測試,才能安全地進行重構。

    所以如果有全面的自動化測試的話,重構不太會產生新的 bug。

    因此接下來可以分兩種狀況說明:

    若是自己所寫的程式,應該隨時重構,不要把程式寫爛了,才想回頭重構。

    如果是接收別人寫的爛程式 (或者要維護自己以前的爛程式),則要視該程式的重要性,是否需要常常變動而定。

    如果重要,而且常常需要變動,則需要重構。

    總之當然要評估重構困難度,重構後所得之益處後才決定。

    對我而言,小幅調整,大幅變更,以及砍掉重練都是重構的一部份。

    自動化測試,在有些程式容易做,益處也很大,另有些程式不容易做,益處不多,都是需要衡量利益得失來決定。

    我會傾向於現在先多花些時間寫自動化測試,重構,以期未來不會因修 bugs 或需求變更,導致程式碼越趨不穩定,難以維護。

  • http://www.facebook.com/people/David-Huang/727798904 David Huang

    重構很重要,但更重要的是由上而下的形成文化,才能成為制度。時間成本往往是這些制度的最大破壞者,只有長官堅持、Programmer自我要求,重構才能真正發揮它大刀的精神。

  • ChrisTorng

    所謂的文化,對我而言就是 Agile 精神

  • ChrisTorng

    所謂的文化,對我而言就是 Agile 思維。

    我自己是以推廣 Agile 為己志…希望整個公司,包括客戶都要認同並支持 Agile 理念:

    個人與互動 重於 流程與工具

    可用的軟體 重於 詳盡的文件

    與客戶合作 重於 合約協商

     回應變化 重於 遵循計劃

  • http://linlong3388.wordpress.com/2011/06/22/%e8%bb%9f%e9%ab%94%e9%96%8b%e7%99%bc%e7%9a%84%e7%a0%b4%e7%aa%97%e7%90%86%e8%ab%96/ 軟體開發的破窗理論 « 天馬行空-程式館
  • http://linlong3388.wordpress.com/2011/06/22/%e8%bb%9f%e9%ab%94%e9%96%8b%e7%99%bc%e7%9a%84%e7%a0%b4%e7%aa%97%e7%90%86%e8%ab%96/ 軟體開發的破窗理論 « 天馬行空-程式館
  • Darrent Chen

    看這篇文章,學到很多,看下面的討論,一段一段都精彩,程式設計師都該知道的東西。

  • Darrent Chen

    看這篇文章,學到很多,看下面的討論,一段一段都精彩,程式設計師都該知道的東西。

blog comments powered by Disqus