l

2014年12月19日 星期五

品質與開發速度

Dec. 16 17:33~18:26

image

 

有一個朋友讀完《The Lean Startup》這本書之後告訴Teddy,在新創公司開發軟體,可以不用太注重品質。因為公司的產品都還在實驗階段,開發的軟體可能用完就丟,或是因為不受歡迎而中止開發,所以投資太多資源在軟體品質(設計、測試、可讀性等)是一種浪費。

先請鄉民們思考一下,上面這句話有沒有道理?

先討論兩個極端的情況,如果產品注定只使用一次,或是在某個事件結束之後就不再使用,在這種情況下的確可以不用花費太多資源在長期的品質投資上,只要人工驗證確定系統可以動就差不多了。如果產品預計會長期使用,那應該要朝向寫出clean code的理想邁進。

難就難在,很多時候公司不是那麼確定軟體會不會被市場接受,又怕「過度重視品質」會導致開發速度變慢,而降低收集使用者回饋的速度。換句話說,這個「界限」要怎麼拿捏,真的不太容易。

理想上,開發人員可能都希望朝向clean code的方向前進,而老闆可能希望東西快生出來就好,以後的事以後再說。Teddy覺得在這個情境之下,有兩個盲點:

  • 注重品質一定會比較慢,省掉工法就可以加快開發嗎:以Teddy自身的經驗,除非系統很小,否則完全不做設計、不寫測試,恐怕只會越做越慢。
  • 軟體做完的定義(Definition of Done):注重品質並不是說立即就把軟體當成「藝術品」來看待,在專案一開始就要立即規範非常嚴謹的DoD。專案一開始風險很大的時候,也許DoD可以鬆一點,但至少也要做到撰寫單元測試。隨著時間進行,再視需要提升DoD。

***

只要不是驗證概念的雛形(錯也沒關係)或是只使用一次就丟的小系統(手動測試的成本低於自動測試的成本),Teddy認為軟體品質的最低要求都應該要包含單元測試,因為這原本就是軟體開發不可分割的一部分。至於要寫多少測試,至少要讓自己與團隊對於繼續開發與修改軟體有信心。注重品質不是只為了客戶,也是為了專案的進度,因為《Clean Code》裡面提到:

The only way to make the deadline—the only way to go fast—is to keep the code as clean as possible at all times.

(讓你趕上截止日期的唯一方法--也是唯一讓你開發速度變快的方法--就是隨時儘可能的保持乾淨的程式碼)

***

友藏內心獨白:心中又冒出Quality Without A Name這幾個字。

沒有留言:

張貼留言