低代码开发的问题 Low Code Problems
低代码开发的问题
低代码/无代码开发如今也成为了一个热门话题，而我自己也深入到一个 Power Platform 的项目实践中，有了一些体会了，也分享一些自己的想法，供大家参考。
低代码开发会很快吗？
第一印象确实如此，我使用的是微软的 Power Platform，整个过程就象是早些年使用 Access 数据库一样（我认为 Power Apps 就是基于当年的 Access 开发的，把 Access 搬上了云就成了现在的 Power Apps 了。），建了一个数据表，设计好字段，维护数据的界面（Model-driven App）就已经有了，填上些数据，然后再一些简单的操作，在 Canvas App 上面摆好控件，连接上数据，相应的功能也就出来了，而且很快就能发布到手机、平板或电脑上测试和使用了。
市面上还有一些其他的解决方案，都没有深入使用，不做评论，相信各有特色，如果是基于代码开发，只是增加了程序员的便利性这类的，应该还好，毕竟必要时还可以用代码来进行后续的开发，但如果象微软这样，完全封闭的开发的模式，对于长期战略性的项目可就不乐观了。
总体的感觉就是，类似 Power Platform 这样的低代码或无代码开发，只适合做一些短生命周期（几个月）、小场景应用（公司内、部门内）、简单业务逻辑（局部、单一需求）、不多于三人（再多就容易混乱和失控）协同开发的原型或演示性项目，仅用于个人或少数人群解决一个具体而简单的临时性问题比较适合。 对于公司长期战略性的业务或产品，最好不要采用，因为迟早都会面临不得不推翻重做的境地。
为什么会被称为“行业毒瘤”？
详见此文《“行业毒瘤”低代码》
文中徐昊认为以降低程序员门槛为目的的低代码是行业毒瘤。主要原因有以下三点：
- 第一，低代码平台预设的使用人群永远是初级、入门的人
- 第二，低代码平台暗藏巨大的变革成本
- 第三，风口不代表长期发展，低代码其实是个伪需求
我个人是有同感的，真正专业的开发人员的价值常常是被低估的，虽然市面上有所谓10陪效程序员、百倍效程序员的说法，但现实中却通常并没有这样的“待遇”，行业内外其实也没有很好的评估方法，软件开发人员的水平参差不齐，鱼龙混杂，再加上软件知识本身的复杂和广博，让软件从业人员很难用一套什么样的标准来简单衡量。
然而真正专业和高效的软件开发人员，确实可以让公司的开发走上正轨，少走弯路，累积价值，短期也许看不出很大的差异，甚至感觉有些慢、有些麻烦，但长期下来，必然会有巨大的不同，产出真正易于扩展、易于维护可不断适应市场需求变化的产品和服务，同时也会积累一批高素质的开发人员，一支技术过硬的开发团队，从而给公司带来真正长期的核心竞争力。
下面以 Power Platform 为例，具体说一下其中包含的问题。
微软的 Power Platform 实际使用中有哪些问题？
- 整个开发环境都在网页上，极大地依赖网速和浏览器加载效率。
- 所有微软网页界面上的 bug 都将会是开发过程中的障碍。
- 保存以后，长期等待，网络的所有延时，也将是开发过程中的痛苦。
- 有可能经历没保存，网页又消失，内容消失的问题。
- 无法多人同时开发、维护、修改同一个 Canvas App， Automate/Flow 等。
- 奇葩的 Solution 概念，你以为各个 Solution 是独立的吗？不，是相通的，因此你不能以为在一个 Solution 里可以独立安全地开发，只有 Environment 才是真正隔离的，但 Environment 是要钱的。
- 谁改动了哪里很难追溯，发布后出现的各种 bug，没有人知道是怎么冒出来的，也不知道是谁因为改动了哪里所造成的。
- 虽然也有 xml, json 一类的源代码，但毕竟开发过程都没看过代码，拿着两个版本的源码来比较，也看不出个所以然。也许只是拖拽了一下，甚至什么也没动，只是按了 Ctrl + S 保存了一下，两个版本的源代码中就会出现大量的不同，怎么比较？
- 谁也无法一次就把程序写得很理想，需要反复推敲和调整，然而低代码的操作界面肯定不如代码那样灵活易修改。
- 单账号每日发送邮件总数量有限制（100封），每5分钟发送邮件频率也有5封的限制。见 Throttling Limits
- 应用中的控件总数有限制，不建议超过500个，超出后加载速度会非常慢。
- 只支持类似 Excel 中的表达式来进行简单的数据处理等功能，无法进行方法、函数的封装和复用，造成大量的重复和冗余，后期要改，慢慢找吧，各处都要改一遍。
- 在 Automate/Flow 中没有正则匹配功能，这需求2019年就有人在社区里提了，至今尚无实现，对于复杂的字符串匹配束手无策，可见严重依赖一个封闭技术的弊端了。
- 没有单元测试、自动化测试等工程化开发实践，虽然有一个预览版的测试功能，但基本不可用于项目实战。
- 简单易用的界面，让新手开发人员习惯于短平快的开发模式，不愿意或不习惯深入的思考，从而导致软件的整个开发和构建缺乏设计思想，只是功能简单地堆砌，无法方便地修改和维护，很多时候会因为设计的缺陷导致无法进一步深入开发或调整的成本大到难以接受。
引深的一些思考
实际项目中，由于采用低代码开发的人员，通常编程素养并不深厚，很多甚至只是业务人员，使用低代码平台时依旧延用 Excel 的建表思维，一张大表包含想要的所有字段，造成大量的冗余和重复，界面以及逻辑等也是代码的直接堆叠，较少考虑重用性和扩展性等，大量的 Hard code，大量啰嗦的 if else 判断语句，任意多层嵌套的 for 循环等，很多逻辑写到后期连开发者自己也搞不清楚具体的逻辑走向了。
所以，即使是使用低代码平台做开发，你也会发现，代码编程素养深厚的开发人员会使用得更加专业和顺畅，然而这些人员肯定是更热爱代码编程的开放性和灵活性的，对于代码开发的大量工程实践也都非常熟悉，所有开发过程中可能遇到的问题也都已经有相应的解决思路和方案。
再说一些反面的示例，就拿写文档来说，新手小白会用什么写文档？自然是 Office 中的 Word 啦，这正好就象是低代码平台的概念，直观的界面，简单的操作，把入门门槛降到最低，大量的市场宣传和垄断效应，让大量用户先入为主，之后导致因为大量人使用，很多人也不得不勉为其难地使用，因为别人给你发来的文档是 Word 格式的啊！ Word 文档自然有各式各样的问题，比如：
- 不同的软件版本无法或不能正常打开不同版本保存的文档
- 格式封闭，无法利用其他工具处理
- 打开文档，格式混乱
- 一些奇葩的文档，格式很难按预想的方式调整
- 不方便多文件全文搜索
- 不方便进行文档版本管理
- 复杂文档将图片、表格、视频、甚至宏一起混杂其中，文件巨大，打开维护困难甚至崩溃损坏。
然而专业人士都用哪些工具来写文档呢？ 初级的使用 Evernote 等云平台，中高级的都会使用各式各样的 Markdown 文档创作工具，最终都回归到事物的本质，文字内容和格式样式的分离，一点点的学习成本，带来的长期收益却是无穷的。 当然更专业的 Latax 可以作为撰写论文、出版书籍的专业排版系统，功能强大而稳定就更不用说了。 Markdown 在这中间完美平衡了这些，已经被广泛接受和使用，更多请参见：纯文本的威力 。
说到这里，我必须提及另一个技术： Git，行内人士肯定都知道，这现在几乎是专业开发人员的命，也许真的不过份，网上和现实中应该可以找到大量这样的实例，如：
我自己当然也有过多次体会，所以才会这么夸张地说。 Git 技术也是这样的，第一印象会觉得好麻烦，特别是对于新人小白，会觉得要记那么多命令才能使用，然而 Git 功能的强大，开放和灵活则是行内人士所共同认可的，底层扎实了，操作界面的问题就好解决了，于是乎就有了 SourceTree，TortoiseGit 等 GUI 的工具，还有 LazyGit 这样的快捷命令和终端界面等来简化命令操作等，如今 VSCode， IDEA Intellij 等开发工具也都深度集成了 Git 和各类 Git 插件等。
以上这两个示例是想揭示，低代码、无代码开发模式与代码开发模式，就好像：
- 微软的 Office Word 软件和 Markdown 的比较一样
- 微软早期的 VSS (Visual Source Safe) 和 Git 的比较一样
尽量前者上手容易，界面友好，但它们远离了事物的本质，对于新手小白做一些临时的事务很有帮助，但长远来看，如果要做一些专业的产品或服务，还是要选择开放的、灵活的、无依赖的、功能专一而强大的解决方案才是上策。
低代码平台开发的软件最终将随着时间的推移，越来越难以适应业务的变化，越来越难以实现新的需求，旧的功能也难以维护和优化，软件应用逐渐走向凋亡，之后不得已还得再找专业人员来解决问题、修改维护或者重写一套新的软件系统。
回到敏捷软件宣言第一句：
个体和互动 高于 流程和工具
和第三句：
客户合作 高于 合同谈判
我在想：是不是因为客户、业务人员和开发人员不能很顺畅和深入地沟通，从而导致了低代码开发平台的盛行？
这里可能会引出一些更深层次的问题：
- 组织架构中有哪些设计特点从根本上阻碍了敏捷软件开发的落地？
- 怎么就逼得业务人员想要亲自上手用低代码平台做开发了？
- 怎么就逼得IT领导选择低代码平台而放弃了原来成熟的代码开发了？
- 怎么就让新手小白、业务部门和IT领导都觉得低代码开发更方便快捷，而代码开发缓慢、复杂和艰难呢？
也许这些问题可以在极限编程合作社共同翻译的《敏捷组织设计》中找到启发吧？:) 敬请期待……