译者 | 牛昊天
Thoughtworks 第 28 期技术雷达中提出，市场中低代码平台能力在近些年取得巨大进步，但依然主要集中在解决中低复杂度场景问题，当面对复杂的业务场景时，仍然存在一定的平台限制。所以建议企业考虑采用低代码技术前，仔细深入评估自己的需求和低代码技术之间的平衡——有界限地使用低代码平台。
主要要点
- 低代码采用率正在增长，但它只适用于某些特定场景，并非所有场景。
- 低代码被认为是传统开发流程和实践的替代方案。但决策者需要了解其限制，并围绕应用程序开发建立适当的防护措施。
- 在决定是否选择低代码之前，先提出正确的问题，以确定它是否适合特定的应用程序需求。
低代码工具和平台，可以使不同团队创建有价值的软件系统，而无需编写和维护大量的自定义代码库，这为低代码工具赢得了几乎相等数量的支持者和批评者。
然而，一些预测显示，到2025年，使用低代码工具和平台创建的新应用程序比例可能高达70％。而持续存在的开发人员短缺，正在推动企业探索加快软件交付和减轻工作负担的新方法，因此越来越多的组织开始探索低代码能为他们做什么。
低代码工具和平台的能力在近些年取得了显著的发展，但质疑仍然存在——这是有一定道理的。尽管低代码工具有潜力增强新一代所谓的“公民开发人员”的能力，并通过低代码实现简单功能的搭建，进而减轻开发团队的压力，但事实是它们仍然并不适用于每种开发场景。
确定低代码是否适合你，并最终获得它可能为你的业务带来的价值的第一步，是了解它最适合什么样的场景。
何时（以及何时不）使用低代码
有很多因素会促使组织采用低代码方式开发。以下是最常见的四种情况，以及低代码在每种情况下的适用性：
场景＃1：应对开发人员短缺
由于全球范围内对开发人才的需求仍然远超过供给，所以能够让用户构建强大软件的工具前景非常引人注目。但如果只是因为组织中缺乏成熟的开发和编码技能，而选择采用低代码技术，可能会带来不必要的麻烦。
如果没有熟练的开发人员和IT专家来监督业务团队使用低代码创建的内容，你将得到“没有策略支持的软件”：业务部门也许会不断地定制不同的应用，来解决数字化需求，但它们之间几乎无法关联或聚合。这将是一种无法扩展的场景，并且与平台化思维等领先实践完全不一致。IT 领导层需要制定相应策略，并采取适当的措施，允许在适当的情况下开发低代码应用或解决方案，使业务用户能够在不产生大型复杂问题（技术债务、无法扩展的系统等）的情况下解决重要问题。
场景＃2：支持业务快速增长
对于早期阶段的扩张，低代码可以帮助快速创建新功能和服务，而无需大幅投入开发资源，这反过来也能保证他们的软件不会成为组织快速发展的瓶颈。
然而，这些组织需要认识到，他们使用低代码平台创建的某些解决方案最终可能必须被替换掉。否则，他们可能会发现其基础设施的核心部分是建立在欠灵活的基础上的。而这对于许多使用低代码构建的应用程序来说的确是一个挑战。
为了从低代码中获得最大价值，成长中的企业应该使用它来快速创建他们需要的功能，但要做好规划和准备，在未来某个阶段它们不再被需要时，用更强大的功能取而代之。
场景＃3：构建新的核心业务软件
软件对你的业务越重要，低代码就越不可能成为构建和维护它的首要选择。这并不是因为低代码缺乏构建关键应用程序的能力或复杂性，而是因为这类应用需要能够轻松扩展、增长和转型，而并不是所有低代码平台和工具都具备这样的能力。
即使你的应用最初设计很适合低代码，但如果它对你的业务极端重要，那么未来设计很有可能需要发展。你可能需要添加更复杂的功能，将其与其他应用程序集成或将其迁移到新的企业平台。如果业务部门和 IT 部门之间的合作没有进行适当的规划，这些事情就会变得更加困难。
场景＃4：增强业务部门能力
如果你的目标是赋予业务部门更大的技术自主权，并使他们成为公民开发人员，那么采用低代码工具是一个很好的方法。大部分低代码工具和平台是易于用户上手，团队可以快速开始管理和增强功能以满足自己的需求。
需要注意的是，即使他们手中拥有最直观的工具，IT 部门也应该参与低代码工具的选择、规划和扩展。并非所有低代码工具都是一样的，选择具有足够可扩展性、可伸缩性并且可以集成到更广泛的 IT 生态系统中的工具非常重要。
平衡的重要性
当低代码首次出现时，围绕该技术的大部分叙述将其定位为传统开发的替代方案——它将减少甚至消除组织对熟练开发人员的依赖。
事实证明，这种描述完全站不住脚，无论是它对低代码设定的不切实际的期望，还是它如何将低代码和传统开发流程定位为敌人或对立面。
问题不应该是“低代码还是传统代码？”而应该是“低代码在哪里可以最好地支持和补充我们的专家开发人员？”
通过在正确的场景中启用和鼓励低代码（通常是增强小型业务团队使用的软件功能），你可以加速交付、缩短周期时间并快速s满足业务需求，而无需完全废除当前的开发实践。
在保留核心 IT 和开发团队提供的所有控制、治理和战略输入的同时，增强业务部门能力并加速交付。两全其美是可能的，但前提是你取得了适当的平衡。
在选择低代码平台之前，领导者需要回答五个问题
在你开始选择低代码平台或工具集之前，确定低代码是否非常适合你当前的业务和需求非常重要。
你需要进行一些深入的评估，但回答以下这些问题会是一个很好的起点：
(11) 有多少人会使用你正在构建的软件？
更多的用户意味着更多的需求要适应，他有可能成为组织的核心业务软件，并扩展到低代码安全区域以外的位置（需要评估考虑结合传统开发）。
(2) 你想构建的是核心软件还是支持（边缘）软件？
你的软件越接近核心业务，那么尽可能地保持其灵活、可扩展和系统间关联性就越重要——你需要重新评估是否全部应用低代码技术来构建和维护它。
(3) 随着采用率的不断提高，你现在构建的软件是否会变得至关重要？
如果你已经知道需要构建或现代化的软件系统对业务极其重要，这恐怕不会是低代码的使用场景，除非你愿意接受低代码平台的限制。
(4) 你的团队准备好成为公民开发者了吗？
为了让低代码发挥其全部的潜在价值，你的团队需要有足够的热情采用它，并开始创建自己的应用。他们还需要有一定的软件应用熟练度，以及正确的心态，才能创建真正有价值的应用。
(5) 你真正想解决什么问题？
例如，如果你希望清除大量积压的工作，那么可能有比采用低代码更好的方法来实现这一目标。你可能试图解决流程效率低下的问题，而不是解决潜在的挑战。当然，你还是可以定义出通过低代码解决方案才能满足的特定需求。
低代码并非万能的，但它能教给我们很多东西
低代码并不是代码的替代品。如果一个组织放弃他的开发团队，并使用低代码平台完全将开发控制权交给业务团队，那么他们在实现目标方面将非常受限。
但对于特定的场景，低代码仍然是一项非常强大的技术。它提供了快速填补能力差距的手段，为部分用户组的边缘软件构建带来新的可能，并使业务团队能够在需要时 DIY 实现自己需要的应用。
通过将低代码与传统代码和开发实践相结合，组织可以在不牺牲核心软件所需的灵活性和可扩展性的情况下，赋予公民开发人员部分权力。这才是真正应用低代码的甜头 - 应用在特定场景并解决非常具体业务部门需求；由IT专家监督，并与传统开发实践和资源结合应用 - 而不是取代它们。
低代码的定义
有很多平台称自己为“低代码” - 但这意味着什么呢？根据我们的经验，低代码通常用于描述允许用户使用可视化拖拉拽等方式创建业务逻辑和界面的平台。
通常，它们比无代码平台更可配置和可定制，尽管两者之间有相当大的重叠。低代码工具通常也允许一些（少量）“真正”的代码 - 通常是所谓的脚本语言，如JavaScript - 来执行常规可视化拖拉拽工具无法完成的任务，例如更复杂的业务逻辑。
