最近，我在設計、開發、維護一個基於『文檔代碼化』思想的平臺。因為豐富的 markdown 經驗和文檔化系統的設計經驗，我在這個系統中實施了很多過去的一些想法。系統工作得很好，但是代碼卻顯得一片混亂，因為系統過於複雜。而，我突然覺得這是一件好事。
最佳實踐很浪費時間
對於敏捷開發來說，我只採納了持續集成和持續部署的思想，即提交代碼便發佈到 GitHub Pages。但是，這也浪費了我很多的時間，而且我覺得沒有必要，因為我已經有一個本地可以部署的腳本。我只需要在本地運行一下<code>deploy/<code>，那麼就會在本地構建，並部署到服務器上。然而，為了最佳實踐的理念，我還是花了半天的時間，研究了一下 GitHub Action，然後讓它實現自動部署。系統的 UI 採用的於 Angular 框架，因為我懶得搭建腳手架，而且我還有一些先前的代碼可以複用。所以，我 copy / paste 大量的代碼，這些代碼大部分都是沒有測試覆蓋的。是的，你很少看到我的開源項目是沒有測試覆蓋的 —— 畢竟寫單元測試也是要花時間的。過去，我們統計過一個相關的數據，在我們日常的開發中，我們差不多有 1/5 的時間花在了單元測試。所以，一週下來，我差不多一天的時間在寫測試這件事上。
一個問題，三種方法實現
如開頭所說，整個系統的核心是一個基於 markdown 的多功能渲染引擎。這部分的組件可以讓你用 markdown：
畫出條形圖、雷達圖、思維導圖
畫出甘特圖
畫出特定的四象限
調用 Web Components
……
而為了實現這個功能，一共有三套不同的機制，當然了對於寫 markdown 的人來說，它們是無感知的。這三種方法分別有：
創建佔位符，渲染完成後，替換佔位符
直接生成最後要渲染的 HTML
-
生成一個 ID，在渲染的過程中，根據 ID 替換元素。
所以，整個過程就相當於，是解決一個問題有三個方法，然後我都用了這三種方法。
起初，我只想創建個原型
起初，我只是想創建一個簡單的系統，它只是一個簡單的原型。而後，隨著越來越多想法的產出，我創建了一個足夠複雜的系統。所以，我起初設計的一系列要素都失效了。
我還有一堆糟糕的 SCSS 要管理，因為第一個版本設計的 CSS 體系，無法適用於新的架構。整個系統圍繞在 markdown render 上，而這個 render 有大量的樣式，就好像早期的多核 CPU 架構，只有一個 CPU 在工作，畢竟有大量的工作。
隨著系統越來越複雜，我開始需要一個文檔系統來管理這個文檔系統，以便告訴我自己：系統裡有什麼功能？
一片混亂，真的很爽
是的，現在，現在雖然看上去界面很美觀，功能也很強大。就好多是我們看到的其它軟件系統一樣，但是內部真的是一片混亂。如果你習慣了這樣的系統的代碼，那麼你可能覺得這不是一個問題。
但是，我習慣了在項目中引用各種最佳實踐。看了這樣一個系統，覺得非常的爽 —— 大部分系統就是這樣的：同樣的時間壓力之下，我做得也就那樣。雖然，我的手速可能比大部分人還快，實現的功能可能更多。但是，這些都是無關緊要的。
如果沒有充足的時間改善，我們的系統都變得一片混亂。沒有符合未來變化的設計，更何況你可能沒有時間設計。
好了，是時候重構
所以，經歷了一系列的過程之後，我決定挑個合適的時候重建這個系統。
開始重寫之前的 markdown converter。
將 markdown render 所有相關的組件提取為框架。
重寫系統。
於是，我們就出現了第二個系統，它設計良好。它的靈感都來自於我們在做第一個系統中的感受。如果沒有來自於我們第一個系統的經驗，我們無法設計出第二個系統。
經驗：快速驗證概念，創造業務價值
事實上，我們在市面上看到的大部分系統，都是以如此的方式演進的：
第一個系統，賺了錢，創造了價值，但是缺少各種最佳實踐，生存週期短。
第二個系統，設計良好，包含了各種實踐，生存週期變長，但是慢慢變得臃腫
而我們的第二個系統很快將變成一個臃腫而緩慢的系統。
『第三個系統』由那些為 『第二個系統』 所累的人們創建。—— 《Linux/Unix設計思想》
沒有新系統，哪來的 KPI？
這些不都是因為我們沒有經驗嗎？哈哈
