代码即设计

原文链接

想象一下明天醒来看到的景象,建筑行业取得了百年突破。数百万的便宜、高效的机器人可以凭空制造物料,几乎零成本,可自我修复。而且更好的是:给一个靠谱的工程蓝图,机器人可以不需要人类的干预就完成建造,成本可忽略不计。

有个可遇见的发生在建造业的冲突,行业上游会发生什么?如果建造成本忽略不计了,那架构师和设计师何去何从?今天在投资建造之前需要先进行物理和计算机建模和严格测试。如果建造本身是免费的我们会烦恼吗?如果设计出错了,没什么大不了——找出问题所在,让我们的魔法机器人在建一个。这是未来可预见的。建模将会被淘汰,未完成的设计将在不停的建造和完善中改进,直至非常接近目标。对于一个不负责的监理而言,区分完成和未完成将是一件烦恼的事。

我们预估时间线的能力会逐渐消失。由于建筑成本会比设计成本更容易计算——我们更准确地知道安装大梁的成本和数量。随着可预估的任务缩小为零,可估计的设计时间就越来越少,开始站主导地位。结果就是生产更快,但“靠谱”的时间消失了。

当然,市场竞争机制仍然试用。随着建筑成本的消除,一家快速完成设计的公司能够在市场中占据优势地位。快速完成设计称为工程公司的核心推动力。当然,一些没有深思熟虑的设计将被看作未验证版本,只是看中早期发布的市场优势,然后说“这看起来够用了。”

一些生死攸关的工程将变得更仓促,但消费者应该受够了设计半成品所带来的苦。公司总是排出他们的魔法机器人去“修补”这些破损的建筑和机械。所有这些都指向一个反直觉的结论:我们大幅降低了建设成本,结果质量也降低了。

我们不应去惊叹上面这个故事在软件业同样上演着。如果我们同意代码即设计——这是个需要创造力的过程而非机械式的——这也可以解释软件危机。我们现在知道一个设计危机:对质量、经验证的设计需求已经超过了我们建造它们的能力。导致使用未完成设计的概率更高。

值得庆幸的是,该模型还是给我们提供了较好的线索。物理仿真等同于自动化测试;软件设计只有经过暴力测试后才算完成验证。为了使这些测试更有效,我们正在寻找能够检测大型系统中巨量状态的方法。改善编程语言和设计实践让我们重新燃起希望。最后一个不可避免的事实:伟大的设计是由伟大的设计师致力于掌握他们的技艺而产生的。代码也不例外。

0%