引言

當談起這個話題的時候，不得不去想到《人月神話》這本著作中所描述的軟件工程思想，其中的最后一段總結論述：

軟件工程的焦油坑在將來很長一段時間內會繼續地使人們舉步維艱，無法自拔。軟件系統可能是人類創造中最錯綜復雜的事物，只能期待人們在力所能及的或者剛剛超越力所能及的范圍內進行探索和嘗試。這個復雜的行業需要：進行持續的發展；學習使用更大的要素來開發；新工具的最佳使用；經論證的管理方法的最佳應用；良好判斷的自由發揮；以及能夠使我們認識到自己不足和容易犯錯的——上帝所賜予的謙卑。

大型前端遇到的問題和困境

在我們的實際項目中，會遇到各種各樣的挑戰，其中最大的挑戰就是：逐漸復雜的領域模型和項目周期快速演進的矛盾。在實際業務推進會很快，隨之時間推移，項目中涉及的模塊，體系，軟件的形態也會變化很快且復雜，隨之產生如下問題：

• 最初的架構不在支持當前的變化
• 代碼由于多人維護，可讀性變差
• 連鎖的破窗效應，代碼的質量變差。
• 維護成本變大，維護成本不及整體重構。

工程化的解法

當然工程問題，還是需要工程方法來解。我們大體會建立自己的工程體系和規范。通過一系列的工程化的方法論來逐一應對和推進。

建立統一的開發協作環境

這個是工程化的基石：開發工具（IDE 或者編輯器），版本管理體系，構建工具，持續集成平臺，項目管理工具。
對于前端項目來說，可以選擇的工具還是比較多的。可以列下清單：

工具類型實際工具說明開發工具VSCode，WebStrom，Atom基本上以上三個就是目前大部分前端使用的編輯器，當然也有使用sublime，vim等版本管理工具git ，git-flow，gitlab目前git還是大行其道，但是git的最佳實踐還是很多，團隊最好還是使用適合自己的版本管理實踐構建工具webpack，rollup等自從前端有了node，構建體系也逐步完善持續集成平臺jenkins，Travis CI，GitLab CI工程體系不可或缺的一部分，如何保障軟件的質量和更新項目管理工具jira，redmine，Trello主要還是進度，溝通，協作工具

這些，目前已經是前端項目開發的標配，在很大程度上可以使用現代化的軟件工程技術，提升開發效率和質量，但是在擁有這些基礎設施，其實還不夠。我們需要在代碼開發建立規約和框架，統一編碼認知，就是接下來講的開發框架。

開發框架

我們希望在開發層面上確立和使用統一的編程模式，因此應運而生的就是前端主要三大體系：React，Vue，Angrular。以及對應的三個主要生態體系。當然還有成長中的web component范疇的一些框架：Polymer。當然React，Vue，Angrular也可以實現web component。

此外，如果是大型前端項目，還是需要MVC，MVP，MVVM，或其他的設計模式的概念，當然現在，單向數據流加狀態管理也是大行其道。這里就不再贅述了。

引入這些的初衷一定得比較清楚：編寫可維護，規范的代碼（系統模塊的協作，人與人的協作規約）。

模塊包管理

大部分工程化的編程語言設計之初都有模塊化和包管理的體系，但是JavaScript一開始是沒有的，這也是制約前端工程化的主要原因，但是前端開發者在編寫一些大型應用時，逐步的建立起模塊化和包管理體系。

統一的開發規范

在逐步構建完整前端工程化體系的同時，一個是否重要的部分，代碼規范如何落地在整個體系里面呢，可以編寫一個規范文檔，引入一個代碼靜態檢查工具，還是加上 更加類型嚴格的TypeScript。當然這些都是已經被證實可行的。
于是在構建過程中，引入了諸多的規范化工具插件。如eslint，stylelint，babel，typescript。

測試，當然還有測試

差點把測試這個給漏掉了，為什么呢，據統計大部分前端代碼是沒有單元測試的，為什么沒有呢，理由很多：需求變化快，需要在修改代碼同時，修改單測，測試收益不大；可以直接使用段對端測試，測試人員完成了。這些觀念沒有問題，當然得想想合理的測試方式，和反思下測試的目的：保證產品質量。可能大部分的情況下會得出一個折中的結論：核心代碼，工具，類庫需要編寫，業務代碼可以不用編寫單測，通過其他方式（黑盒測試，端對端測試等）進行彌補。最后是要列下測試工具的清單：Mocha，jest，qunit，jesmine，Karma，Chai，ava等等。

工程化總結

控制復雜性是計算機編程的本質。 - Brian Kernighan [Unix的主要貢獻者]

前端工程化之路，日趨完善，但是我們擁有了這些，是不是之前提到的問題都可以得以很好的解決呢，事實上答案是否定的。只能說這些工程化工具平臺的使用有助于項目的合理推進，有一點積極作用。以此我們引入接下來的思考那我們還缺少什么呢？
我在擁有現代化的前端工程技術的支持下，還是會產生代碼維護和開發效能，軟件質量等問題。難道就沒有一勞永逸的辦法嗎？如同治療癌癥，就沒有特效藥嗎？是的，目前沒有，如同癌細胞，伴隨我們一身，不斷在突變，同時身體的免疫系統不斷的在抵抗，完全是一個動態過程。軟件工程也是一樣，面最大問題還是變化應對變化的方法，只有持續的控制其發展，才是有效的方法。

如何可持續演進開發

唯一不變的是變化本身。 - Spencer Johnson[《誰動了我的奶酪》的作者]

在軟件生命周期中，一切都是動態的，是不斷變化的，而我們現有的工程方法論就是應對這些變化而存在的，所以需要在現有工程化的基石上，建立閉環的生命周期，把現有的工具融合在一個生命周期里面。

