程序员为什么不喜欢低代码
source link: https://zhuanlan.zhihu.com/p/377234404
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
程序员为什么不喜欢低代码
因为答应要去做这个演讲 程序员为什么不喜欢低代码
被迫总结输出一下提纲。总体上是两个大方向：
- 好的工程实践是有原因的，不会因为“低代码”了，之前的工程实践都不再适用
- 低代码不是纯技术能实现的目标，需要产品和技术一起努力
工程实践角度
- 自动化测试
- 出错提示，代码行号定位
- common reuse principle 等依赖管理原则
我们把低代码换个说法叫“最终用户编程”。然后把最终用户看成一个开发团队。那低代码也是一种软件开发的形式，只是把最终用户这个软件开发团队引入到了软件开发过程之中了。传统的最佳工程实践都是有价值的，有必要在低代码这个语境下一一考量一下其意义。
这里投入不足，很大程度是因为做这些东西成本巨大。这里又牵涉到了，什么情况下值得弄个低代码出来，多少收益才能抵消成本。
产品和技术协作角度
低代码建立在“预制件”的基础上的，但是低代码没有说明这些“预制件”是从哪里来的。两种可能：
- 先有具象的需求，然后逐步归纳出预制件
- 先有预制件，然后把需求往里面套
当使用低代码是纯技术行为的时候，技术侧就会非常难受。因为低代码希望的是需求内在有规范有规律，可以被压缩成预制件。但是需求是啥样，那是产品经理说了算的。
无论是归纳出预制件，还是先有预制件再用预制件表达需求，可能都走得通。但是都不能是靠技术侧去推动产品侧，而是一起协作来搞，得有组织和流程的保障。
用 c 语言很难精确寄存器，用 java 很难控制内存，用 vue 很难高频率刷新 DOM 实现动画，一项技术总是有其代价。低代码也一样，总是会丧失一些适用范围和场合。技术选型的事情应该由解决问题的人，根据问题本身的需求选择技术方案，而不是被指手画脚。使用还是不使用低代码做为技术方案，应该像其他技术选型一样让解决问题的人根据需求来决定。先有需求，再有解决方案。
有时候不是把所有相似的代码都归纳成一个函数，就一定就能提效的。比如搞一个 DSL 解决界面组件联动问题。这样的 DSL 弄出来也就是一个 javascript 的变种。预制件不是你说那里可以弄一个出来，就一定可以弄一个出来的。压缩是建立在有规律，有冗余的基础上的。如果原来的表述方式已经足够精简了，就没有多少压缩空间。
如何做出让程序员喜欢的低代码
- 别让程序员用。低代码的用户应该是 end-user，程序员提效有无数种办法，别啥都叫低代码
- 工程实践该加的都得有
- 管控预期，不是什么需求都可以实现的
- 让程序员提供低代码支持最终用户编程，需要组织和流程保障（对内的低代码），或者需要商业模式支持（对外的低代码）
大概提纲就是这样了，然后就是补充各种例子了
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK