品質與開發速度

Dec. 16 17:33~18:26

 

有一個朋友讀完《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這幾個字。