Re: [心得] 為什麼軟體開發者需要在意軟體品質指標
註：2012/05/28 有使用者提出 test-case 名詞的異議，為免爭論修改用詞。
※ 引述《semop (semop)》之銘言：
: ※ 引述《guest2008 (guest)》之銘言：
: : 結論：請先斟酌專案狀況，不需特別的去擁護 test case 的建立或提出議聲。
: 其實反過來說，如果要製作高品質的軟體，測試反而不是重點。
: 完善的軟體架構，特別是內建的驗證、確認和錯誤處理程序，才是最基本的工夫。
: 所有支持測試的論點，都可以用在軟體架構的完善之上。
: 比較極端的時候，這部分可以佔到程式碼的三分之一，就是要追求任何問題，
: 都不能延遲到問題發生的地方之外，才發現和處理。
: 所有系統問題都有內建的錯誤處理，所有輸出入都有內建的資料驗證，
: 所有操作流程都有內建的狀態檢查，所有程式碼都要經過人工的 code review...
前公司是人工 code reivew 跟 CI 並行，
code review 可以幫忙解決一些問題，但經過人工 code review 的東西，
再經過實際 unit-test 跑來測試，效果會有加成的好。
code review 可以避免蠢問題，但一樣不是「沒問題」。
: 嚴謹的開發過程，本身就是最佳的軟體品質增進辦法。
: 這時 test case 的必要性就非常低了，例如資料輸入都已經統一經過驗證程序了，
你的架構仍然需要驗證，所以你需要 unit-test 。
有 code 就需要驗證，unit-test 就派的上用場。
你資料通過「驗證程序」，假設你講的是 data validateion，
data validation 的 code 一樣需要經過驗證。
你怎麼知道你今天寫得這個 regex 或這個驗證條件是對得呢？
會不會你根本就寫錯驗證條件，code reivew 也沒發現呢？
這是有可能會發生的。
: 再餵入擺明通不過驗證的資料，有什麼意義呢?
validator 自己也需要驗證，
另外通常會餵通過驗證跟不會通過驗證的資料，
succee test 跟 fail test 一樣重要，
因為要確保 fail 是真的 fail ， succee 是真的 succee ，
不是我不小心寫了個 if(true) 所以怎麼樣都對。
這當然有意義，所有寫測試案例的書都會提到這件事情，
我不太理解對這種基本原則跟基本方針都不知道的人，
到底是在跟我們談什麼樣的 unit-test 。
: 以前的程式設計就是這樣的，完全不做外掛的自動化測試程式，
: 有什麼需要檢查的地方，就通通寫入程式當中，除非是一定要人工判讀的結果，
: 但那就表示軟體的設計本身就有問題，才會輸出這種東西。
: 現在有些人提倡 test case, 是為了要快速開發卻又要減少 debug 的不確定性，
: 所以付出一定的檢測成本來達成這個需求，但並不是所有狀況的最佳做法，
如果你說得是把所有的 error state 蒐集起來，
做好完善的 guard statement 確保東西出包了都會運作，
出包了都會有個「回報給 microsoft」的 ui（笑），
那你說得也是一種軟體開發的方法，但不是一種作 unit-test 的方法。
那如果你說程式碼裡面塞滿一堆 warn 或 error log ，
在狀態有問題時叫給系統聽，一樣不是一種作 unit-test 的方法。
unit-test 是自己準備好 input - output ，
去驗證可預期的資料範圍內出什麼事情，
不是丟著等人家來跑，完全是兩回事。
: 主要是應用在商業系統開發和維護上。
: 而在目前輕量級的軟體形成潮流，且相當重視創新價值的時候，
: 由於軟體價值的不確定性高，軟體可能非常有價值，也可能一文不值，
: 就又出現完全不搞測試的做法，先儘可能用最低成本快速開發，
: 確定軟體具有商業價值，再投入較高成本重寫有較高品質的新版本，
: 就是另一套很多人提倡的新做法了。
: 總之，歷史上從來沒有任何一個軟體方法，適用於所有的可能狀況，
: 這就是所謂的 "No Silver Bullet" 的原則了，要提倡什麼方法都好，
: 但請先確定適用的領域和前提，不要太過度相信特定的軟體工程方法了。
其實這個問題是不需要談 startup 或產品開發的，
純粹就是「寫code」這個開發階段，可以解決的問題。
如果一樣的需求、一樣（可能會變動）的目標，
有作 unit-test 可以讓你縮短專案的開發時間 1/5 ，
並且讓你開發起來更心安，
你需要考慮他是 startup 或產品開發的專案嗎？
不需要，對吧？
你們談 startup 跟產品開發有差異的前提，
都是 unit-test 賺的是後期跟不改動下才賺得到的成本，
但不是的，他在你一定的開發週期（三週以上），就有機會賺回來了。
這麼說好了，把用人工測試的東西，盡可能的改用機器測試，
只要人工測試的時間會大於寫 unit-test 的時間，就是有賺。
這樣能節省下來的時間，遠比你們想像的多很多，這純粹是經驗談。
當然，我同意「沒有銀彈」的說法，
碰上一個認為「寫 unit-test 只是浪費時間」的人，
或者是寫 unit-test 就是要寫到「程式沒有 bug 」的人，
碰到一個「unit-test 好神好厲害所以非得要寫 unit-test 」的人，
這都是會賠時間的。
所以開頭的那篇文章，我只想說如果你用這種心態作 unit-test，
即使給你 50倍的錢跟五倍的時間，你也作不懂 unit-test 的好處在哪。
因為你一開始觀念就不是在賺時間，要窮舉的狀況下，
人工跟 unit-test 都一樣是做不完的。
但是碰上會用的人，知道哪些容易會一直進行手工測試的人，
比方你剛剛說得 form validation 如果沒包元件的話，
通常是最容易會有 bug 跟需要被測試到的東西之一。
這賺起來的時間是你不能想像的多。
我只能說， unit-test 現在的地位大概就跟當年的版本控制一樣，
當年一堆人亂用版本控制，拿它當 ftp 用，還怪版本控制太慢太麻煩。XD
現在 unit-test 的狀況，確實也很有這個味道。
---------------------------------
Anyway ，我無意說服你們用它，
開發工具這種東西你不喜歡就是不喜歡，
但是這跟他適合 startup 或者適合大型商業專案沒有關係；
我用它只是因為他可以省我時間，
如果你覺得他不會省到你時間，那你可以不要用那是你的自由。
但我要說的是一樣在 startup 或專案公司，
這東西我都引入使用過，都有得到效果。
你們說得理由不是真正的理由，那只是一些常見的迷思。
你們並沒有論述到 unit-test 真正的問題核心，
unit-test 真正的問題核心，我認為是「人」。
想要窮舉所有測試案例的「人」是不現實的，
想要用 unit-test 測所有東西，完全倚賴 unit-test 的人是不現實的，
寫了 unit-test 之後就不去檢視 test-case，
就不會從使用情境中找到新的 use-case （這是我們在手動測時常做的），
這樣的人都會害專案花時間。
能夠用 unit-test 來節省自己手動測試的時間，
並且不在那些自己不太會手動測試的地方寫 test-case 的人，
會幫專案賺很多時間。
但這些東西都是「現實的」，就是有人可以這麼用，
而你們只是沒辦法想像跟拒絕去使用而已。:P
--
對我來講，寫 unit-test 就像是：
「雜事交給不重要得工讀生去作，我可以專心而安心的去面對重要的事情。」
btw 軟體開發我覺得最大的問題也是「人」，有神一般的架構也擋不了笨隊友。
--
Life's a struggle but beautiful.
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 114.25.78.26
※ 編輯: TonyQ 來自: 114.25.78.26 (05/27 16:46)
※ 編輯: TonyQ 來自: 114.25.78.26 (05/27 16:53)
※ 編輯: TonyQ 來自: 114.25.78.26 (05/27 16:54)
→
05/27 18:02, , 1F
05/27 18:02, 1F
推
05/27 18:15, , 2F
05/27 18:15, 2F
→
05/27 21:10, , 3F
05/27 21:10, 3F
→
05/27 21:11, , 4F
05/27 21:11, 4F
→
05/27 21:13, , 5F
05/27 21:13, 5F
→
05/27 21:13, , 6F
05/27 21:13, 6F
→
05/27 21:15, , 7F
05/27 21:15, 7F
→
05/27 21:16, , 8F
05/27 21:16, 8F
→
05/27 21:41, , 9F
05/27 21:41, 9F
→
05/27 21:41, , 10F
05/27 21:41, 10F
→
05/27 21:41, , 11F
05/27 21:41, 11F
→
05/27 21:41, , 12F
05/27 21:41, 12F
→
05/27 21:42, , 13F
05/27 21:42, 13F
→
05/27 21:42, , 14F
05/27 21:42, 14F
→
05/27 21:42, , 15F
05/27 21:42, 15F
→
05/27 21:43, , 16F
05/27 21:43, 16F
→
05/27 21:43, , 17F
05/27 21:43, 17F
→
05/27 21:48, , 18F
05/27 21:48, 18F
→
05/27 21:49, , 19F
05/27 21:49, 19F
→
05/27 21:59, , 20F
05/27 21:59, 20F
→
05/27 21:59, , 21F
05/27 21:59, 21F
→
05/27 22:00, , 22F
05/27 22:00, 22F
→
05/27 22:00, , 23F
05/27 22:00, 23F
→
05/27 22:01, , 24F
05/27 22:01, 24F
→
05/27 22:01, , 25F
05/27 22:01, 25F
→
05/27 22:01, , 26F
05/27 22:01, 26F
→
05/28 00:55, , 27F
05/28 00:55, 27F
→
05/28 00:57, , 28F
05/28 00:57, 28F
→
05/28 00:57, , 29F
05/28 00:57, 29F
→
05/28 01:22, , 30F
05/28 01:22, 30F
※ 編輯: TonyQ 來自: 114.25.108.214 (05/28 22:13)
※ 編輯: TonyQ 來自: 114.25.108.214 (05/28 22:13)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 7 之 20 篇)：