单页应用详解——(3)开始可维性

单页应用详解（Single page apps in depth）

3. 开始可维性(Getting to maintainable)

本文为译文，原文：http://singlepageappbook.com/maintainability2.html


在这个章节中，我会介绍前一个章节中讲到的东西在代码上是如何实践的。还会讲到通过建立私有的NPM server来发布代码。

让我们从总体原则开始，然后讨论下代码遗产，然后是关于新代码的一些注意事项。今天写的代码就是明天的遗产，尝试避免坏的习惯。


总体原则（Big picture）


使用构建系统和支持细粒度封装的模块规范。不要使用命名空间。


独立包和模块。保持app不同部分的独立性，禁止全局变量名，把实例化分隔开，保持可测试性。


不要把状态和定义混淆。载入一个模块不应该引起副作用，把实例化代码单独放到一个地方，并保持它的小巧。


尽量小的暴露外部接口。保持公用接口小，定义清晰，让你的代码更容易重构。




从你的构建中提取模块/包


首先，做一遍基础的代码检查，避免上一章提到的一些不良问题。


然后，把代码文件移植成CommonJS模式:明确的require(),一个文件只有一个export


下一步，审查下你的架构。尝试把一些毛球(hairball)代码分割到独立的packages。


模块和其它可重用的代码(共享的views/visual组建)应该属于一个common包。这应该是整个app的核心。尽量保持common包里的代码是无状态的(stateless)。其它包里的东西基于它去实现。

那么在core/common package之上，这些小的片段又是怎样的呢？基本上就是app中德一些主要的activity。要加速app的加载就要保持每个activity package可以载common包加载完之后立即接在。如果你的启动比较复杂就可能需要一个单独的机制来控制调用正确的初始器。

为解决状态的初始化，把每个package的初始化代码转移到一个地方：index.js。开放一个initialize()方法，接受一些参数来启动整个模块。每个模块就像一个mini-app，不用关系全局的状态。

反思你的继承链，在大部分情况下对于面向使用的API类是一种糟糕的方式。扩展一个类需要你了解这个类，往往又依赖细节实现。API由简单的函数组成才是王道，API通常看起来像状态可操作的库(比如add,remove一个invite)。当依赖views初始化的时候，views通常挂载在API上。

不要views之间继承。可以继承在framework，但是不要继续继承views。

....略，

后续参考原文。。

http://singlepageappbook.com/maintainability2.html