为什么需要引入子模块？

随着代码量的增加，相关逻辑日渐复杂，需要维护的状态和传递的消息也迅速的增加起来。

Elm 的架构文档中并没有详细说明如何组织比较复杂的项目，我调查中看到的文章中的方案也大多仍然需要模块间的耦合，实际使用中并不能得到满意的效果。

期望达到的效果

首先需要做到的是代码层面的分离，模块内部实现细节的修改对外部来说尽量不可见，减少代码的耦合程度，便于开发。

下一个阶段的目标是模块的可重用性，除了简单的函数层面的重用，在更高层次上也有很多相似性，例如如果由于应用场景的考虑，需要发布多个微信小程序的话，其中有不少逻辑是可以共用的，例如微信端用户登录、信息获取，服务后台的 Session 管理，等等。

模块之间的交互应尽量简单，可以用可维护的方式进行组织。

由于工作需要，最近进行了一些目前很热门的微信小程序开发，技术选型的过程和结果都有些值得分享的体会，尝试做个简要的介绍。

先说结果，核心的逻辑采用了 Elm 语言开发，编译到 JavaScript ，界面显示还是标准的 JavaScript 和 WXML。

Elm 是什么?

官网的简介:

A delightful language for reliable webapps. Generate JavaScript with great performance and no runtime exceptions.

翻译成中文大约是：

一门开发网页应用的令人愉悦的语言，生成高性能、没有运行时例外的 JavaScript 代码

过去两周，写了大约 5000 行的 Elm 代码，感觉上面的描述还是挺靠谱的，和手写 JavaScript 相比，确实令人愉悦。下面简单分析下技术上 Elm 是如何做到的。

（这篇文章以概念和经验介绍为主，就基本不上代码了，以后尽量有后续的详细介绍）

从 2012年4月开始，一直都在开发一款平板电脑上的实时战略类游戏，开发平台是当下比较流行的 Unity3D，网络传输部分基于 uLink。是我自己的第一个 Unity3D 项目，在架构上下了不少功夫，项目相对比较复杂，作为架构师和主要的开发者（技术团队一共3个人，其他两个经验都比较少），工作量着实不小，开发过程还是相当痛苦的，相对应的收获也很不少。

目前项目的技术部分基本上算是告一段落，下一步更多的是市场和运营的工作，我的重心也会向服务器管理的部分转移，计划陆续把项目中的心得体会在这里用文字的形式保留一下。

数据

其实广义的说，与计算机相关的所有的信息，包括代码，可执行文件，网络数据包，一切的一切都是数据，取决于从什么方向来看，比如说，源代码是编译器的输入数据，相应的可执行文件则是编译器的输出数据；从操作系统的角度来看，可执行文件就变成了输入数据。

元数据

元数据简单的说就是关于数据的数据，听上去可能比较抽象，其实并没有什么特别之处，例如关系式数据库中数据库的模式就是一种典型的元数据，定义了数据表的内容格式，包含哪些列，各自的数据类型及取值的约束，索引的定义等等，表中存储的内容是数据，模式就是数据的数据，也就是元数据。

缘起

今年1月的时候，公司协办了一次 Global Game Jam 北京站的活动，说是希望能做个简单的有关游戏开发的介绍，开始没太在意，想着应该是个不太正式的交流，也没怎么准备。结果到了一周前的时候才听说活动规模并不小，至少有100多人会参加，而且我的环节也是更像是演讲类型的。于是多少有些紧张，好久没当众说过话了，开始认真的选题，准备幻灯片。

自己做游戏也有一段时间了，技术上的（主要是 Unity 3D 相关的），非技术上的，收获和感触也还是挺多的，所以想了想还是选了一个比较宽泛的题目。用了一两天的时间准备了幻灯片，主要是一些觉的有意思或者也许对听众有点用的提纲，具体的内容想了些大概的轮廓，并没有特别清晰的排练过，想着准备的多一点，到时候说到哪里算哪里，不用注意控制时间，简单的多，说的时候压力也会小些。

活动当天来的人比想象的还多，多少还是有些紧张和兴奋，出乎意料的是除了介绍性的简单内容，准备的要点只说了两张幻灯左右，分配的30分钟时间就没了，准备的最完整的部分基本都没用上。虽然感觉效果还不错（其实从这种活动上，基本上没法真正的学到什么东西，如果能有一些支离的信息能给听众留下印象，或是感到受到了启发的话，对讲者来说就是很难得的了），不过有些意犹未尽的感觉。