前言：對於前端工程化，很多人都有自己的見解。那麼，公司的產品開發，也在採用前後端分離的形式，到底什麼是前端工程化，我為什麼要推進前端工程化呢？ 本文主要就分為兩個部分，第一部分是介紹一些前端工程化的內容，別人都是怎麼踐行，怎麼理解的；第二部分介紹我為什麼加入了前端工程化，我是基於什麼考慮的。

一、前端工程化的基本概念

簡單借用了兩篇文章，讓大家大概瞭解一下前端工程化，接下來的第二部分，我會解釋，為什麼我要加入前端工程化，在這個過程中，我考慮了什麼，我取捨了什麼等等

二、我為什麼加入了前端工程化

2.1，什麼是工程化

我個人之前有總結過一篇軟體工程的發展歷程的部落格，額，在此僅供參考：【軟工5】：軟體工程的發展和體系結構

我大概闡述一下：在上述部落格中，我總結到，軟體工程從無到有經歷了5個階段，第一個階段，就是“作坊式”生產。事實上，我感覺到，目前很多產品開發，僅從前端這個版塊來說，可能仍然還處於作坊式的開發。軟體危機爆發，1968第一次提出了軟體工程的概念。  那麼，可以簡單的理解為：工程的思想，就是用來解決軟體危機的。  而，工程化，就是用工程的思想來指導產品開發，是一種思想的踐行。

2.2，我為什麼選擇工程化

解釋為什麼工程化，就不得不提軟體危機，從上個世紀60-70年代，80-90年代，本世紀初—現在，總共上是經歷了3次軟體危機，而第三次，我們正在經歷，或者說，我們也正在加劇。說實話，我一直覺得敏捷開發會出問題，不是說敏捷本身會出問題，而是更多的“偽敏捷”。我眼裡的敏捷開發，並不是說沒有設計、沒有文件、不能快速迭代等等，我眼裡的敏捷，是提升每個階段的效率，從而縮減時間，而不是刪減內容。     摸著良心說吧：在你開發的系統中，文件齊全的有多少？而文件齊全，又符合系統迭代實際的，又有多少？每一次迭代，保證軟體質量嗎？  哎呀，其實就是每個工程師眼裡都有對於工程的看法，不能說誰好誰不好，各自取捨，各自負責吧！

1，軟體危機

三次軟體危機各有原因和特點，但總結起來，無非就是這麼幾個：管理、人力、時間、質量，這幾個，又可以組成一個死迴圈，缺乏理論的指導，個性化而難以管理——質量危機——維護成本增加——人力成本增加——時間成本增加——管理失誤，總結到最後，就是花費了很多不必要的錢。  

軟體危機的表現和特徵，不只是發生在後端，前端也有。

工程化：以較少的投資獲取高質量的軟體

2，Servlet技術發展

想象一下咱們前端經歷了什麼樣的演變過程，前端其實從根本上來說，也就是三個基本內容：HTML、CSS、JS

其演變過程：靜態（SGML-HTML-XML-XHTML）—動態（動態頁面，沒記錯的話，應該是從.NET中的ASP發展而來，在java這邊主要是：Servlet-JSP-模板引擎偽靜態化）—獨立工程。  這個演變過程，其實也是一個不斷追求效率的過程吧，我的理解。簡單說當前的Servlet技術或者說偽靜態化技術，相對於直接執行JS來說，還是不夠快。

也是基於這麼一個考慮，如果前端不經過後端伺服器，直接執行JS會比較快，那麼，就拆分吧！

3，產品開發中的現狀

在實際的開發中，我有注意到幾個點：

A：由於工程師的個人技術棧體系不同，很少有人是同時精於後端和前端的，當用這麼一個工程師去開發的時候，第一是無法最大限度的發揮他所擅長領域的價值，第二是增加了額外的開銷（前後端工程師的價位可不是一樣的）

B：我們嘗試不前後端分離，也讓善於前端的人去做JSP頁面，讓擅長後端的人去做後端開發，但是，他們之間的溝通成本在不斷增加，並沒有最終解決問題

C：前端JS、JSP頁面、CSS，複用率太低了，冗餘雜亂。儘管我們模擬後端面向物件的模組化思想去管理，但依靠規範去做的事兒，確實成效甚微，我們在思考，是否可以通過技術手段去解決

在我們產品的開發中，暴露出來的問題，集中起來，也無非就是軟體危機的一些體現。當我們的前端工程出現了問題時，我思考工程化！

三、我為什麼選擇了Angular

首先，前端工程化，這是一種思想。我看來，它並不一定意味著前後端分離或者選用Angular一類的產品。但我們之所以分離或者說選擇Angular這樣的產品，是基於一個站在巨人的肩膀上，徹底的，通過工具和技術，去解決我們的問題。

3.1，其他產品

vue.js:

React:

3.2，為什麼選擇

目前：公司用的是Angular4，前後端分離，效率也提高了很多，當然，在前期，我們也付出了代價！