戳穿可视化编程工具的两项现场测试

供应商展示可拖放的炫酷演示，容易让人误以为在现有编程模型上加一层薄薄的装饰就能提供更高层次的抽象。但一个复杂模型（比如包含并发、长期运行事务、补偿等概念的工作流），即便封装在漂亮的可视化包里，概念权重依然很高，可视化表征无法消除设计本身的挑战。作者用两项测试戳穿这种假象：一是故意在输入控件里输错值，通常会弹出含义模糊的错误提示或生成难以理解的自动代码错误——这叫”走钢丝编程”，只要保持走直线就没事，走错一步就跌入深渊；二是让供应商离开房间两分钟，随机改动部分配置，等他们回来调试弄清改了什么，没有供应商愿意接受这项挑战。可视化编程刚开始似乎能提高效率，但往往无法很好地适应规模变化，一旦应用增大就很难弄清发生了什么，调试和版本控制也会变成噩梦。

结构图：

flowchart TD
  V["供应商可视化编程演示"]
  V --> T1["测试1:故意输错值<br/>→模糊报错/走钢丝编程"]
  V --> T2["测试2:随机改配置,离场2分钟<br/>→供应商回来能否调试出改了什么"]
  T1 --> R["规模变大后:调试/版本控制变噩梦"]
  T2 --> R