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

javascript flux redux architecture

在历数技术进步的代价时，弗洛伊德遵循的路线使人感到压抑。他同意塔姆斯的评论：我们的发明只不过是手段的改进，目的却未见改善。 ——尼尔波斯曼《技术垄断》

css architecture

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

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

我把 MVC 框架作为我们理解架构的切入点。虽然它现在已经式弱了，但在我看来它非常重要并且起到了承上启下的作用：作为经典的解决方案第一次系统的把应用的从复杂的混沌中解救了出来。从这套方法论中我们能学习到很多至今能受用的思路，同时我们也能了解到它的不足。

javascript mvc architecture