如上所述，软件开发是一项非常艰苦的工作，尽管它也非常具有挑战性和令人兴奋。但是，我们的目标是避免研发过程中的大坑，享受挑战，避免“苦差事”。如果你想得到这样的结果，每个从业者最好首先了解以下陷阱：需要，需要，需要。....重要的事说三遍。我们以前的资深经理（目前在百度工作）经常说：“研发不会导致项目失败，只会导致延迟；但如果需求不对，很容易导致项目失败。”有效沟通，有效沟通，有效沟通。....沟通有多重要？1、沟通少或者有效沟通不够的项目，如果不失败，基本也会失败。2、不能有效沟通的项目成员，对团队未来是一个威胁，还不如没有。选择大于努力当前的技术发展，尤其是开源的兴起，大量优秀的技术框架/代码/产品围绕着研发从业者。也就是说，你要写的大部分功能代码都不是核心业务，会有比你写的好得多的开源代码，或者会有简单得多的技术方案。选择正确的一个远比你的努力更重要。以“会变”为真理的研发过程中，最烦的是什么？需求变了。这种情况估计大家都会遇到，都想尽可能的避免需求变更的可能。但我的经验是：需求肯定会因为某种原因发生变化，让你的代码或设计更容易适应变化才是根本的解决办法。如果要控制质量，最好少写代码，只写必须写的代码。此外，好的代码易于理解。从测试的角度来看，每一次未经验证的代码改动都是一种质量隐患。所以，少即是多。不过，适度为上，这里只是提醒一下。做引擎的原因我们为什么要做一个所见即所得的企业级服务产品的SAAS引擎？不要以为我们是因为喜欢、追求、信仰等等才去做的。...真实的事实是：迫于压力，在竞争的压力下，为了生存不得不做。虽然ToB的业务管理产品是大家公认的继ToC之后的又一个增长点，但是这个增长点下其实竞争者很多，狼也未必多；同时，各个政府、企事业单位的需求，企业购买标准化产品的难度也很大。定制化要求高、竞争激烈、单价低、标准化难度大，让很多ToB软件服务商日子不好过。而我们是人员少、资质差、资源不足的人群之一。要想杀出一条生路，只能：更快、更好、更便宜。我们想制造什么样的发动机？在这种情况下，我们定义引擎的要求是足够灵活的：可以配置业务流程，可以配置相关页面，可以自定义条款。最后的需求是可以配置企业的各种定制化需求，而不是写代码。支持模板：企业完成后，可以通过模板保存经验。下一家类似的企业可以在模板的基础上进行修改。移动端支持：移动端无需更改代码即可显示拖出的流程和页面，一次配置，直接使用。支持人工智能：我们不想谈论虚构的东西。从一开始讨论引擎的时候，我们就知道人工智能在未来会非常流行，可能根本就不是一个概念上的东西。所以，为了生存的更久，我们在设计中也加入了人工智能的支持。极简的第三方连接能力一个引擎可以拖拽一些看起来很复杂的页面，即使真的有用，也很可能是一个“玩具”工具。现在的管理软件要想生存下去，支持与第三方方便的数据交换是一个基本要求。同时，对于我们的发动机，要求也会更高。毕竟所有的页面和流程都拖出来了，和第三方的连接也需要1，连接的种类有很多种。2、连接方式简单。技术方案选择主要技术方案后端：Sails.js、Node.js前端：Vue.js、iView、jsPlumb移动端：ionic数据库：MongoDB、mysql其他：Docker、Forever.js为什么都是JS语言框架？JS语言足够灵活，其将字符串转换为对象的特性对我们来说是一个非常重要的功能。同一种语言可以大大降低开发难度，前后端可以统一使用一批工程师，人员和沟通成本会大大降低。JSserver虽然存在各种问题，但是性能非常好，稳定性也有保证。对于企业内部管理软件来说已经足够了。为什么选择Vue.js？在选择Vue的时候，说实话，我们并不是因为好用或者流行才选择它的。因为有大量的前端成型模板可供选择，选择它们可以减少我们的工作量。我们选择Vue.js的原因是：“npmrundev”：在Dev模式下，页面的更新可以直接反映在用户的浏览器中。这种“所见即所得”正是我们引擎所需要的关键特性之一。模块化Vue.js的模块化是一种高度内聚的模块化方案。基本上一个组件或者模块的所有代码都可以写在一个vue文件中。这对于我们通过拖拽页面进行自定义也是非常重要的。为什么选择Sails.js？只需连接数据库，如果要创建表，只需要添加模型并重启服务器即可。节省了很多其他工作。而且表的结构不需要事先制定，非常适合我们通过拖拽生成数据的需求。支持大多数服务器所需的功能，例如路由、安全和日志记录。..而且ORM支持绝大部分数据库，切换时只需要更改配置即可。选择Sails.js的核心原因是因为ORM的强大功能。如果要添加数据集，只需要在model文件夹下写一个data.js，重启即可。这为我们的自定义提交表单提供了很好的遍历。为什么Docker发布简单？Docker可以远程控制整个发布过程，无需运维人员全程重新调整对方服务器等等。运维简单如果Docker出现问题，有一系列的方法可以自动重启Docker，保证服务继续运行。降低运维阶段的人工成本。jsPlumb？选择jsPlumb的特殊原因并不多。目前能在浏览器上显示类似Visio效果的开源图形插件并不多。虽然jsPlumb并不能完全满足我们的要求，但是对于第一版引擎来说，我们选择它也是无奈之举。后期会根据情况进行一系列的优化，达到产品级的要求。离子？选择ionic主要基于以下几个原因：容易上手，开发的界面友好。如果你想写一个简单的应用程序，ionic就像用angular写一个html5页面一样简单。cordova插件很多，包括文件管理、图片管理、数据库访问、微信分享、极光推送、友盟等。..App的一系列必备功能都有现成的稳定插件，大大降低了开发成本。重要的界面可以替换成原生的ionic，相对容易的将一些重要的页面替换成原生的，达到最高的性能。为未来产品的进一步优化提供了可行的模型。对于想要保持增长的产品来说，这也是很重要的一点。这样，ionic可以帮助我们：前期快速开发，后期空间优化。可以接入什么样的第三方？设计的初衷是可以对接第三方提供的API。能访问第三方数据库的就可以连接。第三方支持导入导出，可以对接。那些可以在网络上访问第三方页面数据的人可以访问我们平台的数据。通过配置连接，而不是通过代码。里面有一系列的技术，因为有很多，打算写一篇博客来讲解一下。不过，在设计这个方案的过程中，我们也有一些有趣的发现。跟大家分享一下，并不是所有的数据都必须要有API才能交互：这是我们最初设计的时候遇到的一个难点。很多第三方系统很难拿到API。如果你依赖API，你的成本和周期会大大增加。但是如果你扩展一下思路，其实获取数据的方式有很多种：导入/导出、数据库、API、直接从页面爬取。我们只是将所有这些项目放在一起考虑。数据不是最重要的，能进入业务流的数据才是重要的：我们最初设计我们引擎的时候，引入了一个叫做“term”设计器的模块，其实也不算太复杂，只是为了让用户自定义根据自己的业务特点来定义术语在自己企业内的表达方式。后来发现这个设计在和第三方数据交互的时候起到了意想不到的作用：通过designer这个词，可以在流程中直接引用第三方数据。这样，我们就不需要要求第三方组建标准化联盟等业务上很难实现的要求。所以，有时候技术对业务的推动不仅仅是支持。这可能就是本文最后写“makingtheimpossiblepossible”的原因。,但只能是段落开头。不完整的部分会在后续的系列文章中陆续补充。当然，只有文章没有代码是很难说明问题的。我们的团队还计划在10月下旬开源该引擎。目前开源位置已经创建。有兴趣的也可以关注一下。http://git.oschina.net/yanglf…
