Udi Dahan:“扔掉原型系统”
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中文站投稿或者参与内容翻译工作,请邮件至 [email protected]。也欢迎大家通过新浪微博( @InfoQ)或者腾讯微博( @InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。