軟體品質 vs 開發速度

Software engineering is always a trade-off

軟體工程是一項取捨的藝術

以前在系統設計的書上看過這一句話，當下沒有太多的感覺，但是工作過幾年，愈發覺這句話道盡了現實的骨感。我們會聽到一些似是而非的言論:

測試喔!? 等上線後再來補就好，現在那麼忙!
加上測試工作量會變很多，之後再討論啦。
產品先釋出再說，就邊營運邊測。
測試寫了老闆又看不到，程式會動比較重要。
…

如果這些話出現在30年前，我根本不會太訝異，但即便目前市面上已經有很多協助團隊做持續整合與部署的開源工具，許多中小型的軟體公司仍依循傳統的觀念，要求團隊在短時間內將功能開發釋出，沒有最趕，只有更趕。

工程師幹古時間

會讓我有這些感觸的緣由，便是來自於過往的專案經驗，當時Scrum在我手上已經導入將近一年，期間參與了香港的PSM-I課程，又進一步地加速團隊的進化，成員也開始能夠給出對團隊有用的開發建議，加速同事分享軟體工程知識的意願，而不是早期那種一個口令一個動作的氣氛。

後續接著海外市場的交易開發案，有鑑於海外券商對於交易風險控制的要求非常高，剛好這也是由我這邊負責著手開發，某位同事在Sprint Review時順勢提出開始著手寫測試的要求，當下非常高興，團隊開始有自我管理的味道出現了，因此我也將測試要求一起納入驗收準則 (DoD, Definition of Done)，初期先要求每個人對於自己開發的模組，務必要寫單元測試，慢慢培養大家的測試習慣，我們也順勢引入Google測試框架作為風控模組壓力測試的工具，一切就這麼展開了，內部甚至開始希望能夠引入CI/CD的工具，節省大家手動編譯及部署的時間，以增加生產力。

別懷疑，很多新創小公司不一定會使用這些已知的自動化工具，以當時公司內部根本沒有CTO或技術主管配置的情況下，能夠做到自動自發提出這些要求，絕對是難能可貴的一件事。

不過麻煩也接踵而至，由於風控模組絕不容許有任何交易上的失誤，任何一項違反當地市場法規的交易行為都可能造成交易線路被停用，每一條線路單月就必須付出約莫台幣20萬的租用成本，因此絕非僅是遵守券商的最低風控要求在開發，在外人想像，這就感覺只是在寫許多IF..ELSE..的語句而已，但在我眼裡這卻是練習對自己的模組作壓力測試的絕佳時機，我開始學著考量不同交易行為下的輸入/輸出、數值範圍的合理性、風控檢查延遲優化、邊際事件觸發條件甚至是小數點造成的計算誤差等等可能，因此耗費了許多時間在測試案例的編寫上，卻也替我惹來了麻煩。