Michael Nygard 把自己列为那些仍然相信有架构这种东西存在的人之一。他在 InfoQ 发表的文章敏捷、架构和凌晨5 点的产品问题中抛出了一个神秘的问题,并引导读者走完了从发现到解决的全过程。他在文章的最后总结道,当我们为真实的世界而非QA 来构建产品应用时,需要有面向失败的思维和扎实的防御性编程策略。该文向敏捷社区中那些关于“够用就好”的架构组成的思想提出了挑战。
文章中讲述的那个神奇的问题只会在凌晨的一两个小时内,当网站的访问趋近於无了一段时间以后出现:一个应用每天早上5 点都会宕掉,同时宕掉的还有一个只用于 查询的数据库。引发这个问题的地方——同时也是受害者——包括一个Web 服务器,一个数据库服务器和一个防火墙。如果有些人的第一个想法就是:“如果你只 是查询的话,那根本不会导致死锁啊!”这些人就应该去看看Nygard 到底发现了什么。
Nygard 用这个故事来阐述被他称之为“面向失败思维”的观点,这并不是说他期待着项目会失败,而是在他构建系统的时候,就一直在假设由于某种原因,在 某一天,架构中的任何一个地方都有可能出现问题。他在书中强力推荐大家在构建一套测试体系时要充满各种恶意,从简单的网络连接断掉,到使用错误的协议来发 出响应,这样才能更全面地模拟各种失败的场景。
Nygard 在文中向敏捷社区发起了挑战,因为社区中那些成天为“够用就好的架构”唱颂歌的人到现在还不知道这种想法在实际应用中意味着什么。同样,在不知多少文章和书籍中推荐过的特征驱动开发和极限编程,在解决这种问题的时候还是鞭长莫及。Nygard 相信,在敏捷、架构和凌晨 5 点的产品问题一文中提出的问题领域内,敏捷方法只能保持明显的缄默。
敏捷已经敞开了双臂拥抱测试纪律,而且最近也在努力向技术文档和可用性等其他纪律靠拢。那么有关架构的纪律也是敏捷实践要与之融合的候选之一吗?还是敏捷中已经收录了足够多的原则和实践,完全可以构建出一个强壮的架构了?
阅读全文:敏捷、架构和凌晨 5 点的产品问题
评论