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

看板Soft_Job (軟體人)作者TonyQ (自立而後立人。)時間14年前 (2012/05/28 12:34)推噓1(1推 0噓 19→)

留言20則, 4人參與討論串13/20 (看更多)

註：2012/05/28 有使用者提出 test-case 名詞的異議，為免爭論修改用詞。 ※ 引述《semop (semop)》之銘言： : 看來看去，明明從頭到尾就是在講 unit test 的 automation 啊。 : test case 到底是哪來的名詞? : 我覺得這根本就像是知道了一個"新"方法，然後就狂熱提倡的言論， : 還真以為我們這種老人不知道啊? 我說得其實是「實作 test-case」這件事情。不用 automatic tests 是因為他不見得需要 automatic test ，很多時候我們是手動 trigger 這些 test。不用 unit-test 是因為還有 integration test，所以挑了一個比較中性的詞「實作 test-case」來說。當然，如果你看不懂這個詞，我可以再定義清楚一些，寫「用程式可以跑得測試」。名詞是用來溝通的，如果這樣寫你還看不懂可以再問問。這方法一點都不新，unit-test 有很多年歷史，今天如果不是有人出來批評這個方法不現實，我一點興趣出來講也沒有。知道請用實力/經驗談，不要用「老」來談，我談得東西都是確實有在專案跑過得經驗。跟幾零年代有沒有人講過沒有關係。你覺得寫 unit-test 不好，可以談談您用 unit-test 浪費過多少時間，或者談談 unit-test 您認為的缺點，也不需要別人舉經驗反駁您的缺點就舉老來反駁，這一點意義都沒有。你覺得我的經驗不客觀，你可以用你的經驗說說，哪邊你覺得有問題、哪邊有不客觀。 : 但這東西在九零年代初期就講到爛了，今天會重新被提倡有著時代的背景， : 在 Web Programming 大行其道，文字資料愈來愈重要的狀況下， : 測試的需求增加，測試的方便性也增加，所以測試的成本效益增加。 : 然而以軟體生命周期的觀點來看，需要在軟體開發後期建構的方法， : 都不如在前期就執行的效益來得大。 : 一堆講 test case 的好處的，其實講的是由開發者自行做單元測試， : 比起交給別人測試，有更多早期的效益。 : 但軟體開發在運算層次之外的核心工作是 v&v (verification and validation), : 重點是你有沒有做 v&v, 而不是你有沒有用所謂的 test case 的方法來做。對，但是這裡我們說的是"寫 unit-test" 可以有效作到 v&v 。當然， v&v 跟我們討論的寫 unit-test 原則上是不同層次的命題，所以寫 unit-test 並沒辦法 cover 所有 v&v 的情況，但老話一句，他是工具，不是 total solution。 : 在軟體單元外部建構的 v&v, 本來就沒有比在軟體單元內置的 v&v, : 來得更接近開發的前期。 : 而在 design 階段就建構的 v&v 機制，特別是完善的 exception handling (EH) : -- 這不是指 C++ 對於 EH 的支援，這遠遠不等於 EH 的機制 -- : 則又更是在更早的軟體開發階段了。 : 例如現在我就很傾向即時監控機制的做法，客戶不見得看得懂測試報告， : 要是測試報告說 ok 又出問題還會更怒，但若有個即時監控的功能， : 系統的測試者或使用者都隨時都看得到系統的各種檢測狀態， : 不但測試方便，更重要的是，對於客戶來說，系統即時監控的爽感可說是超級高的， : 當然他們付錢也就爽快了。 : 若以為在畫面上出現不知所云的錯誤訊息就是 EH, 那可真是顯得有些無知了。 : 能在 analysis 階段就主動避免問題發生，又是再好一些的做法， : 例如我就儘量不碰使用者輸出入，不處理字串內容，只接受良好的格式化資料， : 這種狀況還會出問題，都是作業系統層級甚至硬體的問題比較多， : 何況做那些 UI 功能的事情，不是不太需要專業就是需要 UI 的專業... : 所以到現在還在寫 C/C++ 的軟體開發者，特別是傾向系統層級或技術研發的， : 就很少人在談 unit test 層級的事情，更何況如果不是內建的檢測機制， : 光是物件導向的 yo-yo problem 就可能很麻煩了，但不是每個人都會去避免的。以上，完全都跟寫 unit-test 這件事情的主題沒有關係，這才是重點。 unit-test 是加速你開發，不是幫你做出一個「完全」穩定的系統，這是兩回事。你說得這些東西都是挑戰跟值得做的東西，但是有了 unit-test 仍然可以幫助你作這些事情做得更好更快。你在談得是另一個層次的問題，而他也確實是國內開發者的問題，但是寫 unit-test 完全就可以幫助你作到這些事情。我不瞭你拿張飛打岳飛幹麼？難道你要說因為問題是這個，所以「版本控制」就不是重要的東西？因為版本控制不能解決你說得這些問題？他們要做的是扮演好他們的職責，而你說得並不是他們的職責。 : 我在說的也就是這樣的事情，說什麼 data validation 也要做 test case, : 一點意思也沒有，能在前期處理的就不要拖後，能內建的機制就不要外加， : 始終是軟體開發的金科玉律，包括 unit test 的優點也是依賴這個原則的。 : 甚至以為老人們就是打死不做 unit test, 那又更是好笑了， : 我們跟 test 無冤無仇的，如果是能用簡單方法就達成效益的事情， : 那又為什麼不做? 那本來就是成本效益的問題。這，我認識的所有資深 RD 幾乎都會作喔...... 我們認識的大概是不同群的老人吧 : 我可以理解用過有加上 automated testing 的 continuous integration (CI) : 感覺可能非常好，好像找到了軟體開發的終極解答一樣， : 所以很想要先從 automated testing 開始提倡。 : 唉，這要怎麼說呢，工具依賴是一件很沒有救的事情，那是信念的差別了， : 在中大型軟體機構開發的人，常常會覺得世界上有那麼多好用的工具和方法， : 只要輕輕鬆鬆就可以完成工作，為什麼其他人不懂得使用呢。 : 我知道，我理解，但不討論。你不討論的話就沒什麼好說啦。 : 從早年生存至今的開發者，為什麼許多人會走向以程式設計方法論為主， : 儘量不依賴外部工具來寫程式，而不是以軟體工程體系的建構為核心， : 那真的要經過很多風浪之後才會知道... 我也經過一些專案，不算多但是也不能算少，我深知論述一個 solution 的困難，所以我寫作的方針就是只寫實際的經驗跟例子，有人問的時候我會盡量把所有的前提跟假設，甚至是哪個案子中有用到的東西寫出來，這是很重要的。因為這其中很多東西都跟你用的工具跟你的經驗，甚至是一些新工具新 IDE 的抬頭有關系。你的風浪如果不能換作你論述的實際依據，不能因此舉出專案有哪些特性跟前提，如果不能因此讓別人多一點參考價值。坦白說，你的風浪是死的。在你的腦袋裡面有用，在其他人的腦袋理面一點價值也沒有。再者你誤會了，這些東西做起來並不輕鬆，學習新東西總有時間跟成本，但是還是比反覆無聊的手工操作來得輕鬆。我從頭到尾都只是抱著「我用了一個好東西」，然後「別人不識貨」，所以出來說說這東西是好東西，但是你用不用你怎麼想，這坦白說我一點都不在乎。寫 unit-test 我也試著用超過三年，從 ppolis 、自己接小專案、 ZK，我想是不是你所謂「知道了新方法就大力推薦」，我是知道了、做了，我也碰過其中有很麻煩得部份，你回去翻我之前寫有關測試的文章就知道，但是權衡之下這我認為還是有做的價值。 -- 網頁上拉近距離的幫手實現 GMail豐富應用的功臣數也數不清的友善使用者體驗這就是ｊａｖａｓｃｒｉｐｔ歡迎同好到 AJAX 板一同討論。 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 111.250.32.241 ※ 編輯: TonyQ 來自: 111.250.32.241 (05/28 12:37) ※ 編輯: TonyQ 來自: 111.250.32.241 (05/28 12:40)

→

ykjiang

05/28 12:43, , 1^F

05/28 12:43, 1^F

→

ykjiang

05/28 12:44, , 2^F

05/28 12:44, 2^F

→

andymai

05/28 13:05, , 3^F

05/28 13:05, 3^F