写在前面的话

软件研发是个很苦的差事，虽然也很有挑战，让人兴奋。但是，避开研发过程中的大坑，从而享受挑战，避开“苦差事”，才是我们的目的。如果想得到这个结果，每个从业人员最好都能先了解下面的坑：

• 需求、需求、需求。。。。。
  重要的事情说三遍。我们之前的资深经理（现任职百度）常说的一句话就是：“研发是不会造成项目失败的，只会造成Delay；但需求错误，就很容易造成项目失败”

• 有效沟通、有效沟通、有效沟通。。。。。
  沟通有多重要呢？1. 沟通少或有效沟通不够的项目，就算不失败，也基本不会成功。 2. 不会有效沟通的项目成员，未来，将会是团队的威胁，不如没有。

• 选择大于努力
  现在的技术发展，特别是开源的兴起，让研发从业人员被大量的优秀的技术框架/代码/产品所包围。也说是说，绝大多数你想写的并不是核心业务的功能代码，都会有远比你写的优秀的开源代码存在，或是简单的多的技术解决方案存在。选对了用，远比你努力重要多了。

• 把“一定会变化”当成真理
  研发过程中最让人感觉讨厌的是什么？需求变了。这个情况估计每个人都会碰到，而且都想尽量避免出现需求变化的可能。但我的经验是：需求一定会因为什么原因变化的，让你的代码或设计更容易适应变化，才是根本的解决之道。

• 想要质量可控，最好少写代码，只写必须写的代码，而且，容易懂的才是好代码
  从测试的角度来说，每一个未经验证的代码变化，都是质量的一个风险隐患。所以，少即是多。不过，适度才是最好的，这里只是提个醒。

做引擎的前因

我们为什么会做一个所见即所得的企业级服务产品的SAAS引擎呢？千万不要以为我们是因为喜欢啊、追求啊、信仰啊什么的。。。。真正的事实是：被逼的，竞争压力下，为了生存不得不做的。
ToB的经营管理产品虽然是被大家认可的ToC之后的另一个增长点，但这个增长点之下，其实是众多的竞争对手，狼多肉未必多的局面；同时，每个政企事业单位的需求都不一样，标准化产品让企业买账的难度也很高。

定制化要求高，竞争激烈单价低，又很难标准化，这让很多做ToB的软件服务提供商日子很不容易过。

而我们，更是人员较少、资质较差、资源也不足的人马中的一员。想要杀出一条生路，就只能：更快，更好，更便宜。

我们要做一个什么样的引擎?

在这样一个情况下，我们给引擎的需求做了如下的定义

• 足够灵活：
  业务流程可配置，相关页面可配置，术语可定制。最终要求是企业各种定制化的需求，都可以配置出来，而不是写代码写出来。

• 支持模版：
  完成一个企业后，可以通过模版进行经验保存。下一个类似的企业，可以在模版的基础上进行修改就可。

• 移动端支持：
  移动端可以在代码不改变的情况下将拖拽出来的流程和页面展现出来，一次配置，直接使用。

• 支持人工智能：
  我们并不想说很虚的东西，从一开始我们讨论引擎的时候，我们就知道，未来人工智能将会很普及，很可能根本不是一个概念性的东西。所以，为了能生存的久一些，我们也在设计中增加了人工智能的支持。

• 极简的连接第三方的能力
  一个引擎能拖拽出一些看着复杂的页面，就算真的有用估计也是一个”玩具“式的工具。现在的管理软件要想生存，能够支持便捷的与第三方数据互通是一个基本要求了。同时，对于我们的引擎来说，要求会更高一些，毕竟所有的页面和流程都是拖拽出来的，与第三方的连接，也要求 1. 能连接的类型多。2. 连接的方式容易。

技术方案选型

主要技术方案

• 后端：Sails.js, Node.js

• 前端：Vue.js, iView, jsPlumb

• 移动端：ionic

• 数据库：MongoDB, mysql

• 其它：Docker,Forever.js

为什么都是JS语言框架？

• JS语言足够灵活，其可将字符串转化为对象的特性对我们是很重要的一个功能。

• 同一语言可以大大降低开发难度，前后端可以统一使用一批工程师，人员成本，沟通成本都会大大降低。

• JS做服务器虽然有各种问题，但性能很好，稳定性也有一定的保证。对于企业内部管理软件是够用的。

