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

[NDark (溺於黑暗)]

※ 引述《ledia (下班後才下棋)》之銘言：
:   難得看到這麼精彩的討論, 而我非常同意 TonyQ 的看法
:   特別同意
:     1. unit test 不是各處都適用
:     2. unit test 不是萬靈丹, 他只是用來取代人類重覆同一個動作容易出錯的特性
:     3. unit test 視需求再配合其他的 QA 機制

各位可以往後翻 #1FmwBE2i (Soft_Job) 這篇真的講得不錯.解開了我多年的疑惑.
所以我把我的文章重新撰寫讓他清楚了點.

最近剛好給了品質管理的talk.可以補充從遊戲軟體製作方向來看軟體品質的想法.

有幾種情況 不可測
       ( 這裡的不可測指得是 我們 "很難" 由 單元/白箱測試得到它應該要有的好處 )

而這幾種情形剛好就是遊戲軟體特別之處.


第一種不可測情況是規格一直改的情形.

  這裡的"一直改"指的是 還沒完成就改 的情形.
  原本預估系統要做一個禮拜,可是在第三天就改規格.(而不是完成系統之後一直改)
  這種情形的試圖測試都是浪費.
  因為規格變動,測試也要跟著動.測試的變動反而會變成災難.
  (原本的測試就是為了要降低程式改動的side effect,現在反而成為來源)
  這種情形也就是需求根本就不確定的狀況.
  我們可以說這不是測試的問題,是談需求的人做的不好.
  但實務上底層的軟體工人依然要在這樣嚴苛的環境進行工作.
  這也是為什麼很多軟體工人不喜歡測試的原因.
  因為環境就不允許.

  也就是說這種情形是 產品存在設計問題.(產品本身就"不對",而不是實作的不對).
  (這種想法類似 網創開發 會建議不要過分開發,
   先用快速的方法證實真的有賺頭後,再進一步談程式架構設計)

  不論每個系統多麼"正確",結局都會是悲劇,還是要重新設計.
  也只有黑箱找得出這種設計問題.

  這種情形首要之務是 提早黑箱/規格產生/驗證的制度化.

  1.提早黑箱
    提早整合
    在企劃端就快速使用工具(勞作,動畫軟體)驗證設計問題.

  2.規格產生制度化
    把時間投入在規格的討論與產生上.
    從遊戲產品來講 就是 讓企劃(設計)產出就是好玩的.
    減少因為設計不良而導致的重新設計及實作.

  3.驗證的制度化
    讓黑箱能夠科學地找到設計問題的真正來源,
    並且針對問題來重新設計(而不是全盤盲目亂改)


第二種不可測的情形是系統本身就不可測.

  譬如說表現性的系統(如介面)只有美/醜,沒有正確/錯誤.
  以動畫系統來說 有時動的 好不好 這個"規格"就很難量化.
  整個遊戲系統就是一個 完整的可獨立表現的系統.
  站在接觸使用者(玩家)的第一線.

  我這裡要談的是 依據開發中不同種類的模組建立 測試的先後順序.
  那些必須仰賴其他系統才能發揮(驗證)其功能的 核心模組 就非常有測試的需求.
  因為那些核心模組無法獨立運作,
  不透過測試不知道修改之後 其他的系統是否依然運作正確.
  反之,週邊的輔助程式不要花太多時間測試.不要為了測試而測試.


第三種不可測的情形是程式本身就寫的太爛,導致不可測.

  首要之務是透過教育與監督讓軟體工人他們寫出可以測試的程式碼與邏輯.
  先把一些愚蠢不該犯的問題釐清.架構作好.再談其他問題.
  (這點有點像是要健身,先從好的生活習慣做起)
  好code本身就不會有太多的問題,清楚,好改,也好測.


最後一種不可測的情形是一次性的產品.

  依照經驗幾乎每次規格都不同一定會重寫的程式.
  我就是在說遊戲產品.
  事實上根據經驗,一個上線遊戲產品的生命幾乎只有1~2年,
  就算長賣,也不會一連改好幾年,多半都是修修bug調整參數平衡度.
  (魔獸世界這種一套十年的產品是非常少見,請不要拿來當特例)
  新產品都極有可能套用不同的引擎,函式庫,甚至語言.所以都是重寫.
  能夠留下來的珍寶 都是 開發觀念與團隊經驗.
  (譬如早期directx每年一改版就不相容就是經典.
   逼著新產品重複的東西一定要重寫.)






--
"May the Balance be with U"(願平衡與你同在)

視窗介面遊戲設計教學，討論，分享。歡迎來信。
視窗程式設計（Windows CLR Form）遊戲架構設計（Game Application Framework）
遊戲工具設計（Game App. Tool Design ）
電腦圖學架構及研究（Computer Graphics）

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 1.164.81.16
※ 編輯: NDark           來自: 1.164.81.16          (05/27 22:58)
→ TonyQ:第一段的重點在於「縮小層級」。
→ TonyQ:如果你測的不是一整個 product ，而是中間幾個重要 util 的
→ TonyQ:功能，這樣不管產品怎麼改，這些 util 都還是能為你發揮效果
→ TonyQ:至於產品存在設計問題，這不在討論範圍內吧，你手動測試照樣
→ TonyQ:會死的東西，想要設計 test-case 把他搞對，這是緣木求魚
→ TonyQ:三是沒問題的東西，四，如果代碼沒有可測試性，手動測試跟開
→ TonyQ:發時自然有別的開發成本要負。
→ NDark:要解正確的問題.每個專案/產品的情形都不同.
→ TonyQ:的確是，而且你對 test-case 的定位也很有關系。
→ TonyQ:如果你是作為一個開發者，把 test-case 作為省力的工具，
→ TonyQ:那你說得問題除了三以外幾乎都不算是問題。
→ TonyQ:如果你是作為一個專案的 QA ，想要透過 test-case 搞定你的
→ TonyQ:專案，這些就可能是你的問題。:P
→ NDark:有些情況角色定位就不是分的很清楚.著重的重點也不同.
→ NDark:簡而言之就是要視情況而定.
→ TonyQ:視情況而定是很好用的詞，但是前提不講清楚，只丟一句視情況
→ TonyQ:而定跟一堆結論的話，就好像有說跟沒說一樣。:P
→ NDark:從管理層面來看真的沒有絕對.要依照情形對症下藥.
→ NDark:問題都是相對的.不管從人還是從時間的domain都如此.
→ andymai:還是一種情形是：需求已經做不完了~人家要求要看到全部的
→ andymai:東西~在期限內加班到凌晨才有可能全部弄出來就偷笑的那種
→ andymai:先求有...才能求好~就算其它做得很漂亮~沒做的就是沒做...
※ 編輯: NDark           來自: 1.164.62.147         (07/17 21:50)