写点什么

少写代码,用更便捷的方式开发程序

  • 2023-12-05
    四川
  • 本文字数:1413 字

    阅读完需:约 5 分钟

关于低代码的误解很多,很多人对低代码刚出现就各种穷追猛打,实际上并没有深刻理解低代码的目标人群和使用效果。


尽管我对低代码的使用期望更接近一开始的定义,也就是用低代码的方式更快更好地开发应用。就是通过少写代码,用更方便的方式开发程序。(前提是不损失任何功能或者尽可能少地损失)


现在的低代码,算是喜欢的喜欢、讨厌的讨厌,喜欢的自然觉得给自己省下了时间,提升了效率;讨厌的可能是之前被什么产品坑过,或是天生就讨厌这种低代码,总觉得是某些商家专门拿来牟利的利器,或是影响自己的职业发展。


我个人对低代码的态度没有喜欢和讨厌之分,单纯将它做为一个工具来使用,低代码好用,也有适用的范围,超过这个范围用别的方法就好,所以不像网上两拨人争论的那么厉害。


比如说我要开发一个网页,做一个工具表单,做一个快速的程序验证想法,用低代码的方式做就是更快。如果要刷算法,嵌入式系统和硬件级编程,那低代码就是做不了,乖乖用回 C++,就这么简单。


其实一个专业低代码比大多数人想的技术构造要复杂,要做出来也并不容易。


首先要保证产品本身的架构的灵活性,现在无论是前端还是后台,还是云计算,技术迭代的速度都非常快,需要设计一个通用的架构,保证有新技术出现的时候可以快速迭代进来,这点非常重要。


国外的低代码龙头 Outsystems 更新 20 多年,一直在适配近年来的各种前后端技术,就是因为一开始选用的技术框架太过古老,这艘大船想要调头就难得多,但是没办法,只能修修补补接着做。


其次,图形化编程语言本身的设计和现有编程语言的转化,也是一个难点。图形化编程语言的 AST(抽象语法树)如何设计?语义空间(关键字)有多大?如何才能生成流行且大家熟悉使用的编程语言和代码框架?


后台数据库以及后台资源如何接入并保证高可用?外部系统例如 3D、2D、物理引擎如何接入?如何高效渲染?这些都是很棘手的问题,而且很多问题并没有标准答案,都需要独立创新和研发。


就拿 AST(抽象语法树)设计举例,前端的 AST 和后台显然是不一样的,例如后台需要转码 Java,而前端需要转码 vue/react/dart 等,那 Java 是直接采用 Java 原有的 AST 还是重新设计一种?


国内 iVX 的团队就是重新设计了一种 AST,用来生成 Java AST,再转码 Java Code。这是种很聪明的做法,效果很好,体验也很流畅,稳定,但这也是 16 年不间断迭代研究出的结果,可见这个领域跟大部分人想的“速成”还是有些差距。


现在关于低代码是给谁用的,有两种主流的观点。一种认为低代码是给工程师用,目标就是让这些开发软件的熟手把软件快速做出来;一种认为,低代码是给业务人员适用,目标就是降低门槛,不占用稀有的开发资源。


现在低代码存在的两种主流形式:模型驱动和表单驱动就是这两种观点的最好体现,模型驱动为了开发人员适用,表单驱动就是给业务人员。这两种观点也没有错,但我认为还遗漏了一种方式,那就是开发人员跟业务员混合开发的方式,这点我会在以后专出一篇文章详细谈。


低代码说到底还是个工具,有没有用取决于使用它的人,软件开发的历史已经有七八十年了,但编程的方式一直没有发生太大的改变,这对于一个技术快速迭代的领域来说本来就显得奇怪。特别是撰写重复的代码上,我个人觉得是没有必要的,完全可以优化。


我希望大家保持一种更开放的心态,对于新技术,先不要急着下定论,最起码在自己了解一个新事物前,收回自己的固有看法才是重要的,再多的评测和言论都不如自己亲自体验下,有用的东西为我所用,没用的东西置之不理,这样就足够了。


用户头像

一个程序员跟他的猫 2023-10-30 加入

做过 2 年建筑业,现在 3 年程序员

评论

发布
暂无评论
少写代码,用更便捷的方式开发程序_代码生成器研究_InfoQ写作社区