说透低代码
陈旭
中兴通讯软件研发资深专家
18786 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已更新 26 讲/共 39 讲
说透低代码
15
15
1.0x
00:00/00:00
登录|注册

02|低代码到底是银弹,还是行业毒瘤?

你好,我是陈旭。
说到低代码,有人说它是毒瘤,也有人说它是银弹。那到底应该怎么看呢?这就是我们今天要解决的核心问题。
先上结论:存在即合理
这里的“存在”包括两个角度:一是银弹论,二是毒瘤论,无论从哪个角度看,既然存在这样的论调,就有它们的合理性。
我们暂时不介入这两个言论的细节,而是先把关注点移到低代码本身,先回答这个问题:低代码到底是要革程序员的命?还是成为程序员工具箱里的另一个工具?
如果你觉得低代码的目的是为了革程序员的命,是要把程序员的手脚给捆住,是要束缚程序员的创造性,是要把复杂的现实世界强制机械化、特例化、流程化,那么大概率你会接受毒瘤论。你甚至会毫无保留地否定低代码,认为 Low Code 除了 Low 以外,不会有 Code。
毕竟,变革是有成本的,而且往往成本巨大,无论是一个人还是一个团队,保持惯性,留恋舒适区才是正常的。我们几十年来用的软件从来都是双手敲代码创造出来,抛弃这个已被无数次证实可行的方法,拥抱一个“饱受争议”的新方法,这本身就需要有莫大的勇气,也需要承受风险。
虽然会有很多勇于探索、期望尝试新方法的人和团队,也有很多受困于 Pro Code(手敲代码的方式)的各种痛点被迫自我变革的人和团队,但是更多的人和团队是倾向于保持现状的,即使嘴上不说,身体却很诚实。每次回顾会都能复盘出一堆的代码问题,然后一而再、再而三地立 flag 说要改进,但多数会给出各种借口说明问题无解,然后继续这样的循环。有惯性就有排斥,有排斥就有各种负面论调,毒瘤论是其中典型的代表。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

低代码技术在业界备受争议,有人认为它可能剥夺程序员的创造性,甚至是程序员的终结。然而,将低代码视为程序员工具箱中的另一个工具,可以改变这种看法。传统的Pro Code方式存在诸多问题,如高门槛、跨界难、代码编写后的繁琐工作等。引入低代码工具可以缓解甚至解决这些问题,从而实现相似价值的业务,减少副作用,成为更好的方式。低代码技术并非要取代传统的编码方式,而是作为其补充,提高开发效率,赋能更多人参与业务开发。低代码技术的核心在于使用结构化数据描述业务,自动生成大部分代码,从而提高开发效率,降低技术门槛。尽管低代码技术在业务描述能力上不及Pro Code,但其高效率和赋能性使其成为一种合理的开发方式。 文章探讨了低代码技术的优势和不足,以及其在业务研发全生命周期中的应用。作者指出,低代码技术的关键优势在于大幅降低开发门槛,压缩开发周期,赋能无编码技能者,同时提高开发效率。然而,文章也提到了低代码平台需要具备一系列其他能力,如一键导出和部署、较高的可测试性、多人协作、兜底能力等,以覆盖业务研发全生命周期。此外,低代码平台还带来了许多增值功能,如自动对齐UX设计规范、UX设计稿转代码(D2C)能力、App的埋点&数据采集、开源合规治理、安全漏洞治理等,这些功能是拉开与Pro Code差距的重要抓手。 总的来说,低代码平台不仅需要把开发能力发挥到极致,还需要注重其他能力的建设,如一键部署、可测试性、多人协作、兜底能力等。这些能力对于提高业务团队的研发效率和质量至关重要。因此,低代码技术的发展还有很大的空间和潜力,需要不断完善和拓展。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《说透低代码》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(13)

  • 最新
  • 精选
  • 抱紧我的小鲤鱼
    在国内,架构是为业务服务的,没有业务的需求也就不需要架构的支撑,也谈不上到底是Pro code还是low code了

    作者回复: 确实,你的留言让我想起多年前听到的一句话,脱离业务谈架构的都是耍流氓。同样的,脱离业务谈低代码的也是耍流氓

    2022-03-18
    8
  • Light 胖虎
    我认为还需要注重业务能力吧,在开发过程中会存在很多业务相关的重复代码,因此低代码也需要解决一些业务功能

    作者回复: 的你说得没错,任何低代码解决方案最终的目标都是要解决业务问题,从来没有哪个低代码解决方案是只专注于解决技术问题的,技术是没有价值的业务才有价值。但是凡事都有一个发展的过程,一般都先解决技术问题,然后再聚焦到业务问题。

    2022-03-16
    2
  • Tree New Bee
    结合业务能力抽象业务组件,集成外部能力的封装成平台业务组件。比如集成ocr识别可以使用到费控报销场景 发票拍照识别

    作者回复: 是的,低代码平台具有非常强的综合性属性,一定要做成开放式架构,这样才能接入更多业务定制功能,如你说的OCR扫描

    2022-03-16
  • 出发水母田
    由指令式到声明式似乎是程序界不约而同的选择,比如前端MVVM框架、K8S声明式编排,再如Pro code到Low code。本质上是心智负担的转移,将人的心智负担转移到框架、平台。实现声明式的编程体验确实相对更难。 另外我觉得低代码的目的确实是“为了革程序员的命”,但不是“要把程序员的手脚给捆住,是要束缚程序员的创造性”这种革命。而是随着低代码平台的完善与流行,类似AI绘画,人们发现不需要那么多程序员了,会使越来越多的程序员失业的这种革命。
    2023-04-28归属地:广东
    1
  • Brave
    页面版本记录能力、缓存能力、权限、预览、一键部署与回滚、数据监控与日志、可拓展能力、向下兼容能力、调试能力
    2023-11-17归属地:四川
  • OoO
    看最后总结的内容,觉得低代码平台对于一般公司从零搭建难度比较大吧。 我们是不是应该先做个架子,分好适合自己的业务模块,然后逐步迭代完善
    2023-05-22归属地:山西
  • Geek_7e0d86
    老师,低代码开发,是不是对布局有一定局限性?
    2023-05-16归属地:北京
  • ifelse
    低代码:更高级的代码复用。
    2023-02-15归属地:浙江
  • softbaddog
    不管什么模式的开发平台,一定都要围绕着业务进行。目前的低代码平台感觉更像是一堆标准化的乐高积木,如果积木种类越丰富,能够拼出的东西离客户所期望得越接近,但是真正能达到老师所说的那样低代码平台真是寥寥无几,用过一次后基本上都是 ”敬而远之“。 此外,还有一个Gap就是,客户已经习惯Pro code开发出的高度定制化产品,低代码平台生成的App几乎无法达到客户想要得最终效果。给大家分享一个案例,我们团队UX设计人员,一听说要用低代码平台开发,直接就放弃不参与了,老师你们那边有碰到这样的情况吗?
    2022-11-19归属地:湖北
  • 李凯旋
    老师国内外对低代码的评价、发展有什么不一样的吗
    2022-05-05
收起评论
显示
设置
留言
13
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部