终于有人把“低代码”讲清楚了！
一、背景
低代码对于我本身而言是挺矛盾的，毕竟工作中我几乎用不到它。一开始接触到低代码的时候我也是有抵触或者鄙视心理的，毕竟手写代码的快乐，沉浸式的那种感觉很少能体验到了。
我也通过最近几年的工作经历慢慢的对其有了改变，尝试去接受它。于是一开始在北京的时候是把它当作一个提效工具，做了简单的低代码实践。但是后来，当我对大规模分布式微服务等有了深入认识后发现，一个企业的服务数量，业务场景岂是一个人能模拟得来的。
所以当我需要去实践分布式，企业级，高并发，大数据，这些内容的时候我发现我好像无法真正构建大规模的企业应用服务。但是因为一些原因我希望尽快搭建仿真的企业大规模的微服务应用，所以我开始了对低代码平台的探索之路。
关于我做低代码的具体动机，以及技术选型等已经在之前的文章中有所说明，这里不再赘述。所以本文就简单聊一聊我对于低代码的理解和我在设计低代码平台的一些理念。
二、对低代码的理解
2.1 为什么要做低代码
这个问题我也问过自己，我做低代码的目的是什么，我真正的诉求是什么，为什么我没有采用其他大佬开源的东西选择自己造轮子。当我开始去看不同的低代码搭建平台的时候，我发现他们能做的工作确实可以降低代码工作量，但是还不足够。
基于脚手架的低代码会绑定多个技术框架或者中间件，或者集成一些菜单权限用户等数据表或者仪表盘，类似于OA这种。基于idea插件的则可以更灵活一点，但是也是需要去基于表构建对应的代码元素。
或者其他框架类的诸如mybatis-generator，可以针对性的构建DAO底层相关的代码从而降低手写的工作量。
但是对于大多数复杂的业务应用其实上面的这些低代码平台是不够用的，这些只生成到了方法级别的，而且只针对于增删改查的简单模版化操作，不够灵活，更多情况下我们真正的复杂代码需要的代码元素远远不止service,entity,dto,dao,mapper,controller,facade。
当我们需要继续实现整个调用流程的时候发现工作量还是有不少的，比如要写文档，要定接口等等。对于前端代码或者前后端一体的其实是一个道理，这里当然只讨论后端Java相关的代码生成。
那么对于类似于工作流或者拖拉拽的低代码平台其实也不是我想要的，或者说不是最高优先级的，因为我本身定位的用户是开发者，首先是自己用的稍微舒服点再让跟自己同类型的用户用的舒服点。
所以，我仍然还是先从后端应用为主，对于业务逻辑的编排或者业务流程的编排这里可能并不能完全用工作流或者编排工具拖拉拽实现，毕竟我只是去模拟仿真企业大规模微服务应用，我也无法想象或者意淫服务之间的大多数交互流程，或者服务内部的交互处理。
因为时间的关系或者跟我本身的诉求方向有偏差，这种类型的低代码对我来说也不是特别合适，当然他们这些先进良好的设计理念，落地实践也给我带来了很多灵感。
在这其中我也了解了一些专门构建低代码平台的创业公司，他们做的已经非常好了，交互，api方面都无可挑剔，所以我认为低代码还是大有可为的。
那么又回到了问题的本身，为什么要做低代码？因为市面上的低代码实现其实还不够低，还不够让人更少的写代码。所以对我而言我的真正诉求就是实现一个低代码平台，尽量覆盖更多代码元素，尽量写更少的代码。所以少写代码，唯快不破才是真理，当然早点下班是正经的。
2.2 低代码带来了什么
有些大佬或者有些相关的从业人员会追溯20年前的托拉拽式的低代码场景。那时候就有人通过图形化的界面帮助快速构建企业要用的软件系统了。
所以低代码本身带来的是整个软件行业的改变，从图形化到人机交互到数据处理，低代码的一个显著特征是提高软件构建交付效率，提高软件企业营收。
当然也让更多人意识到随着软件技术的发展软件系统的开发实现不再是高精尖，而是逐步变得大众化，人们认知应用上更加成熟了，有种走进千家万户的感觉。
当然另外一方面也带来了一些惶恐，比如像我这样开发了一个低代码像是在革我自己的命，我有时候会想到我写的低代码会不会把我替代了。
更多的时候是很多程序员依然担心因为低代码会让自己丢了饭碗，但是有些就不会，毕竟低代码依然无法撼动他们在企业软件开发的某一个角色。因此对于低代码有抵触心理的程序员对lombok等提高效率的工具组件依然抱有蔑视心态。
但是不管怎么样，低代码已经存在了，而且发展了几十年，从低端的到高端的，都没有出现大的变革，对于作为程序员的我们该怎么做，我认为可以保持开放和警惕的心态，时刻保持终身学习的态度，毕竟现在我敢说低代码真的无法完全取代程序员。
2.3 低代码的瓶颈
这里我也对低代码的瓶颈简单聊一下，说白了低代码在很多有点动手能力的都可以随手就来，但是能不能做好就不一定了。所以对于低代码实现而言是很容易达到瓶颈的，比如基于某某技术栈体系，基于自研的框架体系，基于某某工具体系等等。
这里的瓶颈制约着企业无法发挥出低代码的更多价值，或者我们仅仅只是看到了低代码用自己的方式替代了人工的方式，而没有看到它可以展现的其他潜力。
2.4 低代码的缺陷
1、无法识别业务
对于低代码而言它其实是一个平台工具，或者平台应用，那么对于平台应用而言要做到非常强大肯定不能去识别业务，不能感知业务的存在。
那这样的话，一个需求从产品层面到落地如果进入到低代码平台中可能没人能完全懂里面是什么逻辑，就拿拖拉拽或者是流程编排式的低代码应用来说也是不能感知业务逻辑的，或者不能很好的梳理整个业务逻辑。
2、无法跨越编译运行的鸿沟
这个观点是我在前两个月低代码讨论的火热的时候提出的，跟群友们吹牛的时候说的。我这么说的意思是因为计算机本身的底层(网络，硬件，操作系统等)与上层语言应用天然存在层间隔离，那就导致几乎所有除了低级语言能直接在应用上跑而其他语言需要编译一下借助对应的容器环境才行。
所以当我们通过低代码构建应用逻辑的时候我们依然需要去借助人工也好借助机器平台也好去让他变得可运行。
所以不同语言，不同技术体系下依然需要对应的工具平台去辅助完成低代码从创造到运行的完整过程。
比如宜搭等这种轻应用的基本上是可以做到0代码的，所以这种可以很容易翻越这个鸿沟。但是当我们需求有变化或者提供应用环境的云厂商出现了问题那么依然需要开发者对其做可用性的保证。
3、低代码代替不了所有软件编程工种
这里是可以怼低代码的最佳理由，毕竟我说我是做php的它也不能咋的，大不了我可以做C。所以对于低代码而言数据分析，大数据，中间件，嵌入式，或者是工具类平台系统它都只能尬笑。
4、低代码无法修改它创建的东西
这个其实就是说我们可以用低代码创造代码，但是无法修改它，就像人一样，你无法控制你的孩子未来每一天都按你的规划去过活。假如我流程编排可以，配置化可以，托拉拽可以，但是保不齐哪天需求多了，修改多了，改配置也变得跟改代码一样了。
2.5 低代码的悖论
这里我对于低代码的缺点分了三条，上面已经讲了两条了，这里我分享一下关于低代码的几个悖论：
低代码只能无限趋近于0代码 用低代码创造低代码 低代码创造还是修建
上面两条可能有点玄乎所以了，所以这里简单跟大家解析一下，第一条的意思可以用数学的概念去解释，就是说低代码的极限情况下可以约等于0代码，但是绝对达不到，类似于数学中的无限大或者无限小。
当然第二种就类似于俄罗斯套娃，或者你可以简单理解为先有鸡还是先有蛋的场景。如果低代码有那么它不是0代码，如果低代码没有，它创造不了低代码。
第三个其实算是低代码缺陷的一种，这里姑且算一个悖论，就是低代码可能无法感知到要创建的东西其实已经创建过了，只是修改了。
2.6 低代码是银弹吗
那些非常遵奉低代码的人可能会说出这种话，但是对于受到软件编程毒打的人是万万不信的，毕竟产品改需求的次数低代码翻脸都反应不过来。
2.7 低代码是毒瘤吗
这个问题跟2.6一样，稍微理智一点的或者见识多了也不会说这种话，毕竟有很多人去做了低代码，然后说它可以帮你早点下班，对于程序员来说没人不想去了解它。与其说是毒瘤，我觉得倒不如像是抚媚的妖女，你懂得，有时候你会因为修改变更倒排期等等因素受到它的蛊惑。可能是因为我们对其期望太高，期望它能背负起从需求到上线的大部分责任。但是期望越大失望也越大，企业不可能指望它可以帮助我们应对产品的需求变更，实现更多业务价值，偿还技术债务等。所以说不公正不客观的去评价低代码是不合理的。
2.8 简评零代码的低代码平台
对于号称0代码的低代码平台而言，就像是微信公众号的广告文章一样，看个标题就相当于阅读了全文。
三、低代码的定位
3.1 脚手架
其实低代码的功能可以从框架或者技术栈延伸出来，当作脚手架的一个特色功能，所以这里可以将低代码定位为脚手架，帮助软件项目进行一些高效的构建任务。
3.2 代码生成工具
如果更专业一点或者说将其从脚手架脱离出来单独发展则可以成为代码生成工具，包括最简单的lombok,idea插件，数据库实体生成工具等等。这里的工具级别是做针对性的生成和解决，提高开发效率。
3.3 代码生成平台
如果从生成工具丰富到一定程度则会演变成一个代码生成平台，此时从平台视角来看他有更多的能力特色，比如技术栈定制，流程编排，可视化等等。
3.4 代码生成应用
从平台到应用其实也是有一个跨度或者进化的，这里所指的应用是那些靠低代码和周边技术服务来创业的商业公司的应用产品。到这个地步低代码已经可以与需求管理，发布迭代管理，云环境交付等结合在一起了，真正实现闭环式的应用软件构建生态。
四、总结
低代码未来一定还存在，不同的人对其有不同的态度，对于我而言我只是想一次性构建，后续工作中学习中都可以帮助我快速达到构建软件雏形的目的。所以低代码再怎么智能，还是需要程序员去调教的。好了，本文从网上热议的一些话题结合了我本人的一些想法对低代码本身做了一些探讨，希望能给大家带来不一样的观点和思维火花。
作者简介：神帅
毕业5年,混迹于大小厂打怪刷实战经验。
资深Java开发工程师,是个宝爸,热爱生活做饭,读书,在企业服务领域和电商领域均有积累,
最近一直在研究DDD和低代码领域,对后端微服务业务平台架构的实践和发展比较感兴趣。
公众号:神帅的架构实战
CSDN:https://blog.csdn.net/u010504064
推荐阅读：
欢迎关注微信公众号：互联网全栈架构，收取更多有价值的信息。