[]
type=info
本页面中以下内容均针对“模型驱动的低代码平台”,可能不适用于部分“表单驱动的低代码平台”。
软件开发的本质,是将现实中的问题搬到计算机里,借助计算机的能力来解决。承担这项工作的开发者,需要对“现实中的问题”(业务)和“计算机的能力”(技术)有充分的了解。相比于业务知识学习,技术能力的培养投入更大,所以,虽然业务开发者也能参与到低代码开发中,但有较强技术能力的IT技术人员长期以来都是软件开发的主力军。进入低代码时代后,IT技术人员依然是软件开发的主力,也是低代码平台的主要用户群体。低代码技术在现有软件工程方法论的基础上,使用可视化和代码自动生成技术,减少了大量重复性工作,让IT技术人员将精力集中在更具创造性的领域,通过更快的交付速度,更智能化的软件应用,显著提升最终用户的满意度。
这里的IT技术人员是与“业务开发者”相对的概念,包含但不限于程序员,特指在企业或信息化提供商中,本职工作为企业信息化相关的技术人员。IT技术人员主要集中在企业信息化部门和为企业提供信息化服务(如外包开发、系统集成等)的软件公司中,典型岗位有项目经理、架构师、程序员、测试人员、实施和运维人员、DevOps等。
整体而言,IT技术人员具备以下特征:
具备技能:通常具有计算机相关的教育背景,或通过自学的方式掌握了一定的IT技能(如编程语言、数据库管理、配置管理、系统管理等)
考核指标:能否保质保量地满足本单位或客户的信息化需求是核心指标
学习意愿:需要紧跟技术发展趋势,跟随团队和企业技术决策,及时更新技术能力
在进入低代码时代之前,各岗位的IT技术人员均已掌握了软件开发全生命周期所需的部分技术,通过简单的学习,这些IT技术人员均可转型为低代码开发者,以团队成员或个人开发者的身份构建软件应用。
当前岗位 | 与低代码开发者的 匹配程度 | 需求 理解 ● | 架构 设计 | 数据库 设计 ○ | 界面交 互设计 △ | 数据库 开发 △ | 前后端 开发 | 项目 管理 △ | 系统 管理 | 说明 |
---|---|---|---|---|---|---|---|---|---|---|
架构师 | ※※※※※ | √ | √ | √ | √ | √ | 架构师不但适合转型为低代码开发者,更适合成为低代码技术专家,为多个团队提供技术支持 | |||
项目经理 (乙方) | ※※※※※ | √ | √ | √ | 乙方项目经理通常具有计算机的教育背景,学习数据库设计和开发相对较容易,可以做到“开发管理一肩挑” | |||||
项目经理 (甲方) | ※※※※ | √ | √ | 甲方项目经理通常缺乏项目管理经验,需要补全短板才能确保低代码开发有序展开 | ||||||
程序员 | ※※※※ | (部分) | (部分) | √ | √ | 对于程序员来说,低代码不过是一个新的开发语言和工具,要想发挥低代码的最大价值,需要提升需求分析能力 | ||||
实施和运 维人员 | ※※※ | √ | √ | 适合运维人员的转型需要学习需求分析、数据库设计知识,可行,但难度相对较高 | ||||||
DevOps | ※※ | √ | ||||||||
测试人员 | ※ | (部分) |
●:低代码开发者的必备技能;○:低代码开发者的重要技能;△:部分场景下低代码开发者的需要技能
对于软件开发这种成熟的生产模式来说,任何一项新技术的引入都需要投入学习和切换的成本,在计算该技术能带来的价值时,则需要将这个成本减掉。从编码开发到低代码开发,IT技术团队,特别是开发团队投入成本不仅限于学习该技术花费的时间,还需考虑配套的工具和方法论的学习和切换成本:
学习低代码开发工具的时间投入
学习低代码平台配套工具(如版本管理、CI/CD等)的时间投入
适应项目管理方法的时间投入和风险
而引入低代码后,开发团队能获取的收益也不仅限于开发工作量的降低,还有与之相伴的测试工作量降低和交付周期缩短,而交付周期缩短可以有效降低返工成本。
综合上述低代码的价值公式可以概括如下:
开发和测试的工作量减少 + 因交付更敏捷带来的返工量减少 - 低代码学习成本 - 配套工具学习成本 - 方法论切换成本 = 低代码的价值
考虑到不同的低代码平台适用于不同的应用场景,上述5个参数可能存在较大差异。从实践上看,采用模型驱动的低代码开发平台开发项目规模大、复杂度高、技术要求严格的企业核心应用时,低代码带来的收益显著高于使用表单驱动的低代码开发平台构建临时性的简单应用。而后者更适合由业务人员而不是IT技术人员完成,以“解决有无问题”为目标。
参数 | 模型驱动低代码(核心业务应用) | 表单驱动低代码(简单应用) |
---|---|---|
开发和测试的工作量减少 | 高 | 高 |
+ 因交付更敏捷带来的返工量减少 | 高 | 低 - 返工工作量较低 |
- 低代码学习成本 | 低 - 与编码开发的概念和模式更接近 | 中 - 需要打破现有软件开发思维 |
- 配套工具学习成本 | 低 - 可沿用现有工具 | 高 - 需重新考虑版本管理和DevOps流程 |
- 方法论切换成本 | 低 - 与软件工程理论兼容 | 高 - 需重新设计团队协作和管理方式 |
= 低代码的价值 | 高 | 低 |
详细了解:低代码平台的技术原理;低代码开发支撑软件全生命周期
对于程序员来说,学习模型驱动的低代码开发平台和学习一项新的语言类似,都是将之前学习和实践中积累下来的经验,套用到新的开发工具上。在适应了低代码开发平台后,IT技术人员就能通过可视化的方式,大幅减少重复性的工作,比如增删改查、页面布局和样式等,最终实现工作量的显著下降。从相对低端的重复性工作中腾出精力,才能扩宽职业发展的道路。在一个采用低代码技术开发的团队中,IT技术人员的发展路径主要有以下4条。
低代码时代的技术专家与编码开发的架构师类似。如果对传统编码开发更感兴趣,低代码开发者可以持续钻研编程扩展,包括低代码平台的插件开发、外挂式Web API开发、软硬件集成、数据库调优等,为公司提供技术支撑。成为技术专家,意味着开发工作从面向应用需求,切换为专注于处理技术和集成方面的难题,为多个团队和项目提供技术保障。相比于没有接触过低代码开发平台的其他程序员,技术专家通常可以根据低代码平台的特点给出最有效的解决方案,并且能够充分理解和照顾来自公司其他开发者的功能和体验要求,降低沟通成本,为整个公司的软件开发工作提效。
大多数采用低代码开发模式的软件公司和企业信息化部门对技术专家岗位的需求量较少。所以,这个路线对开发者自身的技术突破能力和持续学习能力有较强的要求。通常情况下,公司会优先从编码开发团队的架构师中选择学习能力强、对新技术敏感度高的人员担任技术专家。
低代码开发和编码开发在项目管理和软件生命周期上的方法论是一样的。所以,低代码开发团队一样需要设置项目经理的角色。考虑到低代码时代有“设计即开发”的特点,项目经理也需要具备使用低代码平台构建可操作原型,甚至参与到具体开发工作的能力,这就为低代码开发者转型成为项目经理提供了更有竞争力的条件。
相比于编码开发,数倍的生产力优势让低代码开发的团队规模更小,2-3人的微型团队就能具备编码开发时代10人团队才有的软件交付能力。更小的团队规模,让公司能同时启动更多的软件开发项目,这就需要更多的项目经理来保证需求沟通和开发管理的有效可控。所以,除了编码开发团队的项目经理之外,更多的开发者可以借助这一契机,通过承担更多项目管理工作,成为新的项目经理。需要提示的是,项目经理所需的管理知识已经形成了成熟的体系,“自学成才”是完全可行的。
低代码具备更快的迭代速度和更低的学习门槛,这使得很多公司开始让业务人员深入参与到软件开发中来。业务人员和IT技术人员一起,前者贡献业务知识,而后者基于对计算机技术的理解,将其转换为软件。在不断的交流中,有一部分业务人员因此掌握了软件开发能力,也让一些技术人员对业务流程和背后的原理有了更深刻的理解。所以,在帮助业务人员转型为开发者的同时,技术人员也能成为业务专家,将软件开发工作中培养的系统化、逻辑化思维带到业务部门,为业务发展引入新动力。
低代码开发的团队规模更小,一人身兼数职也是常态,可以帮助开发者更快速地成长。在低代码的助力下,一个人同时掌握需求分析、产品设计、开发、测试以及DevOps相关的技术能力的可能性大增。如果具备覆盖软件全生命周期的能力,再加上合适的时机,“成为独立开发者”也是一个值得考虑的选项。相比于编码开发,低代码的开发效率足够帮助独立开发者建立起交付速度和成本上的优势。
Q: 使用低代码开发出的系统,性能会不会很差?
A: 就像.NET EntityFramework在某些特定场景下,生成的SQL语句性能不高一样,低代码平台也无法保证每一个数据查询的性能都得到极致优化。所以,低代码平台会提供更完善的日志分析能力,帮你判断性能瓶颈是否出现在数据库访问。如果是,可以选择手写SQL来有针对性的解决性能瓶颈,这就是为什么企业级低代码平台会提供直接执行SQL的能力。在企业级应用开发领域,这种情况的发生概率并不高。
Q: 低代码开发出的系统,耦合性是否过强,导致后续维护困难?
A: 模型驱动的低代码开发平台采用了“数据结构与业务逻辑分离”、“前后端分离”的模式,在耦合性与可维护性方面,与ASP.NET MVC(含EntityFramework),Spring Boot(含hibernate)的范式基本一致,在开发效率、运行性能和可维护性上找到一个平衡点,支撑企业级应用开发。事实上,低代码开发平台将范式中的大量配置和编码工作进一步可视化,加强了框架对开发行为的约束。在项目实践中,低代码平台可以帮助技术管理者更严格管控突破框架的开发工作(手写代码的总量更少,更易检查),降低耦合性,提升可维护性。
Q: 低代码开发出的系统,是否易于测试?
A: 首先,更少的人工编码意味着更少的Bug以及更低的测试工作量。除此之外,使用低代码开发和使用Eclipse等IDE(含JUnit插件)的编码开发在编译检查、自测、测试上的体验基本相同。在 低代码开发支撑软件全生命周期 中,你可以详细了解如何为低代码开发构建测试环境,实现CI/CD的。
Q: 低代码开发是否意味着原来基于Git的敏捷项目管理机制无法继续使用呢?
A: 不会的。低代码开发同样可以兼容Git的权限控制、版本管理和分支管理。就像Visual Studio内置了git操作一样,你也可以用低代码平台内置的功能,在开发工具上直接完成签入、签出、版本管理等工作。所以,原有的敏捷开发方法论可以无缝应用于低代码开发。
Q: 能否将一个低代码平台上开发的应用,迁移到其他的低代码开发平台上?
A: 就像.NET程序不能运行在JDK上,成熟的低代码工具通常会提供强大的运行平台,提供更高的处理性能、更全面的功能支撑,无法也不应脱离使用。
Q:厂商停止服务后,应用怎么维护?
A: 就像很多企业都有一些运行着老旧软件的服务器一样,选择私有化部署和买断式授权可确保开发平台和基于该平台开发的软件能长期使用;如有必要,也能基于新的开发技术,逐模块替换这些老旧系统,新老系统并行。