提供具体的服务,有具体的业务是很容易的。基本上每个大众用的软件,都是 No code / Low code 就可以使用的。之所以这么多厂商提出自己要做 No code / Low code,都不是冲着解决一个特定领域的问题去的。比如说不用写代码也可以在网上卖东西。这个用淘宝就好了,不需要 No code / Low code。
为什么说远比想象得要难。因为这里面其实蕴含了4层问题。我们由表及里来看。
第一层,是要解决普通人也能编程的问题,这一层需要用一些普通人熟悉的概念和表达方式来代替代码。本质上是要解决一个教学的问题,利用熟悉的概念学习新的概念。让编程的效率更高,和让普通人也可以学会编程是两个完全不同的问题。其实这个教学问题没有多少捷径。所以大部分 No code / Low code,实际上是把问题转换为下一层的问题,就是让你复用,就不用写代码了。
第二层,因为这种普通人也可以“编程”的方式效率其实是不高的,所以尽可能少的让普通人来完成必要的工作。而是把工作前置到平台方提前帮用户做好。然后普通人只需要“复用”就好了。但是通用不限领域的软件复用,这个自身就是一个非常难的问题。往往可复用的代码都会更复杂,复用的同时还要好懂,易于维护就是更难的问题。软件复用其实历史悠久,然而进展非常缓慢。今天的代码生成器和五十年前的代码生成器,没啥本质的提高。所以快速生成Java 的 CRUD 是不会有什么实质性提高的。如果这种做法有用的话,早就普及推广了。还是要看有没有比 Java 这样主流的方式更好的写法。所以就引出了下一层的问题。
第三层,要解决的问题是减少软件开发与维护的总工作量。第二层是关于软件代码的 reuse。第三层就是假设不存在 reuse 的问题,就是实打实的解决一个明确而具体的问题,如何做得更少的问题。软件开发和维护的工作量是一个总数,我们也不论这个总工作量怎么在平台方和复用方分工的问题。这些活不论你干还是别人,总得有人干。一个总的方向就是降低编程这项活动的认知负担,减少需求和源代码之间的Gap。所谓 complexity 大家都认同,但是有几个人可以具体 complex 在哪几处说明白的。为什么这些事情会对我们的大脑来说是难呢。这个问题分解的过程才最为致命。
第四层,当我们写的代码越像需求,而实际的CPU执行方式是恒定不变的。那么代码和实际的执行过程的Gap就会越来越大。目前的主流实践是用 console.log 这种非常低带宽的方式获得反馈。如何提高开发者获得反馈的带宽以及频率是很难的一个综合性问题。
整体而言,一个根本性的困难是这些问题都不是可定量的科学。因为其作用的对象是人类自身。这些问题更多的是人文性和社会性的问题,而不是数学问题。同时强烈的主观性,导致了进展非常难以评估。而且也会导致即便有进展,其实际的功效也非常难以定价,从而具有明确的商业价值。
从商业模式的角度来说,最有吸引力,最好讲创业故事的领域是第一层的问题。最不性感,最难以销售的是第四层的问题。然而最表面的问题,“普通人无法像自己就能写信一样,要求助写信专家(开发者)代写”不是在于普通人与写信专家之间的差异。而是写信这个事情,对于专家来说也是困难的。
这个行业最缺少的是对问题的深入分析,例如到处充斥着是 OOP 更好还是 FP 更好的无意义的争论。在我看来 OOP 和 FP 都一些对不明问题的解决方案而已。单纯讨论解决方案是没有意义的,关键是问题是什么。
所有 No code / Low code 从业者需要做的是把前面列举的四层问题进一步展开,每一项都能分解出更具体的问题。当我们把问题都理清楚的那一天,对应的解决方案就会显而易见。
文章来源于知乎创作者陶文
原文链接:https://zhuanlan.zhihu.com/p/82579865
若有侵权请告知,我们将及时删除,本文仅供学习交流、我们注重分享,勿作商用,版权归原作者。
未经允许不得转载:RPA中国 | RPA全球生态 | 数字化劳动力 | RPA新闻 | 推动中国RPA生态发展 | 流 > No code / Low code 看起来容易,其实远比想象得更难
热门信息
阅读 (13588)
1 聚合产业资源 向未来生长,第三届ISIG中国产业智能大会成功召开阅读 (12303)
2 《Market Insight:中国RPA市场发展洞察(2022)》报告正式发布 | RPA中国阅读 (10759)
3 Gartner发布《2022年12大技术趋势》:超自动化连续3年入选阅读 (10461)
4 《2022年中国流程挖掘行业研究报告》正式发布 | RPA中国阅读 (10310)
5 《构建敏捷数字实践力-2022年中国低代码/零代码行业研究报告》| LowCode低码时代