02|低代码到底是银弹,还是行业毒瘤?
- 深入了解
- 翻译
- 解释
- 总结
低代码技术在业界备受争议,有人认为它可能剥夺程序员的创造性,甚至是程序员的终结。然而,将低代码视为程序员工具箱中的另一个工具,可以改变这种看法。传统的Pro Code方式存在诸多问题,如高门槛、跨界难、代码编写后的繁琐工作等。引入低代码工具可以缓解甚至解决这些问题,从而实现相似价值的业务,减少副作用,成为更好的方式。低代码技术并非要取代传统的编码方式,而是作为其补充,提高开发效率,赋能更多人参与业务开发。低代码技术的核心在于使用结构化数据描述业务,自动生成大部分代码,从而提高开发效率,降低技术门槛。尽管低代码技术在业务描述能力上不及Pro Code,但其高效率和赋能性使其成为一种合理的开发方式。 文章探讨了低代码技术的优势和不足,以及其在业务研发全生命周期中的应用。作者指出,低代码技术的关键优势在于大幅降低开发门槛,压缩开发周期,赋能无编码技能者,同时提高开发效率。然而,文章也提到了低代码平台需要具备一系列其他能力,如一键导出和部署、较高的可测试性、多人协作、兜底能力等,以覆盖业务研发全生命周期。此外,低代码平台还带来了许多增值功能,如自动对齐UX设计规范、UX设计稿转代码(D2C)能力、App的埋点&数据采集、开源合规治理、安全漏洞治理等,这些功能是拉开与Pro Code差距的重要抓手。 总的来说,低代码平台不仅需要把开发能力发挥到极致,还需要注重其他能力的建设,如一键部署、可测试性、多人协作、兜底能力等。这些能力对于提高业务团队的研发效率和质量至关重要。因此,低代码技术的发展还有很大的空间和潜力,需要不断完善和拓展。
《说透低代码》,新⼈⾸单¥59
全部留言(13)
- 最新
- 精选
- 抱紧我的小鲤鱼在国内,架构是为业务服务的,没有业务的需求也就不需要架构的支撑,也谈不上到底是Pro code还是low code了
作者回复: 确实,你的留言让我想起多年前听到的一句话,脱离业务谈架构的都是耍流氓。同样的,脱离业务谈低代码的也是耍流氓
2022-03-188 - Light 胖虎我认为还需要注重业务能力吧,在开发过程中会存在很多业务相关的重复代码,因此低代码也需要解决一些业务功能
作者回复: 的你说得没错,任何低代码解决方案最终的目标都是要解决业务问题,从来没有哪个低代码解决方案是只专注于解决技术问题的,技术是没有价值的业务才有价值。但是凡事都有一个发展的过程,一般都先解决技术问题,然后再聚焦到业务问题。
2022-03-162 - 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