低代码，没有想象的那么容易，一个过来人的吐槽（低代码的概念）
我一个小镇青年，大学学的电子信息专业，毕业几年过后，就一直开始承接外包项目，才开始还行，团队小，业务不复杂，小日子过得还算不错，这种样子持续好几年，中途兜兜转转，团队也没有做大做强。有天突然幡然醒悟，找到了原因，就是团队一旦规模大了，研发质量不可控，研发管理难度太大，很难保证多快好省完成项目交付，我相信这是很多小的开发团队的通病。
找寻了很久之后，发现自己要构建低门槛开发框架（现在所谓很火的低代码开发工具），是解决这个问题的核心关键，然后找了一个志同道合的投资人，开始了跌跌撞撞的研发工作，一边保持日常的项目外包，一边开启烧脑的做低代码，我们的产品名称为JVS，通过几年的推进，现在产品也算是成型了，两次推到完全重来的经历回想起来绝对是漫长的恐怖片。
一开始我们最简单的想法是，低代码开发就是像Delphi、VB那样拖控件，然后功能就实现了，但这种就有个问题，那就是业务逻辑复杂化后，很难通过拖拽的组件实现复杂的业务，这样导致整个平台的灵活性受到限制，特别是开发很多业务需求复杂的定制的软件功能时，基本上这个东西对关键的问题解决使不上劲了。
后面为了要满足很多定制化的需求，结合市面上看到的已经有成型的代码生成的框架，又开始推进，借着mybatis这种就可以在数据库更抽象一层来获取元数据，由系统自动生成一些通用的crud的代码，这样可以缩减程序员的机械性重复性的劳动，程序员补充相关的逻辑代码。这个过程一直持续了好久，在生产项目上也是使用这种方式，但真正执行下来，分析出来的结果，并没有省掉多少开发工作量。又开始绞尽脑汁找原因。
我们发现，在很多外包项目过程中，甲方的领导高瞻远瞩，但是他们内部缺乏IT建设的专业性人才，往往在落地设计业务需求的过程中，缺失承上启下的过渡，那么这个过程中，就非常考验我们的产品经理，产品经理理解能力、沟通能力强，且干事情积极主动的项目 ok，一旦缺失任何一个方面的执行力，项目铁定会出问题。当时就要 寻求一条新的路，去优化这个问题。
我们找到一个关键点，传统的产品经理或者需求经理 设计原型 需要给客户看设计图或者axure，很多客户看不懂，很难意识到交付的预期效果，那么是否能把产品经理设计原型这个步骤改进为直接配置可见的业务系统，并伴有简单的业务操作逻辑，客户直接上手操作，这样大大缩短前端还原，客户需求确认的过程，客户看到的实际系统更加具象化，需求确认之后的变更大大缩减，从而减少了大量的研发浪费。 当然这个前提要求是产品经理配置的工作量不能太大，门槛不能太高。
当时参考多种技术与产品，像Sap不光是做到这种元数据的动态加载，还做到了像程序的在线编译，不需要通过传统的编译发布，这点像在java的groovy语言一样，可以动态编译运行。同时，也思考权限控制，需要比传统的信息管理系统更加灵活，可能需要控制到数据行的权限，权限的方式也更多。这样有了权限 元数据管理 动态语言，基本上就可以搭起来了。后面需要加入像OA这种动态表单设计，实现和数据库互通，解决传统OA只是文档的问题，把表单提交的数据放入数据库中，配搭对应的逻辑执行，让配置的功能真正能跑起来。
再后面就是整个系统的多租户设计，还有像复杂查询条件，多种界面控件，内置报表集成，API和界面的动态生成，有的是加入了代码生成器，对于复杂应用可以生成代码，再用程序来调式应用。
这样设计出来的整个系统需要很多引擎，与数据库交互的动态数据引擎，实现表单功能的设计引擎，实现列表页配置的列表配置引擎，实现报表功能的引擎，实现动态功能的逻辑引擎，实现人工业务流转的流程引擎，实现权限管理灵活性的方案，实现数据管理的功能的方案，实现API开发的动态化，实现界面动态设计的引擎。这些你想全部都集成完美，实际上是一个很大工作量，如同开发一个高端动态化的ERP引擎一样，这样实现后，一个明显的缺点就是整个程序很重，如在加载时需要加载很多库，也需要专业的经验去操作。
当然优点也是很明显，就是开发速度快，数据私有化安全可控，对人员的依赖度远远低于传统开发，而且是基于柔性的交付，灵活性相对于传统系统要高，基本上属性配置、熟悉需求的人员，一般普通的管理系统1-2周的时间就可以配置完成，大大缩短了开发的成本。
但难点就是前期客户不解这些，客户的技术水平一般也不高，需要培训才能使用，或者最好有以前的程序员经验才能使用，这样就限制住了客户，相当于一个半成品的中间件一样，不像传统的产品是一个很简单的使用，这样软件的使用需要有一定的技术水平。
大厂做这些有优势，也有缺点，缺点就是大厂的人工成本很高，对于客户的定制化修改功能成本很高或者基本上就不响应，优点就是可以充分利用现有的资源，快速打磨产品。所以这个也是决定我们的产品与大厂产品的不同之处。
我在市场上看到有的厂家使用PHP来做这样的系统，其实PHP真的不适合做这种高度复杂，N多功能杂化的软件，后面维护起来，像面条一样，一拉动全碗，真的会导致后期复杂度指数增长。软件开发造型时语言最好是选择java或c#这种面向对象的语言，使用分层框架设计，做好整个软件的框架，这样后面可能需要改动的比较小，也比较适合多个团队分开功能开发。
最后发现，我们很多功能与简道云、宜搭的产品在思路实现层面比较相似，或者是殊途同归吧，但区别在于我们侧重于私有化、定制化、构建技术开放的辅助研发工具，而非是靠生态的聚合平台，毕竟体量、资源不同，所以商业模式与出路也不同。