如何控制變化：工程方法（分治，協同）

軟件工程的目標是控制復雜度，而不是增加復雜性。 - Dr. Pamela Zave

作為工程工具在開發中的角色，可以想象成一套水管系統，每一個環節其中的水管的一段或者水管中間的泵。水管中流動的水就是我們需要生出的產品。工程工具系統就是保持軟件演進是像活水不斷的前進保持活力、
其中主要的思想就是分治和協同，把軟件需要完成任務在生命周期中拆分出來，在各個階段使用工具完成使命，然后采用協同的方式，接入各個時期任務的產物進入下一階段的產物生成。
通過工具保障產物的質量和效率。但是我們會發現這些工具在軟件設計階段還是相對薄弱的支持，因為關于設計這塊更多還是開發者需要去思考的很重要的部分，而通過通用的工程方法顯然無法直接覆蓋和解決。為了提升開發統一和效率開發框架應運而生和同時產生DSL的編程方式，在大方向上指導，如申明式編程，響應式編程，面向對象編程等編程范式和對應的最佳實踐框架。
如何組織模塊，架構，代碼都必須是開發人員自己該去思考部分。而這部分思考最終會導致程序產出內容好壞和可維護性。所以引出了如下話題：如何設計變化：架構。

如何設計變化 ：架構(拆分，組合)

取勢 明道 優術 -長江商學院校訓（最早出自《道德經》，《孫子兵法》）

這里用"取勢 明道 優術"來開篇，主要這三個層面的方法論可以指導我們做出正確的設計和架構，取勢：順勢而為，找到軟件產品的本源，本身用來做什么的，他的方向是什么，這個層面是最重要的。接下來明白了方向和產品的本源，那我們就要思考如何使用正確的方法，原則來設計軟件架構，這個就是所謂的明道。接下來就到了第三個層面，優術，可以用商業本質的4個字來詮釋優術：多快好省，歸納到我們軟件工程方面就是質量和效率提升的方法和工具。
所以，做什么，為什么要這么做，怎么樣做？只有把這三層問題回答了，對于架構的產生和理解就順其自然了。設計主要是在完成這本源問題的解決。如果要確定三個層面“取勢 明道 優術”，架構設計就是實現取勢，明道這兩個的問題解決。
前人在設計架構方面提供了很多經驗和典范，方法，原則，有領域驅動設計，設計模式，測試驅動開發，行為驅動開發，面向對象編程，面前切面編程，響應式編程，申明式編程，DRY原則，開閉原則（OCP），CAP原則，12factor...
有很多，不一一列舉，而且要掌握這些需要靠實踐積累和學習，要做到活學活用，必須在具體實踐中使用，理解，驗證，使其符合發展規律。

如何治理變化: 開發資產(粒度，標準)

無為而治 -老子《道德經》

以無為而治開題，并不是說不去做什么，而是順應變化和自然去治理的意思，如果只是這樣那就不是無為而治，變成了無治了。無為的意思是不對具體細節加以干涉，過多的管理和操作的意思，另一方面，不去關注細節，也就是可在方向和變化本身的趨勢更多的關注，認識整個發展過程，建立起開發資產的生態。關鍵點：形成開發資產的自治和進化。

所以，這里需要我們在更高的層面去思考治理變化這件事情，如何建立一個自治的開發生態體系？
主要可以分成以下幾塊：

• 資產系統化：資產共享共建平臺。
• 資產標準化：確定開發資產的特性和類型，及其規范（工具，組件，插件，服務）。
• 業務領域化：建立業務知識圖譜和領域劃分，系統架構圖。
• 培訓體系化：可以共享共建的WorkShop（知識和能力學習系統）。
• 共建激勵機制：明確開發資產價值，貢獻值。作為團隊加分項。

這幾個模塊是互相依存的，大體關系如下：

每一塊的構建都有很多需要去思考和完成的，這里只是提綱挈領的列出來，后續可以有單獨的篇幅的闡述每一個部分的內容。這里我們主要關注各個模塊之間的關系，如圖所示，最底層是需要建立一套激勵機制，保障上層各個模塊建設和執行的動力。通過明確事務和資產的價值，產生正向的激勵，推動執行。接下來培訓體系，用于團隊自我進化的一套體系，主要起到知識連接傳承的作用，幫助團隊認知統一，然后可以通過，workshop，進階課程，競賽，資質認證，專業評定等方式來落實。標準規范，是開發工程化和資產化的基礎，需要確定流程，編碼，質量，部件標準等。最終我們真正得益的開發資產和知識圖譜，有了明晰的資產和圖譜，在產品應用構建的時候，可以極大提升效率和質量，同時也有了全局的視角來指導產品方向。

進一步：從自動化到智能化

在軟件開發過程中，一直在致力于構建高效的，準確的解決實際問題的方案，技術的革新也是在整個人類可以發展的大趨勢下不斷演進和突變，我們縱觀歷史，從電氣化時代到信息化時代，主要的技術革新是計算機和網絡快速發展，那我們的下一個革新可能是機器的智能化，從運算智能，感知智能和認知智能的突破，而對于我們所處的計算機行業影響比較大，對于軟開發來講，原來是人所需要做的事件可以由機器來完成，從最初單一邏輯事項，逐步進化到感知邏輯的事項，最后到認知邏輯的事項，逐步由機器替代。變成了人類自治到機器自治。逐步軟件構建，治理從自動化到智能化晉級。

結語

只有不斷孜孜不倦的思考問題和問題本質，才能逐步從大型項目的困境中突圍。同時，問題也在隨著方法論進步而變化出新的問題，所以還是已《人月神話》的結尾，保持謙卑，砥礪前行。

總結

以上是生活随笔為你收集整理的知识图谱前端插件_大型前端项目可持续演进开发的思考的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。