前言
太多的实战性了，来看看思想性的。今日早读文章由ThoughtWorks
李光毅授权分享。李光毅，知乎专栏「前端技术漫游指南」以及图书《高性能响应式Web开发实战》作者。曾就职于爱奇艺、百度、知乎等互联网公司，目前就职于ThoughtWorks，从事全栈开发相关工作。正文从这开始~~
在这个系列里面，我会谈到前端架构的进化；它们解决了什么样的问题以及又是如何面临新的无法解决的问题的；最后这些架构背后常见的组件和模式。
我知道你们都太熟悉Flux，Redux和Vuex了，所以我不会对它们着墨太多甚至说刻意避免它们。相反，我会谈论到你们不熟悉和没有听说过的Backbone.js，Mobx，NgRx和Akita等等。我不会深入这些框架的使用细节，而是在必要时介绍它们框架内的概念和设计思路。最后你会发现其实所有框架背后其实都在用同一种方案解决问题，你也有能力创建自己的框架了。
作为系列的第一篇，在涉及到真正的技术内幕之前我们需要达成一些共识。这些共识是我们之后谈论所有技术方案的基础，关于什么是好的，如何在选项间抉择，关于框架演化的方向在哪。
关于这些原则你不必每一条都认同，你可以反对它们，也可以有讨论的空间。但你需要了解的是这些原则和共识决定了之后系列的文章中我偏好的一些内容。
满足非功能需求框架是为了解决非功能性需求（Non-functionalrequirement），这一点非常重要，这是一切的前提。在我们公司内部更倾向称之为跨功能需求（CrossFunctionalRequirement）
所谓非功能需求就是我们老生常谈的可拓展性，可维护性，可测试性等等。之所以称它们是非功能性的是因为它们和我们的业务需求没有任何关系。例如产品经理要求你实现一个留言板功能，即使你在单个文件里使用了拥有1)一千行代码和2)20个形式参数以及3)数十种依赖注入的函数去实现这个功能他也并不在乎。因为他只关心功能能否上线，至于这部分代码的将来维护的成本有多高与他无关。
但是与我们有关，框架和模式的魔力恰恰是能够帮助我们在将来的开发中减少项目的维护成本。这里的成本不仅涵盖新功能的增加，旧功能的迭代，开发过程中的调试、部署，还能够让新加入团队的成员更快的上手融入团队。
之所以把这一条原则放在首要位置，是因为我知道你们中的大多数并不考虑非功能性需求。如果在之后的内容中我每列举出一种技术方案时，你们都在心里默默的念：
“为什么要这么麻烦，把功能实现不就得了”，
“反正两年后我也不在这个公司了，谁爱维护谁维护，快速上线要紧”。
“大不了换一波人重构”
那我们其实就聊不太下去了是不是。
实现功能需求不难，如果你已经是稍有几年的工作经验的话，想象一下如果现在让你和一个实习生去实现同一个功能，最后你和他最后的工作成果差别在哪？我相信单单从用户角度上看不大，因为你们都是根据同一份需求文档，同一份界面设计稿，同一份交互方案实现的。真正的区别在于程序的内部你是如何更优雅，更高效和更具前瞻性的解决这个问题的，这些都是非功能需求体现的地方
如何培养的这样的思维模式：想象你的项目要维护十年之久。在这十年里技术栈可能会发生天翻地覆的变化，可能React已经不再是最适合的表现层框架了，但是你的业务逻辑依然有效。如何保证业务逻辑与表现层的分离，如何在更换React的前提下不触碰核心业务逻辑的修改，这一系列文章也许会能给你答案。
“FallingIntoThePitofSuccess”这个标题来自codinghorror博客上的一篇文章，标题就叫做“FallingIntoThePitofSuccess”。这个网站的文章曾经集结成书出版，中文版译名为《高效能程序员的修炼》
这个原则翻译起来很奇怪：“掉进成功的陷阱”。但是如果你阅读完原标题的那篇文章之后，你会明白他想表达其实是：好的系统应该让开发变得容易，使得程序员很容易就能做正确的事情。
举个非常简单的例子，在早些年还在用jQuery或者是Backbone进行开发时，如果你本地想搭建一个应用的开发环境非常简单：1)去