[生活筆記] 有關單元測試的一些反思

前情提要

單元測試可以說是我這幾年投入最多學習項目,
我為什麼會這麼投入? 是因為我相信這是一個有效的開發方式,
持續的上課與練習,稍微記錄一下這些年來的反思。

想法

單元測試是我覺得不論何種程式語言(雖然我並不甚理解 FP),最最基礎的技能,
非常值得深耕,好的單元測試本身是一種規格書(spec)與使用者案例(use case),
你想搞 CI/CD、敏捷、DevOps、DDD,都一定要有單元測試,
甚至我認為這一切只是軟體開發的本質的多面。

我個人是相當推崇 XP (極限編程)的,雖然不知道是不是因為「每周工作 40 小時」這一條,
導致企業不愛,公司不疼、專案管理協會不推、主管不敢用,
但就我來說 XP 反而是最貼近軟體工程的具體實踐(而 Scrum 只是框架,你可以把 XP 放進去),
也是真正能快速帶來品質的作法(簡單而務實)。

缺少的拼圖(困難的現實)

  1. 學習曲線

    有寫單元測試的工程師非常非常稀少,能內化寫得好的更是稀少。
    為寫而寫的單元測試不但無法帶來好處,反而弊病叢生又無法為產品帶來價值。
    但是學好單元測試要多久 ? 要導入又要多久 ?
    這點有些因人而異,但我敢說不是只有一兩次的內訓或 WorkShop 就可以實際上戰場。

  2. 人員素質參次不齊

    承上,寫測試的好處,短期內很難有立竿見影的好處,
    人性就是多一事不如少一事。
    更糟的是,過沒多久這些人員離職、調任、昇遷,
    人走了留下了代碼,一年年過去,
    就只剩一個焦油坑,一代一代傳承的業力,等待被引爆。

  3. 教育體系的缺乏

    在台灣能把測試說到點上的講師,我只能推 91 大,
    也可能是我同溫層太厚或是見識太少,有很棒的講師或網路資源請推薦給我。
    如果可以的話,我希望所有軟體的教育機構都應該介紹並深入指導這門知識,
    包含大專院校與各類補教機構 。

    不過反過來說,91 大的課程對學生來說並不便宜,時間也相當短促資訊量大,課也很難搶。
    在我的觀點,台灣整體軟體產業不能只依靠一個人,希望有更多高品質的課程能夠出現。

  4. 產品生命周期短

    現在的公司壽命,往往比一個人的職涯短,更不用說是內部的專案壽命,
    人員也常常被調任,也導致開發人員對產品或代碼的擁有權與責任感降低,
    當你對自已的產出只當作是個過客,那就不會原意用單元測試去細細打磨

  5. 人各有志

    並不是所有人都與我有相同的想法,我認為身為開發人員必須對自已的負責,
    要有「匠人心態」所以我的基礎會建立在單元測試之上。
    但有得人就只是「討口飯吃」、有得人著重「商業思維」、
    有得人偏重「架構設計」、有得人在乎「市場行銷」。
    退一步說,這都沒錯,但是這些開發者往往不會投入太多的精力在單元測試上(或是排序上靠後)

與未來的展望

單元測試可以幫開發人員可以用更少的資源,對代碼有更深的理解,
一切都是案例,而案例是對產品的解釋,
一但理解了案例,工程師只需要組合單元或是創造新的單元。
而代碼就會是活的工程文件,可以跨越時間傳承給下一位 RD,
你傳承的不再會是業力,而是產品品質的火炬。

一但單元測試的基本知識抓住後,
測試趨動開發與重構就會水到渠成,
這兩門技術也不容易,本質上也易學難精,很需要經驗值,
測試趨動會讓我們更接近使用者,這裡指的是代碼的使用者。

反思:也許是我們太常一人同時飾演多角才會這樣的問題,那麼 Pair Programming 是不是能解決這樣的問題)

重構會引導我們到設計模式
當然設計(架構與軟體)又是另一個領域了,未來會多找這一些課程來上。
目前這塊我也覺得是有缺憾的,TDD 之後就是重構了。
但是我並不認為硬背重構的準則或是 Design Pattern 就是解決之道,
而是應該結合兩者有系統化的設計課程,
理想上是有一個開發案例,可以循序漸進,反覆迭代的開發,
讓學徒可以由作中學,進而掌握這兩本藝術。

我希望可以有更多課程與資源可以學習讓學生們在接觸程式的當下,就接觸測試。
如何讓初階的開發者在學習路上,就接觸到正確的單元測試的姿勢呢 ?
如果未來有一天,人人都能寫出水平之上的測試,這個產業將會進入什麼樣領域呢 ?

參考

(fin)

Please enable JavaScript to view the LikeCoin.