參與 Element3 開源項目，使用 TDD 的一些感覺

本文是element3 的contributor之一，在體驗了element3的tdd組件化開發流程後的感想

本文做者：世風十三

TDD的困惑

不少項目團隊並無使用 TDD （測試驅動開發）的開發方式，我想這在目前的開發團隊中佔比很是高，特別是中小型公司的前端開發團隊，幾乎能夠說是「全軍覆沒」，爲何？緣由多是如下所列的一些：

• TDD 太麻煩，增長了工做量
• TDD 太複雜，普通程序員掌握不了
• TDD 並非必須的，沒必要要投入這些時間成本
• TDD 是個太理想的方式，仍是要面對現實
• TDD 很好，但是咱們公司實力弱，招不起那麼專業的開發人員啊

我想這裏面有一些可能的緣由：

• 對 TDD 的理解可能還不夠深入
• 沒有給團隊必定的空間和時間去嘗試和體會
• 眼光看得不夠遠，只關注眼下項目的結果
• 沒有真正體會過 TDD 的好處和收益

TDD的思考

還有一個極限編程羣裏的說法是：

說到底仍是開發人員能力不行，沒練好 TDD ，說什麼也沒用，TDD 是要刻意練習的，「先投一萬個球再說！」。 :D

總的來講，這個 TDD （測試驅動開發）就跟不少體驗性的能力同樣，不親身體驗，不深刻體驗，不會有深入的感覺，正應瞭如今流行的「真香」定律，老是要用過了，體會過了，纔會說好用的。

就比如，有人跟咱們說，健身很快樂、很上癮，收益很是大，而咱們卻沒辦法體會，也明知這個道理，也不能實踐。而後呢？老是有一堆理由和藉口來給別人，也給本身開脫。

• 健身 太麻煩，太累，天天上班工做已經很累了
• 健身 太難了（要辦健身卡，請健身教練），通常人沒條件
• 健身 也不是第一要務，暫時沒那麼多時間去投入
• 健身 的生活方式是理想的方式，目前的現況仍是要面對的
• 健身 很好，但是家裏的現狀不容許啊

固然，健身還只是一個我的的事情，而 TDD 則是一個團隊和一個公司的事情，有時候可能最終能推進會顯得更困難。固然，也能夠從自身作起，逐漸帶動周圍的人慢慢加入，這須要一個過程。

然而這個狀況在開源社區中，可能就相對好些。一方面參與開源項目的開發人員一般都是出於對技術的追求，更願意採用先進的編程思想和理念，市場和業務的壓力相對寬鬆，一般掌控開源項目的社區領袖都是技術方面的高手，可以正確地看待一些技術實踐對質量的重要影響，因此整個開源項目的開發過程可能更加科學、合理和有序，儘管參與開源項目的人員分散在全世界的各個地方，卻並不影響他們產出高質量的軟件和成果。

Element3裏的TDD

最近參與了開源項目 Element3 的組件開發，整個項目從立項之初，就確立了使用 TDD 測試驅動開發的原則和規範，所以參與的人員要麼已經熟悉 TDD 的開發方式，要麼是想學習和深刻理解 TDD、Vue3 和 ElementUI 的學習者，所以在心態和意願上具有了良好的基礎，團隊成員至少是不存在對於 TDD 開發方式的抵觸和抗拒問題的。

在此過程當中，我我的也進一步對 TDD 的開發方式體會更深了一些，下面聊一些我我的的感覺：

其實不少時候，我並不想聊具體的技術，我以爲比技術更能改變自身的是心態，具體的技術資料，網上難道還不夠多嗎？現現在這個時代，怕是窮盡一輩子也學不完。說回到 TDD 這個開發方式，多數人都是有隻知其一;不知其二的，我本身可能多年之前就知道測試驅動開發是什麼意思了，然而也就是近一兩年纔開始真正入門實踐，爲何呢？ 本身反思了一下，一個主要緣由多是缺少見識，不知道這個 TDD 原來是這麼好的開發方式，本身也沒有深刻思考過相關的問題，套用最近我看到的一個文體：

由於你沒聽到音樂，因此你會以爲跳舞的人瘋了。

由於你沒體會過 TDD 高質量代碼的好處，因此你會以爲用測試驅動寫代碼的人瘋了。

Progress組件

我我的目前只重構了一個組件： Progress，兩個星期才重構完了一個 Progress 的組件，注意：僅僅是重構／重寫，這期間的前提仍是需求明確、實現方案已經現成的狀況下，我再次重寫，只是須要用測試驅動開發，保證代碼質量，原來的具體實現方式已是通過使用驗證的，能夠大量參考的，這中間減小了大量的溝通需求的時間，研究實現方案的時間等等，我猜若是要徹底憑空實現的話，給我一個月時間還不知道能不能達到如今的效果。

「就這？」也許你會調侃一下個人開發效率了，我也自知是個能力通常、資質平庸的程序員，這很正常，但也很真實，咱們最好仍是認可咱們本身是平凡的大多數，使用 TDD 後一個很大的好處是，即使是平庸如我這樣的程序員，也能夠寫出拍着胸脯有自信的代碼了，一種真正的腳踏實地的感受，軟件行業流行着一種觀念是說：哪兒有軟件沒 Bug 的？有 Bug 很正常嘛！的確軟件的複雜性，決定了軟件出 Bug 的高機率，但是這樣的觀念和說法，卻無行中滋長了不少軟件代碼的粗製濫造，只求快速實現功能，無論將來的可維護性、可擴展性等等。

