对低代码平台发展的争议
说到低代码，悲观的人说它是毒瘤，认为低代码的目的是为了革程序员的命，是要把程序员的手脚给捆住，是要束缚程序员的创造性，是要把复杂的现实世界强制机械化、特例化、流程化；
乐观的人说它是银弹，认为原有的开发模式存在诸多弊端，比如开发技术要求门槛高、跨界难、技术栈长、系统维护繁琐，而低代码技术路径正是缓解这些问题的有效手段。
作为一名理性的开发人员那到底应该怎么看呢？
我认为要看技术趋势和市场认可情况，软件开发工程作为项目工程的一种，需要考虑范围、进度、成本这些基本要素。任何有助于提高进度，降低成本的技术手段都是非常受欢迎的。而低代码正好是为了提高开发效率，降低开发技术门槛而产生的一门技术，可见的未来肯定会在软件工程中有自己的历史地位。所以怀疑低代码的人大可不必，不管是怀疑它还是痛恨它，它终将会普及开来。
基于现有的低代码项目落地情况，可改进的方向在哪儿
- 一个重要改进点是：如何有效解决强逻辑场合下的可视化配置方法，这是 Low Code 采用无逻辑的结构化数据描述业务常见的重要短板。
- 要有快速部署能力，最基本的需要一键导出所有运行时需要的文件，最好能做到一键部署和运行时，这样的能力将给业务的小伙伴提供巨大的便利，大幅减少他们的试错时间。
- 低代码平台需要关注生成的 App 的可测试性。如果生成的 App 是一个黑盒，出错时无从下手，日志打印惜字如金，要是这时候平台再对业务团队的困境置之不理甚至推诿，那无论是谁都会厌恶这样的开发方式的。
- 低代码平台需要支持多人协作开发，当业务越来越复杂，多人协作是刚需。这个问题往往在平台建设初期就容易被无视，在后期随着应用的复杂度上升后才被提出，这时候再去实现，成本会非常大。此时平台有可能会简单粗暴地采用互斥的方式来掩耳盗铃。
- 兜底能力也是很重要的。低代码平台不可能面面俱到，它总有能力边界，但这个能力边界不能束缚业务团队的探索。业务需要紧随市场甚至引领市场，而市场是千变万化的，任何公司都无法决定，所以要把“业务提出低代码平台能力之外的需求”当做一种常态。此时，低代码平台需要有一种策略帮助应用快速实现需求，哪怕直接上手编码乃至 Hack。这样的策略就是兜底策略。
- 还有一些增值功能，包括 UX 设计规范自动对齐、提供 UX 设计稿转代码（D2C）能力、App 的可维护性、App 的埋点 & 数据采集、App 的开源合规治理、App 的安全漏洞治理、App 的性能等等。简单来说，这些都是低代码平台的亮点能力，并且是拉开与 Pro Code 差距的重要能力。
