我对低代码持怀疑态度

原文 ↗ Hacker News 讨论 ↗

低代码和无代码平台承诺更快的软件交付和更少的开发者，但许多工程师表示，随着需求变复杂，这些工具会失效，导致系统脆弱、版本控制糟糕，以及难以拆解的供应商锁定。评论者区分了诸如 Excel 之类的“终端用户编程”工具——它们在狭窄领域内可以极其高效——与重量级可视化平台，后者最终会在专有 GUI 和 YAML 中重建意大利面式代码，而不是使用文本。逐渐形成的共识是：低代码在边缘场景中可以很好地工作——如原型设计、简单 CRUD 应用、专家规则配置——前提是配合真正的工程实践并保留代码逃生通道；但它并不适合核心业务逻辑或长期存在、关键任务系统。

线程中“低代码”的含义

  • 这个术语使用得比较宽泛；发帖者区分了：
    • 可视化流程 / GUI 构建器（PowerApps、Webflow、Retool、Node-RED、n8n 等）。
    • 企业平台（Salesforce、SharePoint、Oracle APEX、SAP 风格工具）。
    • 类似 Excel、Access、Airtable 的“终端用户编程”。
    • 面向开发者的“更少代码”：更好的框架、生成器、headless CMS、认证/CMS 服务。
  • 有些人认为，相对于汇编，几乎所有更高层级的语言和框架都算“低代码”。

低代码擅长的场景

  • 简单的 CRUD 应用、表单、工作流、营销网站、内部仪表盘。
  • 快速原型 / MVP；之后可能会重写，也可能不会。
  • 企业中的“最后一英里”自动化：连接 SaaS、串联审批、基础集成。
  • 专家系统 / 策略引擎：让领域专家编码不断变化的规则（税务、合规）。
  • 用来替代电子邮件 + 表格 + 临时宏；赋能“高级用户”。
  • 具体成功案例：Excel、Access、Airtable 的配置，Lotus Notes、Node-RED、Retool、Power Automate、Unreal Blueprints（对某些游戏而言）。

常见问题和失败模式

  • 复杂度天花板：很容易做到 80–90%，最后的 10–20% 会变得痛苦甚至不可能。
  • 逃生通道（自定义代码）会导致专有且纠缠不清的逻辑，比普通代码更难维护。
  • 版本控制、测试、调试、可观测性和部署流程薄弱或缺失。
  • 供应商锁定：专有语言、运行时、定价（尤其是按最终用户计费）。
  • 平台升级打破现有系统；底层 schema 不透明且混乱，以及数据治理问题。
  • 意大利面式图表 / YAML / 可视化流程难以 diff、审查和维护。
  • 安全/合规、审计和长期维护常被忽视；最后往往需要 IT 来救火。

组织和社会动态

  • 这些工具常被卖给管理者，作为绕过“缓慢的 IT”和昂贵工程师的一种方式。
  • 它们往往是在社会层面解决优先级/沟通问题，却被误诊为“开发者短缺”。
  • 成功使用需要清晰的边界：非核心、非关键任务，并且要有 IT 参与。
  • 有些人认为，低代码岗位对开发者而言会限制职业发展，因为它们依赖的是小众、不可迁移的技能。

替代方案与未来方向

  • 更偏好“赋能开发者”的工具：Rails/Django 生成器、headless CMS、优质库。
  • 有人呼吁开源、可自托管的平台，具备真正的 VCS 支持和非专有语言。
  • 一些人认为，AI 辅助加上传统代码将取代“面向非开发者的无代码”愿景中的大部分内容，同时仍需要熟练开发者来处理复杂性和边缘情况。