update

temp/05.md

@@ -1,10 +1,10 @@
 Web应用的组件化开发（三）
 ====
 
-协作机制
+架构与协作
 ----
 
-在前面两篇文章中，我们叙述了组件化开发的基本原理和管控机制，这就相当于工厂引入了新的生产流水线。光有设备不行啊，最终在这个流水线上面操作的是人，本篇和下一篇都将从人员的角度来谈谈。
+在前面两篇文章中，我们叙述了组件化开发的基本原理和管控机制，这就相当于工厂引入了新的生产流水线。光有设备不行啊，还需要有对产品的一些规划过程，然后才能去生产。
 
 开发一个大型系统，最重要的是什么呢？是可控性。大系统最害怕开发过程失控，首先就要求整体架构是良好的，如果部件出问题，比较容易调整，整体出问题就麻烦了。所以，作为大型系统的架构师，最重要的感觉就是一切尽在掌控之中。那么，如何解决可控性的问题呢？
 
@@ -16,7 +16,7 @@ Web前端这个领域有些像很多年前的客户端软件开发，最开始
 
 这个方面，目前关注的人还不是很多，但在一些大公司，比如阿里和百度，已经很多有识之士看到了这里面可做的事情，并且有一些成功的案例了，比如百度的FIS。
 
-#1. JavaScript代码的架构
+#1. 建模
 
 Web应用系统中，JavaScript是一切交互的核心，但JavaScript本身是一个比较松散的语言，这样的语言来做大型系统，可靠性方面需要做很多事情来保障。传统的构建大型系统的语言，比如Java和C#，都有很多反向工程的工具，比如根据代码生成UML图，这就从一个方面让架构师能随时了解自己项目的结构和依赖关系，有机会去调整一些不合理的地方，而这些调整又可以反过来作用到代码上，这些过程很大程度上能让项目的整体稳定，因为它的重构成本是比较小的，这些重构可以不太打断开发过程，在一次项目开发过程中，能够有机会多次重构，从而降低了很多风险，消除掉绝大多数隐患。
 
@@ -26,5 +26,53 @@ Web应用系统中，JavaScript是一切交互的核心，但JavaScript本身是
 
 如果在构建一个大型系统之前就有机会把它的模块依赖关系和交互都描述出来，并且以图形的方式展现，每个开发人员都有机会看到系统的全貌，然后从这些图形化的描述再生成代码的基本骨架，填充内容，逐渐看着这个系统有血有肉，活泼生动起来，每个人的成就感都会非常强烈。
 
+很多时候，架构师并不是一开始就能把所有东西都搞对的，如果做了一半，发现开始有些不合理的地方，想要做些调整，该怎么办呢？举例来说，项目做到一半，发觉在逻辑上，两个并列的目录其实应该是父子关系，想要把其中一个整体下沉一级，移动到另一个下面，这个改动还要尽可能不影响业务的开发过程。
+
 想要达到这些目的，我们的难处在哪里呢？需要把真实的代码和抽象的描述建立这么一种对应关系，能够实时反映彼此的变化。这种对应关系很难在代码中体现，因为代码是一个线性的东西，难以表达立体的结构。所以，我倾向于把这些关系放到外面，逻辑结构跟代码的物理文件分离，互相有联系。
 
+我们先看一个在线UML的Demo：[Online software modeling](http://www.genmymodel.com/ "")，注册之后，可以打开已有的示例，比如Online Shopping Cart，能够查看UML图形。
+
+![online-shopping-cart-diag.jpg](https://raw.github.com/xufei/blog/master/assets/web-components/online-shopping-cart-diag.jpg "")
+
+这个Demo可以大致说明我们的意图，但还是有差别。在这个在线Demo里面，可以直接生成Java代码，我们的思路也大致是要这样。
+
+考虑到JavaScript是一种灵活的语言，我们其实并不需要把类关系整得这么正式，要整出来的实际上是模块的关系，这里的模块可以暂时先理解成AMD那样的。
+
+所以，从模型到代码的这个方向，大致就是先绘制这么一种图，然后从图形生成最初的代码结构。
+
+在很多工具里，也提供反向的功能，就是从模块依赖关系反过来生成依赖图。在Chrome的插件Angular Batarang中，可以对正在运行的Angular系统分析模块依赖关系，生成一个图形。这个图形不太直观，但大致能说明意思了。
+
+我们来看这正反两面，如果合二为一的话，就非常好了，这也就像双向绑定，改数据能同步UI，在UI上操作能影响数据。用这里做比喻，代码就好比数据，逻辑关系图就好比UI，所以我们只要直接把依赖关系抓住，从始至终一直维护起来，就能解决所有的问题了。
+
+举例来说，如果有三个模块，分别是portal.User，portal.Goods，portal.Cart，表示用户、商品、购物车，它们所对应的模块，如果按传统方式，可能是这样：
+
+portal/user.js
+
+    define("portal.User", [], function() {
+        //User
+    });
+
+portal/goods.js
+
+    define("portal.Goods", [], function() {
+        //Goods
+    });
+
+portal/cart.js
+
+    define("portal.Cart", ["portal.User"], function(User) {
+        //Cart
+    });
+
+注意到这里，购物车Cart模块对用户User有依赖，而且三个代码存储的目录也是有所讲究的。
+
+我们打算把它变成怎样呢？
+
+       
+
+整个系统的复用原则是：
+
+除视图以外的所有部分，在PC浏览器和移动端共用。
+如果存在可直接复用的视图层，可以拿出来共用，不强求。
+
+逻辑代码具有通用性的前提是跟DOM层彻底分离，而视图层的通用性其实很小，所以这一块不用特别去强求，即使是响应式设计，在很多地方带来的也可能是更多的负担。