我這樣的開發速度也許在一些「追求結果」、「惟快不破」的公司項目中是不能接受的，然而，這纔是高質量軟件的真實開發進度，前些天在極限編程羣裏有編程能力很強的朋友統計了本身一星期「無異味」（Sonar 掃描沒有壞味道，即代碼可讀性很好）高質量的代碼產出量，也不過是天天兩三百行而已，放在通常的程序員能力來講，可能也就一天一百行左右吧，一百行代碼能作什麼呢？可能離不少公司領導心目中那種高速的指望很是遠：「我這兒有個想法／需求，下週一能出個 Demo 嗎？這個月最好能上線發佈」。 這種速度倒也不是說不能實現，只是須要前期有相應的準備和積累，編程開發這件事，其實就是這樣，積累得越雄厚，應變的能力才能越強，打造一支這樣的開發團隊，一種企業文化，一批批高素質的軟件開發人才，天然可以作到「惟快不破」高效交付。

這就好像咱們作的這個 Element3 組件庫，或者其餘的各類前端UI組件庫，使用它的人能夠很是快速高效地搭建出一個業務須要的界面，在一些中小公司手快的程序員一天作三個、五個增刪改查的界面效果都是有可能的，然而公司領導或行外人士怎麼會想到，其中的一個小組件竟然要這麼長時間開發？各類後端的開發框架和其餘技術要素也是一樣的道理，沒有相應的積累，就沒有高效的交付能力。

TDD的好處

下面結合此次開源組件重構說一些我所體會到的 TDD 的益處：

TDD 能夠幫助咱們理清需求和思路，由於上手要先寫測試，那麼要測試什麼呢？這時就會先把最終要的結果分析清楚，而後拆分紅可實現的小任務，從簡入繁，先寫出相應的單元測試，再推導出相應的代碼實現，測試經過後，再寫下一個單元測試，再倒推出業務代碼實現，如此往復，這就是咱們說的 TDD 的開發節奏。在這個重構 Element3 項目的 GitHub 倉庫 Issues 列表中就能夠看到參與項目的成員相應的任務拆解過程，一個組件的重構，都好幾十個任務和子任務，整個過程冷靜、耐心、嚴謹，一步一步，看着慢，其實很高效。 實際上越是複雜的組件，越是獲益良多。

TDD 能夠幫助咱們更有信心地進行重構，真正的重構不僅是在原來的代碼上改就完了，《重構》這本書出了兩版了，初版是以 Java 語言爲例寫的，第二版是以 JavaScript 語言爲例再版的，其中對重構有着明確的定義：在不改變"軟件之可察行爲"前提下,調整其結構和代碼，關鍵字是如何確保不改變可察行爲呢？根據不少編程大師多年的編程經驗來看，只有100%全面覆蓋的自動化單元測試才能確保。而要達到100%全面覆蓋的自動化單元測試，最好的方法就是一開始就從寫單元測試入手，測試驅動着寫出相應的業務實現代碼，這樣整個過程下來天然而然就達到了100%的單元測試覆蓋了，即便部分代碼不須要測試，達到 90%以上也是很是輕鬆的事情，有了這樣的保障，咱們才能大膽地嘗試新的想法，不抗拒變化，高質量高效率地持續交付。

按上面這個重構的定義來衡量，大多數咱們日常項目中看到的直接修改實現代碼的行爲，在權限編程羣裏有個說法叫：「瞎搞」，體驗過 TDD 的同窗都明白，確實如此，回想起本身當年的「大刀闊斧」，不由汗顏，確實是瞎搞。瞎搞帶來的危害你們天然也能想到，頻繁的 Bug 修復，不穩定的軟件質量等，天然就會致使團隊成員對任何的修改都心生抗拒，對於業務的需求和變化心生畏懼，對於源代碼日漸陌生，即便很是小的改進也沒有信心快速完成，每一次的更改和發佈都須要大量的人力輔助測試、迴歸測試等，後續的成本耗費其實很是巨大、不可估算。

還有些時候不是需求變了，而是本身的想法變了，最初的實現可能考慮得不周到，可能採用的實現不理想，如今想用更好的方式改寫，這時就須要有一個能夠保障的安全網，這時 TDD 所構建出來的全面覆蓋的單元測試又會發揮極大的價值，

還有就是發現 Bug 的時候，TDD 所構建的單元測試也能夠幫助咱們快速、準確地定位問題，若是現有的測試均可以正常經過，對照相應的測試和 Bug 產生可能的緣由來分析，很快就能有解決的思路，經過補充針對相應 Bug 場景的單元測試，可能很快就能在本地快速重現出問題，相應地解決也將很是快速而準確。

就在這兩三週的重構過程當中，項目涉及了更改目錄結構、轉換到 TypeScript 語言等重大變化，這在一些公司裏的項目多是很是可怕的決策，然而由於有單元測試的保障，團隊成員堅持使用 TDD 來進行開發，都很是有序而平滑地完成了這些變更。 在可預見的將來，有這樣良好基礎的項目，後勁會很是強大，如同飛輪效應，如同滾雪球效應，能夠愈來愈高效地交付價值，知足用戶的需求和變化。

最後，但願此文能引發你對 TDD 的一些興趣和信心，實際體驗一下，尋找一個採用 TDD 的團體，參與其中，真正跨過這個程序員的「分水嶺」，是的，沒錯，在我如今的概念裏，程序員能夠分紅兩種，一種是會 TDD 的，一種是不會 TDD 的，這幾乎成爲了一道「分水嶺」。不論語言、框架或者業務方向，都是如此，當你領略了 TDD 的威力後，你會發現，用這樣的編程方式，各類編程語言可能都再也不是界限，用這樣的手法，一種相似工匠精神的手法，用什麼語言編程均可以寫出質量很高的軟件代碼，由慢到快，「天下武功，惟快不破」 就只是刻意練習的時間問題……

其餘

你們能夠關注Element3和花果山團隊咱們會持續更新最棒的內容。 也歡迎star和pr