※ 引述《semop (semop)》之銘言：
: 標題: Re: [心得] 為什麼軟體開發者需要在意軟體品質指標
: 時間: Sun May 27 14:15:10 2012
:
: ※ 引述《guest2008 (guest)》之銘言：
: : 直接開新回文
: : 1. test case 是否有必要:
: : 回想了一下，根本不需要像 T 大一樣大力鼓摧，那個真的就是類似摩托車跟汽車
: : 的關係，摩托車跟汽車都可以到達目的地，你認為摩托車真的會比汽車慢嗎??
: : 錯！有時候車子塞車，或者找不到停車位，或者xxoo各種因素，結果都是摩托車
: : 先到。
: : 摩托車跟汽車都是可以到達終點的，要看狀況去選擇交通工具，而不是一意的說
: : 汽車就是比較好。而且汽車真的成本比較貴，且貴太多了。
: : 結論：請先斟酌專案狀況，不需特別的去擁護 test case 的建立或提出議聲。
:
: 其實反過來說，如果要製作高品質的軟體，測試反而不是重點。
:
: 完善的軟體架構，特別是內建的驗證、確認和錯誤處理程序，才是最基本的工夫。
: 所有支持測試的論點，都可以用在軟體架構的完善之上。
:
: 比較極端的時候，這部分可以佔到程式碼的三分之一，就是要追求任何問題，
: 都不能延遲到問題發生的地方之外，才發現和處理。
:
: 所有系統問題都有內建的錯誤處理，所有輸出入都有內建的資料驗證，
: 所有操作流程都有內建的狀態檢查，所有程式碼都要經過人工的 code review...
:
: 嚴謹的開發過程，本身就是最佳的軟體品質增進辦法。
:
: 這時 test case 的必要性就非常低了，例如資料輸入都已經統一經過驗證程序了，
: 再餵入擺明通不過驗證的資料，有什麼意義呢?
:
: 以前的程式設計就是這樣的，完全不做外掛的自動化測試程式，
: 有什麼需要檢查的地方，就通通寫入程式當中，除非是一定要人工判讀的結果，
: 但那就表示軟體的設計本身就有問題，才會輸出這種東西。
:
: 現在有些人提倡 test case, 是為了要快速開發卻又要減少 debug 的不確定性，
: 所以付出一定的檢測成本來達成這個需求，但並不是所有狀況的最佳做法，
: 主要是應用在商業系統開發和維護上。
:
: 而在目前輕量級的軟體形成潮流，且相當重視創新價值的時候，
: 由於軟體價值的不確定性高，軟體可能非常有價值，也可能一文不值，
: 就又出現完全不搞測試的做法，先儘可能用最低成本快速開發，
: 確定軟體具有商業價值，再投入較高成本重寫有較高品質的新版本，
: 就是另一套很多人提倡的新做法了。
:
: 總之，歷史上從來沒有任何一個軟體方法，適用於所有的可能狀況，
: 這就是所謂的 "No Silver Bullet" 的原則了，要提倡什麼方法都好，
: 但請先確定適用的領域和前提，不要太過度相信特定的軟體工程方法了。
:
:
: --
: ※ 發信站: 批踢踢實業坊(ptt.cc)
: ◆ From: 218.174.32.74
: 推 Ting1024:是阿，不用太過趕流行。實實在在建構比較重要。 05/27 14:33
: 推 thinkniht:我很好奇一件事情 你碰過的專案中... 05/27 15:10
: → thinkniht:有實現過"完善的軟體架構"嗎??? 05/27 15:11
:
: 有的，至少在 service system 或 network service 這一塊，
: 很需要在考慮得到的範圍內，完整地把軟體架構做好，不能依賴測試來填補問題，
: 沒做好就有很大的機會垮掉或出包，沒有太多僥倖的空間，
:
: 大部分開發系統核心或關鍵技術的案子，對於穩定性和安全性要求通常都很高，
: 甚至會比效能還重要，基本上就是需要做到這樣子的。
:
: 雖然技術領域的軟體開發，已經幾乎沒有年輕人在做，但這還是很需要有人做的。
:
: 推 thinkniht:再請問一下..."技術領域的軟體開發"是甚麼意思啊 05/27 16:40
:
: 嗯... 大致上就是系統程式設計、軟體技術研發、需要用到冷門技術的軟體開發，
: 和科技相關的應用吧，或者可以說是"比較有技術性"的程式設計了。
:
: ※ 編輯: semop 來自: 218.174.32.74 (05/27 17:09)
: 推 guest2008:thinkniht:你有沒有用過廠商給的API來寫APP?如 google的 05/27 17:54
: → guest2008:API還是券商的API..還是機台的API..這些都算系統程式 05/27 17:55
: → guest2008:打錯..是"技術領域的軟體開發"..另外廣義的講會更多 05/27 17:59
code review
要有程式能力夠強的資深同事才行
但通常這樣的同事也很忙
就算一開始開發的時候會看一下
等之後程式要做一些修改時 不可能一直做code review
有沒有可能越改越爛呢? 我是看過越改越爛的啦
所以啦 我相信code review可以提升品質
但是公司是否真的願意支付這個成本 會是很大的問題
內建驗證的部份
如果是檢查資料異常那當然是OK
但如果單純是為了看程式有否異常而做的檢查
那似乎是沒有必要放在release版本中的
正常程式的錯誤應該在上線前就處理才對吧一.一+
而且這種做法 很可能會讓驗證跟程式的業務邏輯綁在一起
這樣的程式我想應該不好維護吧...
我認為程式如果設計得不好(耦合性太高)
會很難做單元測試
開發新東西時 要是真的就抱持著程式能跑就好
不管可測試性的話...
之後要做單元測試...困難度會高一點
(謎之音：真的只有一點而已嗎XD)
以下是跟主題沒太大關係的話題:
我目前寫的程式...是碰不到UI與資料庫的
技術上...我覺得也沒甚麼技術
(用到的技術呢 相信很多版友都會用)
主要就運算邏輯複雜點而已
我不知道算不算你所謂的"技術領域的軟體開發"
(所以我才會特別問)
但我想算是軟體產品的核心之一吧...
單元測試...有時候非做不可啦
不然UI和資料庫的資料都沒好...
我怎麼驗證我的程式可不可以跑XD
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 114.42.225.173