No code / Low code 看起来容易,其实远比想象得更难

后台-系统设置-扩展变量-手机广告位-内容正文顶部

提供具体的服务,有具体的业务是很容易的。基本上每个大众用的软件,都是 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 看起来容易,其实远比想象得更难

后台-系统设置-扩展变量-手机广告位-内容正文底部