Re: [心得] 為什麼軟體開發者需要在意軟體品質指標

看板Soft_Job作者 (lgd1008)時間13年前 (2012/05/27 23:48), 編輯推噓7(7推 0噓 76→)
留言83則, 5人參與, 最新討論串11/20 (看更多)
看到許多人的討論都蠻同意. 對我來說unit-test算是重要的, 但我也同意說unit-test可視情況來實行的說法. 要道行高的人, 配合道行低的人的規則, 那道行高的人會煩. 要道行低的人, 配合道行高的人去冒險, 那道行低的人會怕. 畢竟每個人道行不同, 我只關心你的理由說得通就行了. 早點寫, 晚點寫, 寫得多, 寫得少, 我覺得都能夠變通, 重要的是寫出你的承諾. 如果你能給出承諾中的表現, 那unit-test的確算不上最重要的事... ----- www.facebook.com/java.tw -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 114.25.60.203
→
05/28 03:14, , 1F
確實是這樣.類似股票長線派在跟短線派爭論誰獲利,誰方法
05/28 03:14, 1F
→
05/28 03:14, , 2F
正確..黑貓白貓會抓老鼠就是好貓
05/28 03:14, 2F
→
05/28 03:19, , 3F
有些人一個月只要模組增加一點新功能就能領薪水.
05/28 03:19, 3F
→
05/28 03:21, , 4F
有些人是二個月要完成一整個團隊的任務或全部的系統
05/28 03:21, 4F
→
05/28 03:22, , 5F
你是後者.我真的不知道你怎麼還有那麼多功夫可以寫測試?
05/28 03:22, 5F
→
05/28 03:24, , 6F
我提過能被檢測程式檢核到error我真的感到訝異.不可能發
05/28 03:24, 6F
→
05/28 03:26, , 7F
生. 除非說明或文件沒給清楚.不然不可能發生.
05/28 03:26, 7F
→
05/28 03:31, , 8F
上面那句話肯定會被炮轟.很多人要質疑.因為你們沒經驗
05/28 03:31, 8F
→
05/28 03:32, , 9F
但事實就是這樣.我寫的程式也會有bug.但自己會檢測過.
05/28 03:32, 9F
→
05/28 03:32, , 10F
這類的bug.根本就是檢測一次就不會再發生.哪會需要一再
05/28 03:32, 10F
→
05/28 03:33, , 11F
需要重複檢核?還會再發生,那代表你的程式品質真的有問題
05/28 03:33, 11F
推
05/28 03:41, , 12F
我今年已經被兩位好友講我的程式功力退化了.沒有年輕時
05/28 03:41, 12F
→
05/28 03:43, , 13F
猛.但事實我根本沒感覺我真的有退化.我只是程式碼寫更多
05/28 03:43, 13F
→
05/28 03:44, , 14F
但因為執行結果相同.讓大家感覺我怎麼開發用時更多了?
05/28 03:44, 14F
→
05/28 03:45, , 15F
我到底在寫啥?我每一個函數.每個進入點都寫了一大堆檢核
05/28 03:45, 15F
→
05/28 03:46, , 16F
因為累積經驗..一些死人骨頭會怎樣給你亂搞的全都檢核
05/28 03:46, 16F
→
05/28 03:49, , 17F
這樣的方式還需要去寫驗證案例嗎?還不如像我這樣直接把
05/28 03:49, 17F
→
05/28 03:50, , 18F
檢查寫在程式碼內..跟著程式碼走..沒檢核也不會出事
05/28 03:50, 18F
推
05/28 03:54, , 19F
貼一篇趣味文章做結束.讓氣氛緩和一下.
05/28 03:54, 19F
→
05/28 03:54, , 20F
05/28 03:54, 20F
→
05/28 07:51, , 21F
我在想。UNIT TEST很單純就是驗證功能的結果。
05/28 07:51, 21F
→
05/28 07:52, , 22F
並不需要把他想得太複雜。
05/28 07:52, 22F
→
05/28 07:52, , 23F
一個函式，一個方法，依結果回傳TRUE、FALSE。
05/28 07:52, 23F
→
05/28 07:52, , 24F
最多就是回傳一些必要的值。
05/28 07:52, 24F
→
05/28 07:52, , 25F
然後僅僅驗證這樣的結果符不符合條件而已。
05/28 07:52, 25F
→
05/28 07:53, , 26F
可UNIT TEST不是讓你毫無目的的卯起來什麼東西都要測。
05/28 07:53, 26F
→
05/28 07:55, , 27F
而且unit test其實可以變成TDD的！經由驗證的開發。
05/28 07:55, 27F
→
05/28 07:58, , 28F
TDD 有點太遠了，對 unit test 都不接受的人， TDD 不會有
05/28 07:58, 28F
→
05/28 07:58, , 29F
吸引力。XD
05/28 07:58, 29F
→
05/28 08:57, , 30F
還是老話一句.請視專案規模及複雜度而定,沒必要墨守成規
05/28 08:57, 30F
→
05/28 08:59, , 31F
以前曾搞過一個很複雜的遞迴演算法.類似那個沒auto test
05/28 08:59, 31F
→
05/28 09:01, , 32F
真的會死人.永遠不知道在哪個環節出錯.現在的都是網頁,
05/28 09:01, 32F
→
05/28 09:02, , 33F
資料庫..等等都很單純化.真的程式寫好就已經測試完畢了.
05/28 09:02, 33F
→
05/28 09:04, , 34F
而且現在都是物件導向寫法..不需要在寫啥功能.真的都是
05/28 09:04, 34F
→
05/28 09:06, , 35F
在寫檢核而已.功能在上層class早都身經百戰驗證沒問題了
05/28 09:06, 35F
推
05/28 09:10, , 36F
大家環境都不同.一定會雞同鴨講.寫一大堆 assert() 我也
05/28 09:10, 36F
→
05/28 09:14, , 37F
搞過..到現在我還是有保留少許這些東西.但幾乎真的絕跡
05/28 09:14, 37F
→
05/28 09:15, , 38F
需要動用assert的機會真的沒那麼多了.搞演算法的環境,我
05/28 09:15, 38F
→
05/28 09:17, , 39F
真的承認且有必要性寫 test case.因為連我都有寫.
05/28 09:17, 39F
推
05/28 09:24, , 40F
我想起一個笑話:很久前歐美跟日本購買燈泡.跟廠商講故障
05/28 09:24, 40F
→
05/28 09:25, , 41F
率要2%.當時日本人搞不懂歐美幹嘛要2%的故障品..於是
05/28 09:25, 41F
→
05/28 09:25, , 42F
出貨時每箱都塞2個壞的燈泡在裏面.並且註記這兩個是壞的
05/28 09:25, 42F
→
05/28 11:11, , 43F
樓樓上的講法有點怪怪的,unit-test單純用於驗證,還可以TDD
05/28 11:11, 43F
→
05/28 11:11, , 44F
但TDD本身不就是unit-test驗證功能的反証嗎? XD
05/28 11:11, 44F
→
05/28 11:11, , 45F
你先寫一些test case,再製做一些mock object讓test case都
05/28 11:11, 45F
→
05/28 11:12, , 46F
能夠通過, 這樣代表程式被驗證完了?可是程式都還沒開始寫.
05/28 11:12, 46F
→
05/28 11:13, , 47F
unit-test的驗証功能, 應該恰好是在TDD以外的情況發揮吧?
05/28 11:13, 47F
→
05/28 11:40, , 48F
TDD 驗證的是「界面」，而 TDD 的過程是從「不過變成過」。
05/28 11:40, 48F
→
05/28 11:40, , 49F
不過 TDD 解釋起來有點太複雜，我基本上也還感覺不到他的好
05/28 11:40, 49F
→
05/28 11:40, , 50F
處，所以我就不多說。XD
05/28 11:40, 50F
推
05/28 11:41, , 51F
TDD 不是「程式還沒開始寫」的狀況，至少介面跟函式定義會先
05/28 11:41, 51F
→
05/28 11:41, , 52F
寫，只是實作是寫完之後在做這樣。
05/28 11:41, 52F
→
05/28 12:08, , 53F
當太多層樓的時侯,"樓樓上"是簡化的說法,仍謝謝樓上的回覆
05/28 12:08, 53F
推
05/28 14:40, , 54F
TDD的意思簡單來說就是：測試寫完功能也同時寫完了。
05/28 14:40, 54F
→
05/28 14:41, , 55F
所謂的測試驅動開發TEST DRIVEN DEVELOP
05/28 14:41, 55F
→
05/28 14:41, , 56F
簡單來說！你要測試資料庫連線過不過。
05/28 14:41, 56F
→
05/28 14:41, , 57F
一開始一定是給FALSE，因為你都還沒連嘛！
05/28 14:41, 57F
→
05/28 14:41, , 58F
然後測試語法，輸入帳號密碼。
05/28 14:41, 58F
→
05/28 14:42, , 59F
因為連線成功就會獲得回傳值為true。
05/28 14:42, 59F
→
05/28 14:42, , 60F
當你驗證完這個true時，你還需要寫功能嗎？你都寫好了。
05/28 14:42, 60F
→
05/28 14:43, , 61F
同樣的。登入帳號密碼也是一開始給FALSE。
05/28 14:43, 61F
→
05/28 14:43, , 62F
用第三方測試載入功能函式給予測試值看結果。
05/28 14:43, 62F
→
05/28 14:44, , 63F
當結果為PASSED時，你還需要寫登入嗎？你都寫好了。
05/28 14:44, 63F
→
05/28 14:45, , 64F
然而因為功能開發的過程全部都有一個測試做為輔助驗證。
05/28 14:45, 64F
→
05/28 14:45, , 65F
萬一有BUG時，也僅需要列出驗證狀況就知道錯誤在那了。
05/28 14:45, 65F
→
05/28 14:46, , 66F
換個方式來說，你卯起來寫功能難道都是腦內補完程式碼？
05/28 14:46, 66F
→
05/28 14:46, , 67F
寫完他就一定過？一定是修修改改修修改改......
05/28 14:46, 67F
→
05/28 14:46, , 68F
那花這些時間修修改改為什麼不一開始就測試？
05/28 14:46, 68F
→
05/28 14:47, , 69F
很多人都以為寫程式去測試主功能是浪費時間的一件事。
05/28 14:47, 69F
→
05/28 14:47, , 70F
卻沒注意到自己浪費更多時間在那想程式寫的對不對。
05/28 14:47, 70F
→
05/28 17:46, , 71F
樓上兩位對於TDD的解釋都很怪...
05/28 17:46, 71F
→
05/28 17:47, , 72F
如果除了在程式完成的情況, 在任一時間點, 都容許測試中有
05/28 17:47, 72F
→
05/28 17:48, , 73F
錯誤存在.這還算是test-driven嗎? 那要怎麼分辨那些錯誤是
05/28 17:48, 73F
→
05/28 17:49, , 74F
實作的錯誤? 還是設計的錯誤? 還是就咬定設計一定是對的?
05/28 17:49, 74F
→
05/28 20:47, , 75F
TDD我是基於單元測試的開發。一次僅對單一功能進行測試。
05/28 20:47, 75F
→
05/28 20:48, , 76F
一個函式大概就沒幾行程式碼，我想根本上沒什麼問題。
05/28 20:48, 76F
→
05/28 20:48, , 77F
除非你是想把一大堆程式碼塞在函式來驗證。
05/28 20:48, 77F
→
05/28 20:49, , 78F
對我來說，一個函式超過10行code我就有點忍耐不住了。
05/28 20:49, 78F
→
05/28 21:54, , 79F
@lgd1008 所以這就是我為什麼說太遠了，他說得是對得，但是
05/28 21:54, 79F
→
05/28 21:54, , 80F
這看過實例的人很難跟上。
05/28 21:54, 80F
→
05/28 21:54, , 81F
^沒
05/28 21:54, 81F
→
05/28 22:42, , 82F
我想我們是在雞同鴨講, 關於TDD的討論可以停了...
05/28 22:42, 82F
推
05/29 07:53, , 83F
的確. 有做好Assert的話某程度上可以代替Unit test...
05/29 07:53, 83F
‣ 更多 lgd1008 的文章
文章代碼(AID): #1FmapClJ (Soft_Job)
討論串 (同標題文章)
完整討論串 (本文為第 11 之 20 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共20篇)
‣ 更多 lgd1008 的文章
文章代碼(AID): #1FmapClJ (Soft_Job)