“低代码”是真工程师的得力助手

我是做工业上位机程序开发的从业人员。以下谈到的编程，都是对该行业的。

程序设计的一般步骤是什么？

1，对接需求，确认需求，拆分需求。

2，根据需求，设计人机交互的方式。

3，根据人机交互的方式，设计数据交互的方式。

4，根据数据交换的方式，设计你的程序框架。

5，基于程序的框架，填充你的程序功能。

“低代码”，在哪个步骤可以帮你？毫无疑问，是最后一步，也仅有最后一步。

“低代码”可以提高开发效率。所以是得力助手。

为什么“低代码”干不了1,2,3,4。

因为1,2,3,4是环环相扣。而第一点，“低代码”就被难住了。一个程序的需求，就连客户自己，都不是一次就能描述清楚的。要反复沟通确认。更不用说，需求本身，也会发生变化。

根据目前的人工智能“低代码”，要突破，还有很长的路要走。而且我并不看好他能突破。

为什么“低代码”可以干5呢？

因为一些功能程序，需求很清晰，而且网络上有对应的资料。甚至在别人的帖子里面，都直接有。“低代码”它能找到，或者它训练的时候，就曾经喂过这些程序给它。所以它能干。

如果你是个真工程师，你又擅长使用“低代码”，那么你的效率就*2，*3，*5。

如果你是个真工程师，你不用“低代码”，那么你效率不变，但相对效率降低了。

如果你是个伪工程师，只会干部分低质量的5，那你工作的价值逐渐趋于0了。

“低代码”并不是新东西。

在最早，穿孔纸时代。相对而言后面的机器语言，就是“低代码”。

后来，对机器语言来说，汇编语言，就是“低代码”。

后来，对汇编语言来说，面向过程的高级语言，就是“低代码”。

再后来，对面向过程的高级语言来说，面向对象的高级语言，就是“低代码”。

现在，对面向对象的高级语言来说，自然高级语言，就是“低代码”。

经过半个多世纪的发展，编程这个行业非但没被取代，反而是越来越繁荣。

所以“低代码”并不是危，而是机。