文章的名字我想了很久，备选项有“我再不推荐 Redux”，“Redux 为什么令我头疼”，“Redux 进化启示录”等等。通过这一系列名字我想你大概能猜到我接下来想聊的问题是什么，但这个问题放眼望去不是 Redux 独有，而是在做技术决策时经常会遇到的，即使对于非前端背景的开发者也同样成立。最后决定用一个带有开放式标题也许能够引起更多的共鸣。

javascript flux redux architecture

正在阅读这篇文章的你，或多或者接触过前端性能优化，这样的接触可能是来自你的阅读体验也可能是来自工作经验。那我们不妨从一个非常简单的思想实验开始，请你借助你对这个领域的理解，来回答下面的几个问题：

javascript performance

编程框架日新月异，工具平台推陈出新。但有意思的是，代码的坏味道不会因为你使用工具的时髦而自行消散，团队成员的编程水平也不会随着工具的进化而水涨船高。

javascript vue

随着应用程序的日趋庞大，它变得越来越难以维护。随着可复用模块的重要性逐渐递增应用的复杂性也随之增长。我们都意识到我们应该在它面临难以维护的风险之前做些什么

javascript mvc architecture

这篇文章或许看上去仅和 Angular2 开发者相关，但我相信它也适用于其它的框架。这只是一份关于编写具有可拓展性和可维护性单页面应用的指南。需要指出的非常重要的是，这并不是达成目标的唯一方式，但是对我个人而言它们在不少的场景中都行之有效

javascript angular architecture

我猜此时此刻你心里的疑问一定是：为什么是 Angular，不是 React，不是 Vue，不是 Flux，不是 Redux ? 因为你已经对它们太熟悉了。我个人作为开发者而言最希望是能够汲取到“圈外”的“营养”，这样才能给我的成长带来帮助。我想对各位也是一样。

javascript angular architecture

如果你对整洁架构（Clean Architecture）有所了解的话，回想一下我们前几篇中描述的内容，你会发现整洁架构对前端，对 MVP 来说也是同样适用的。

javascript architecture

在 Flux 架构中，有两个问题依然没有被提到，一个是表现层模型，另一个是测试

javascript flux MVC architecture

MVC 的不足

javascript flux architecture

在上一篇中，我提出了一个应用中常见的问题：如何在多个视图中共享同一份数据，并且保证它的改动能够同步到不同的视图中去？

javascript mvc architecture