Udi Dahan 在他最近的博客“构建完即弃之”中提到了软件工程师经常遇到的“鸡和蛋”的问题。一方面，客户并不一定喜欢他们所要的，因此需要和软件工程师密切的沟通；另一方面，在迭代中构建可用于生产环境的解决方案又带来了昂贵的成本。或者就像作者所说的：
你可以在即有产品之上添加实际功能、从更多的挑战中学习、并且在这个过程中完善平台的 API 和获得更多的能力储备。虽然这些是有价值的，但问题是这样一来，你获得系统需求的速度将变得很慢。
因此，Dahan 建议“构建完即弃之”。对于构建这样一个原型系统的工程师来说，不应该使用测试驱动开发（TDD，Test-Driven Development）、领域驱动设计（DDD，Domain-Driven Design）、命令查询的责任分离（CQRS，Command Query Responsibility Segregation）、事件驱动（Event Sourcing）和面向服务的体系结构（SOA，Service-Oriented Architecture）等。创建这个原型系统的构架师至少应该知道系统中最重要的用例，然后开发一个“恰好满足需求”的构架模型。在这个过程中，理解原型系统和产品代码之间的差别是一大挑战。
在博客的最后，Dahan 写道：
效果比效率重要。在将油门踩到底之前首先要保证方向是正确的，要试着去接受甚至拥抱那些重复的工作。
Dahan 的这篇博客收到了一些读者的评论。
比如，Jonathan Oliver 写道：
我完全同意，特别是“效果比效率重要”。事实上，《7 Habits of Highly Effective People》的作者也曾提到：我们总是为了效率而奔波，而这正是许多问题的源头，相反，效果才是我们真正需要的。
Jonathan Atting 回复道：
非常棒的一篇博文。最初的原型系统通常是由原型语言完成的。大家看到的不仅是一个需要“扔掉”的原型系统，同时也可以从中获得更多的实质性建议。如果原型系统看起来就像真的一样，那么大多的反馈将集中在 GUI 上，例如按钮的尺寸和位置等。但是最终，我们将无法获得实际的具有验证性的反馈，直到用户开始使用我们的产品。
Nightwatch 认为，原型系统存在一些风险：
恕我直言，这个建议在冒很大的风险——当客户正在为已有的原型而兴奋不已，并开始着手进入下一阶段时，你却立刻喊停，并对客户说：“没有那么快，现在我们得从头开始写代码，4 个月后，我们才将实现原型中展现的效果，并开始下一阶段的开发”。这样怎么行得通呢——客户会认为你是在浪费他们的时间，并且付出的努力也前功尽弃。这样以来，你不仅在打消他们的信心，同时给了客户更多时间来改变他们的需求。最后，当你向客户展示产品时，他们需要的可能是另外的东西了。
查看英文原文： Udi Dahan on Throw Away Prototypes
感谢贾国清对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。
中国开发者画像洞察报告 2022
本次报告为你深度解读开发者人群背景，分析开发者群体面临的挑战，洞察开发者人群特征，预测开发者生态发展...
评论