?? ? ? 前几天看到关于“低代码开发”的话题，简单的谈了些自己的看法，也看了一些朋友们各抒己见的好文章，今天想结合我们实际使用的开发平台和大家再做些探讨。
? ? ? ? 在平台的简介中首先提出了这个大家一定很关心的问题：
一、“为什么使用低代码？”
“低代码工具可让主题专家 (SME)?最接近挑战，设计出相应的解决方案。”
? ? ? ?因为是翻译的原因，对于SME（Subject Matter Expert）采用的是直译，而从我们实际的系统开发中来看，这就是那个我们能获得准确需求的关键人物（或团队），一般是对用户核心业务及流程非常熟悉的人，从传统的系统开发场景中，要让这个关键人物写出一份完整、准确且结构详尽的需求文档，是一件很困难的事，主要面临以下几个难点：
1、这样的关键人物往往事务繁杂，很难有整块的时间和我们的开发人员进行细致的沟通；
2、最要命的是用户的业务专家，往往没有系统思维，对他们而言计算机程序严谨而刻板，他们会“飞星四溅”的把脑子里想到的所有内容，跳跃的，间断的，泉涌式得喷薄而出，在激情散去的一刹那丢出一句，“我这么讲，你们一都听明白了吧？”
3、我们的开发人员在半懂不懂的状态下，不断的提供根据自己想法和理解，设计的系统原型，而这相当于是在给专家启发和授课，得以让他产生不断调整和修改的思路和建议。
? ? ?总之，这样的过程是痛苦的。低代码提供了一种可能，让专家可以自己通过初步了解库、表、字段之间的关系后，开始进行业务内容的布局和规划。这样的方式对于开发实验室运行这样专业性强、且内容繁杂的系统是非常适合的，也是经过我们多年实践证明是有效的。当然这里还会有很多的方式方法和前提条件，在不同的开发场景中需求大家去领悟和调整，始终需要记住一点——“无论是怎样的开发模式，都只是工具，而人是活的，能根据实际状况正确使用工具才是好的方法”。
? ? ? 讲到这里，会有一个很重要的点被大家所忽略：我们大多数程序设计和开发者，总是在强调用户缺乏系统思维，需求讲不清楚，但是从提供服务的角度，是不是首先要想想自己有没有从业务角度出发，是否具备了业务逻辑思维呢？低代码不仅对用户有很大帮助，实际上对我们的项目经理也非常有用，往往可以不受后端、前端的限制，可以自己把充分了解的需求形成demo，无论在与用户，还是团队小伙伴的沟通中，会比PPT和流程图来得更亲切和有效。
? ? ? 低代码开发的优点显而易见，但是这个优势往往只被用于构建相对简单或者临时的一些应用开发中。事实上，通过我们这几年的实际开发经验和成果来看，如果业务专家和高水平的低代码系统开发者能长时间保持实时的沟通，是可以更充分的发挥低代码开发平台的优势，构建出应对复杂业务的系统，这个系统的可用性和易用性，是传统开发方式完全做不到的，我认为，这才是低代码开发平台真正的价值所在——“为其不可为也！”
? ? ? 以目前很多低代码平台，主要还是强调了简单化应用的开发，没有突出复杂应用的开发，实际上在欧美、日本、乃至台湾和香港地区，有一半以上世界500强的企业，在用其构建“核心数字化系统”，在国内还处于起步阶段，当然这和目前国内大多数用户的管理者中，很难找到我所描述的具有系统思维的业务专家有一定关系。
? ? ? 再强调一点，无论低代码开发平台只是工具，而如何利用好这个工具和复杂业务之间的关系，从而能开发出超出用户预期的产品，才是我们所具有的真正价值。之所以强调我们程序设计和开发者应该予以重视，是因为这种模式为大家的职业发展方向提供了一种很好的选择，你不一定要在软件或者信息化公司不停的内卷，更多优秀的开发者，当你对具有业务逻辑和思维有一定信心的时候，你可以去很多大型或者成长性好的企业工作，去协助他们在低代码平台上构建核心业务系统，未来你也会伴随着核心业务不断成长，无论是职位还是薪酬都不用愁，你也可以在自己的领域，成为那个人人都爱的“DYH”！
关注“实验元”老李（latteinfo)，共享高质量数据服务，让一切变得简单！