应用架构

可以提升团队的工作效率、产品质量和降低维护成本。引用应用架构前须先明确当前存在的根本问题。因为架构方式很多，针对不同的场景，需要对问题有详细的了解之后进行架构改进才能起到效果。

通常存在的问题包括：代码间的耦合和大类型定义。

开发过程中要注意最小化依赖，避免耦合太多导致项目后期花费大量精化处理bug，却不能提高应用质量。

可复用性还包括可以方便的移动代码或添加删除代码。

一个应用团队大约只有1至5个人。当公司慢慢发展，各团队间也会出现耦合，这个架构模式也适合于公司架构，所以架构是一门普适学问。

架构的最终目标是并行开发，互不影响和依赖。

模块化应用可以减少编译时长，也可以使用其它人编译好的二进制来进一步缩短编译时长。Google's Bazel

MVVM架构

Redux架构

应用的状态全部放在一个容器里面，改变状态的方式只能是通过： 原来的状态(state) + 修改状态的动作(Action) => 新的状态(new state)

状态容器(store)中的状态变化事件可以被外部订阅，状态容器(store)接收从外部来的状态修改请求，状态容器把当前状态和状态修改请求(Action)发给Reducer进行具体处理，reducer按照状态修改请求生成一个新的修改后的不可变状态，更新回状态容器里。把所有状态都保存在一块显然是不合理的，所以反状态拆分成子状态，对应不同的响应部分。所有的Reducer都必须在同一个串行线程中运行，大多数是在主线程。

判断一个应用的架构好坏的指标

• 一个新人加入项目后要子解一个功能需要理解的代码行数占总代码的比例，这个比例越小，架构越好。