無瑕的程式碼《軟體工匠篇》－審校序
一開始的前幾章，Uncle Bob 火力展示 TDD 的實戰應用，從無到有，手把手教你起手式，透過自然而然的推論，最終完成一個又一個的「演算法」。重點是他提供的影片。我觀看第一則展示 Stack 的影片時就被嚇到了。
TDD 嚇到我嗎？不是的，是影片中 Uncle Bob 的笑聲嚇到我了。
不論是學習程式、語言、開發、上台分享、參加研討會⋯⋯開發人員們，你有 一邊 Coding 一邊大笑的經驗嗎？老實說，Coding 那麼久，除了在克服難關攻 上山頭時會開心高興之外（也只是心情上），好像從來沒有過，像 Uncle Bob 一樣能邊笑邊寫程式。他的笑，就像跟 Baby 學走路一樣，只是前進了小小的 一步，就足以讓你開懷大笑。這才是開發人員應該有的心態，為自己前進每一 小步而開心大笑。
本書的影片沒有字幕，因此我利用 Whisper AI 幫中文讀者轉錄了字幕檔，讓英聽不是那麼好的讀者，可以開著字幕檔好好當一下 Uncle Bob 的學徒，更好 理解文字無法表達的展示情境。（當然，現在英轉中的 AI 工具已經唾手可得， 讀者想的話，DIY 一下吧。）在 AI 轉換過程中發生了一件事，你會發現，有兩個 clean_craftsmanship_sort2(_2).txt 的檔案，sort2.txt 在 12 分 33 秒後開始當機，同一模型試了幾次都一樣，後來換了另一個模型，才有了 sort2_2.txt 的正常輸出。我覺得這是個很好的經驗（我個人前進一小步），因此請編輯把兩個檔案都保留下來提供給讀者。
除了 TDD，本書「第 3 章」裡面對於測試的講解，更是解開我多年來對於測試物件的疑惑：Dummy、Stub、Spy、Mock、Fake，你知道這些測試替身物件之間的差別嗎？你知道它們之間的使用時機嗎？光是搞清楚這件事，我認為已值回票價。
另外，在本書看到「測試替身」這個術語時，我有點激動。原因是，當初我在翻譯《Martin Fowler 的企業級軟體架構模式》時，被一個詞 Stub 卡了許久， 後來想通了整個測試物件的行為，最後採用了「替身」一詞。能與大師有同樣 的感悟，讓我差點大叫。讓我把當初的譯者註放上來：
[譯者註] Stub 本身的技術中文翻譯都沒有很好的語意，微軟技術文件翻成「虛設常式」，常見的還有「存根」、「票根」、「樁」等翻譯。譯者首次是在 學習測試時碰到 Stub 這個詞。Stub 本身在測試裡的行為是一種擬態，用以斷開原本依賴的物件，讓程式碼達到更好的可測試性。譯者喜歡看漫畫或動漫，某天突然靈光一閃，這不就是替身嗎！JOJO 冒險野郎的替身、火影忍者的影分身都是 Stub，它是一個可以代表本體的身分的替身。電影裡也常有 Stub 的身影，葉問的木人樁、拳擊手的練習沙包都是一種真人的練習替代品，也 有引申為替身的意思。（《Martin Fowler 的企業級軟體架構模式》p.501）
當我看完「第 3 章」才發現，原來是我格局小了，原來⋯⋯（留給讀者去瞭解。）
看到這裡，你會不會以為，這是一本專談測試、TDD 的書。千萬不要誤會，測試很重要，但還有比測試更重要的事情（我個人認為）。在 AI 技術大爆發的現今，開發人員的地位被提升到一個完全不同的層級，而在學校，通常也只 是教你某個程式語言及相關程式或 API 開發的技巧。但對開發人員應有的「紀律、標準、倫理」並沒有太多著墨。或許你不會用 TDD 來開發，你不會寫單元測試，但你應該保有「紀律、標準、倫理」，這部分應當印成類似「員工手冊」 的「開發人員手冊」人手一本才對。
我細細思考身邊認識的開發人員，只要是往「紀律、標準、倫理」的方向前進的開發人員，我不敢說都會成為 TDD 的信徒，但最少都會成為測試的一員。在寫完產品程式碼時，不寫測試，慢慢的不敢 commit，綠燈就是你能按下 commit 的通行證，綠燈就是你的信心，你的保證。
因此，我想重述我在《重構：改善 .NET 與 C# 應用程式的設計，償還欠下的技術債》審校序中的一段話：『曾經有人問我，如何區分資淺和資深開發者？以技術能力而言，我會把「測試」當成其中一項評估指標。』（《重構：改善 .NET 與 C# 應用程式的設計，償還欠下的技術債》p.iv）
在《重構：改善 .NET 與 C# 應用程式的設計，償還欠下的技術債》中，也花了不少篇幅教大家如何有技巧地提出重構的 Sprint 或 Task。相較之下，Uncle Bob 認為，重構就跟『煮飯時……在烹煮過程中隨手清洗備料用的器具』（本書p.242）一樣，只是日常紀律，開發時隨手清理髒亂的程式碼。看完後有點汗顏。但細細回想，我們比較像「重寫」而非重構，因此需要為「重寫（改變 了行為）」想盡辦法安排 Sprint 或 Task。
《無瑕的程式碼 軟體工匠篇》可以引起回憶的地方實在太多，例如「估算」這 件事。2016 年左右，那時公司剛導入 Agile/Scrum 沒多久，大家都還在熟悉這一套框架，只是個還在練習如何為 Story 估點數的新手。
那時我被指派一個非常重要的任務，需要研發一個能統一存取資料與服務的核心功能（參考 twMVC#42：https://s.poychang.net/dev-udsp）。能接到有難度的任務，心裡是高興的，但每週的 Planning Meeting 我都好有壓力，每次在填寫預估數點時，我心裡都非常難過，因為我知道我又說謊了。我知道我有能力能完成這個任務，但任務的難度難到我完全無法預估何時能完成，但那時的 Agile/Scrum Game 讓我別無選擇，只能一次次成為「狼來了」的小孩（我相信團隊也知道，只是不說破）。
幸運的是，不論是團隊還是老闆都知道這個任務的難處，放手讓我專心研發。最後整整花了 6 個月（24 週）的時間，突破所有的難關，終於開發出來平台所需要最核心的功能，現在這個平台為整個開發團隊提供非常重要且核心的服務。但說真的，如果時光可以重來（或早點讀到本書），我會選擇說實話，落實「誠實」這條倫理，跟老闆及團隊好好溝通，而不是每次的 Planning Meeting 都非常心虛的填預估數點，如犯錯的小孩一樣低著頭說，再給我 1 個 Sprint 試試看。（God ！好可怕的回憶。）
《無瑕的程式碼 軟體工匠篇》寫著開發人員進入匠人桃花源的一切關鍵，如同 書中對於 100% 涵蓋率的見解：『100% 是一個遙不可及的目標⋯⋯請把 100% 這個數字視為一個漸近的目標』（本書 p.256），堅持每天持續不斷的進步， 那怕是 0.01 也好，這是開發人員成為匠人的最佳實務。
最後感謝編輯國鳳的邀約，讓我能品嚐（閱讀）到如此的美味的書，滿足，太滿足了。感謝我的家人們，每一次都是佔用你們額外的時間，來成就這些額外的工作。
沒有留言:
張貼留言
感謝您的留言，如果我的文章你喜歡或對你有幫助，按個「讚」或「分享」它，我會很高興的。