那到底是什麼啊？
我用兩年時間深入鑽研Angular。
我接觸過十幾個基於Angular的專案，接觸到不同的團隊和思想。
第一年我看到框架被採用，API的改變，文件的改進和社群的形成，從上到下的瞭解了Angular。
另一年是完全的親手實踐，提供諮詢。
我的結論是：Angular.js對於大多數專案是“足夠好了”，但是對於專業的Web應用開發是不夠好的。
你所謂的“專業Web應用”是指什麼?
我所說的“專業Web應用”指的是長久可維護，在所有的現代瀏覽器中都表現良好，有著流暢的使用者體驗，且對移動裝置友好的Web應用。
專業的Web應用不是簡單的只解決特定問題的工件，它是可以讓使用者愉快使用的產品.
這個應用應該完成的相當快，採用各種最佳實踐，不僅在程式碼層面（優秀的設計、簡單的概念、容易掌握的元件)，而且還包括部署過程（CDN、程式碼壓縮、搜尋引擎優化、關鍵路徑優化等)，以及可用性領域（載入速度、內容優先、故障弱化，資訊組織，等等 )。
Angular有在什麼情況下適合使用？
1. 構建基於表單的“CRUD（建立、查詢、刪除、更新）應用”。
2. 臨時的專案（例如原型系統，小應用程式）。
3. 行動遲緩的大企業，當效能無關緊要，而且不用考慮維護的開銷。（但是你試過ExtJS嗎？）
什麼情況下Angular絕對不適合呢？
1. 團隊的經驗不同。
2. 需要不斷髮展的專案。
3. 缺少資深的前端開發主管來經常瀏覽程式碼。
4. 有著五星級效能需求的專案。
當然，這些問題可能所有的框架和專案都有。但是Angular會比其他MVC框架更快帶來更嚴重的問題。
如果被迫要使用Angular，有什麼好用的策略呢？
1. 使用Angular做原型沒問題，輕鬆搞定。
2. 一旦原型被證明是要做的事情，那麼馬上忘掉原型，不要繼續發展它。
3. 坐下來分析你犯的設計錯誤。
4. 開始一個新的專案，最好用其他的技術堆疊。
5. 把原型的功能匯入到MVP（最簡化可實行產品）中。
如果你仍然需要發展你的專案並且在未來維護它：
1. 接受你將在未來承受痛苦的現實吧，降低期望有時候會讓你開心一些。
2. 用這些流行的AngularJS風格指導 (這個, 這個 和 這個)建立一個完整的指南，能夠覆蓋到所有你能想到的用例和模式.
3. 用你OOD（基於物件設計）的知識嘗試保持一切儘可能的鬆耦合。
4. 使用MVC或者MVVM，但不要把它們混起來用的。
5. 把“重構”的迭代放到開發過程中（最好每三個月一次）
6. 建立一個基於Angular的元框架，針對你專案的需求和你團隊的經驗進行裁剪。
Angular不好的部分
如果你還在讀，我建議你深入瞭解一些主要的問題，寫在下面的部落格中：
1. 糟糕的抽象
2. 糟糕的效能
3. 名稱衝突
4. 複雜性
5. 第三方模組
6. 沒有可供參考的經驗程式碼
“不，Angular很酷！你只是不知道Angular怎麼做事！”
很久以來我都這樣告訴別人，試圖證明我是錯的。
是的那些問題可以避免。
但是你必須花大量的時間來學習框架的細節。
你要在開發過程中引入那些“警告標誌”。
你必須花時間來繞過那些問題。
嘿，你會解決這些框架強加給你的問題。
但這不是你試圖實現高效能的專業應用時想要做的事情。
而且“變通的方法”也不是你想要維護的東西。
你學到什麼了嗎？
- 對於有經驗的開發者來說一些問題開始就已經很明顯了。只是這些點子都很棒啊，團隊也認為沒問題，就覺得應該不會出錯吧。
- 我相信那些問題將會被逐步解決。
Github上有很多有價值的討論。有很多pull請求。有很多可以解決問題的方法。
但事實是：這些解決方法還在討論中，並沒有被合併進去。 - 一些問題在Angular 1.*中永遠都不能被解決。
- 我相信我可以教人們把事做對。但是沒有框架的支援就必須一遍又一遍的解釋。
框架（元框架）開發者的經驗教訓：
- 必須儘可能少的使用抽象。
- 命名必須和你的“思維領域”一致。
- 不要混淆元件的功能。用明確定義的角色進行細粒度的抽象。
- 在文件中描述你這些決定的目的，以及你所做的權衡妥協。
- 寫一個完善並且保持更新的參考專案或例子。
- 抽象必須是“自底向上”的，從一些小專案開始，逐漸組成複雜的模式。不要一開始就問“我們應該如何全域性的過載？”
- 全域性狀態是惡魔。它就像恐怖電影裡的黑暗一樣。你永遠不知道踏進去會有什麼問題發生。
- 資料流和資料變化應該是粒度化的，而且定位到單獨的元件。
- 不要讓事情易於使用，讓你的元件和抽象簡單，易於理解。人們應該學會新的有效的方式，不要適應他們的舒適區域。
- 把所有你知道的好東西都編碼到框架裡。製作“導軌”，如果有不正確的操作，就丟擲警告。
嘿，我需要一些其他的選擇！不要只給我這些！這不公平！
好吧，不好意思還沒搞定它們，但你可以點選這裡!
但我用Angular工作很開心！
如果真是喜歡的話，請你在github上分享你的實踐、方法、問題解決方案，元件和專案結構。
但如果不是真喜歡這些東西的話，就不要勉強做。
Alexey Migutsky，全棧工程師。我用魔法讓 IT 工作。