为什么是Vue.js?
选择Vue的时候，说实话，我们并没有因为它好用或者比较流行而选择它。因为现在有大量的前端成型的模版可以使用，选择他们可以减小我们的工作量。我们选择Vue.js的原因是：

• “NPM run dev“:
  在Dev模式下，页面的更新可以直接体现到用户的浏览器中，这种”所见即所得“也正是我们的引擎所需要的重点功能之一。

• 模块化
  Vue.js的模块化是一个很高内聚的模块化方案，基本上一个组件或模块所有的代码都可以写在一个vue文件中。这对于我们通过页面拖拽做定制来说，也是非常重要的一点。

为什么是Sails.js?

• 简单
  只要连接上数据库后，如果想创建一个表，只需要增加一个model,重启一下服务器就可以了。省去了很多其它工作。而且，表的结构与不需要事先制定，这对我们这种靠拖拽来生成数据的要求，非常适用。

• 支持大多数服务器需要的功能
  比如路由，安全，日志。。。而且ORM支持了大多数数据库，切换时只需要改个配置就可以。

选择Sails.js的最核心的原因是因为ORM的强大，如果想增加一个数据集，只需要写入一个data.js在model文件夹下，重启一下就可以了。这给我们自定义提交表单提供了极大的遍历。

为什么是Docker

• 发布简单
  Docker可以将整个发布过程控制在远程就可以，不必在运维人员重新调整对方服务器等等整个过程。

• 运维简单
  如果Docker出了问题，有一系列的方式可以让Docker自动重启，保证服务一直运行。减少了运维阶段的人工成本。

jsPlumb?
选择jsPlumb没有太多特殊的原因，目前在浏览器上可以显示类似Visio效果的开源图形插件并不多。虽然jsPlumb并不完全符合我们的要求，但对于第一版引擎来说，我们选择它也是无奈之举。后期根据情况还会进行一系列优化，到到产品级的要求。

ionic?
选择ionic主要是基于以下几个原因

• 入手简单，开发出的界面友好
  如果想写一个简单的app的话，ionic很类似于用angular写一个html5的页面一样容易。

• 有大量的cordova插件
  包括像文件管理，照片管理，数据库访问，微信共享，极光推送，友盟等等。。。一系列app必备的功能，都有现成稳定的插件可用，大大降低了开发成本。

• 重要界面可替换为原生
  ionic可以相对简单的将部分重要页面替换成原生，达到最高的性能。给未来产品进一步优化提供了可行型。对于想一直发展的产品来说，这也是很重要的一点。

这样，ionic可以帮我们：前期快速开发，后期有空间优化。

能连接什么样的第三方？

设计初衷

• 第三方提供了API的，可以连通。

• 能够访问第三方数据库的，可以连通。

• 第三方支持导入导出的，可以连通。

• 可以在web上访问第三方页面数据的，可以将数据接入我们平台。

• 通过配置连通，不是通过代码连接。

这里面有一系列的技术，因为比较多，我计划在单写一篇博客来说明吧。

不过，在这个方案设计的过程中，我们也有几个很好玩的发现，在这里分享一下

• 数据不是全必须有API才能交互：
  这是在我们最初设计的时候碰到的一个困难，很多第三方系统都很难得到API的，如果依赖API，将会让你的成本和周期大大增加。可如果扩展思路来考虑，得到数据的方式其实很多种：导入/导出可以，数据库可以，API可以，从页面直接抓取也可以。我们就是将这几项全放在一起来考虑的。

• 数据不是最重要的，能进入业务流的数据才重要：
  我们最开始设计我们引擎的时候，引入了一个叫“术语”设计器的模块，其实没多复杂，就是让使用者可以根据自己的业务特点来定义自己企业内部的术语的表现方式。后期才发现，这个设计在与第三方数据交互的时候起了一个意想不到的作用：通过术语设计器，可以将第三方数据直接引用流程中去。这样，我们就可以不必要求第三方形成标准化联盟等等非常难以业务实现的要求。

所以，有时候技术对业务的推动，不只是支持，有可能是“变不可能为可能”

写在本文最后

时间的原因，虽然还有很多没有写全，甚至包括写的部分也只是草草的完成，但也只能先节一段落了。不全的部分，会在后面的系列文章中逐渐加全。

当然，光有文章没有代码也很难说明问题，我们团队也在计划将引擎在10月下旬开源出来，目前开源位置已经创建，如果大家有兴趣，也可以关注。
http://git.oschina.net/yanglf…