Michael Nygard把自己列为那些仍然相信有架构这种东西存在的人之一。他在InfoQ发表的文章敏捷，架构和凌晨5点的产品问题（Agile, Architecture and the 5am Production Problem）中抛出了一个神秘的问题，并引导读者走完了从发现到解决的全过程。他在文章的最后总结道，当我们为真实的世界而非QA来构建产品应用时，需要有面向失败的思维和扎实的防御性编程策略。该文向敏捷社区中那些关于“够用就好”的架构组成的思想提出了挑战。
Nygard在Pragmatic Programmers出版的新书：“交付！设计和部署生产就绪软件”，在上个月牢牢占据了Amazon“热点新书发布”排行榜的首位。该文基于书中的一个故事进行了扩展，并把它与作者曾经经历过的敏捷过程——在那个时候，它们还被称为“轻量级方法学”——进行了结合：
敏捷方法告诉了我们很多关于如何构建能够灵活面对变化的功能性软件的方式。程序员们创建出一些诸如单元测试和 重构之类的技术来供其他程序员使用，并且将这些技艺完善推广。但是大多数情况下，敏捷方法只是关注于系统边界内的行为。在敏捷社区中，关于应该为系统边界 外的事物投入多大精力的争论一直在持续着。那些最极端的拥护者（他们算是“极限”的拥护者么？）声称，“让架构从持续的重构和强壮的单元测试中消失吧！”我是一个敏捷开发者和架构师，但是你应该把我算入……那些坚信系统实现中仍然存在架构的人中。一个好的架构可以在真实世界中存活下来。而一个坏的架构只会 在运行时发出吱吱嘎嘎的响声和艰难的呻吟，对人和计算机都是一种摧残。我常常都能看到一些架构师沉迷于自己的抽象中，创造出一些根本无法成功构建的架构。
文章中讲述的那个神奇的问题只会在凌晨的一两个小时内，当网站的访问趋近於无了一段时间以后出现：一个应用每天早上5点都会宕掉，同时宕掉的还有一个只用于 查询的数据库。引发这个问题的地方——同时也是受害者——包括一个Web服务器，一个数据库服务器和一个防火墙。如果有些人的第一个想法就是：“如果你只 是查询的话，那根本不会导致死锁啊！”这些人就应该去看看Nygard到底发现了什么。
Nygard用这个故事来阐述被他称之为“面向失败思维”的观点，这并不是说他期待着项目会失败，而是在他构建系统的时候，就一直在假设由于某种原因，在 某一天，架构中的任何一个地方都有可能出现问题。他在书中强力推荐大家在构建一套测试体系时要充满各种恶意，从简单的网络连接断掉，到使用错误的协议来发 出响应，这样才能更全面地模拟各种失败的场景。
Nygard在文中向敏捷社区发起了挑战，因为社区中那些成天为“够用就好的架构”唱颂歌的人到现在还不知道这种想法在实际应用中意味着什么。同样，在不知多少文章和书籍中推荐过的特征驱动开发和极限编程，在解决这种问题的时候还是鞭长莫及。Nygard相信，在
敏捷，架构和凌晨5点的产品问题一文中提出的问题领域内，敏捷方法只能保持明显的缄默。
敏捷已经敞开了双臂拥抱测试纪律，而且最近也在努力和技术文档（ 译者注：特指那些说明如何使用软件的文档）和可用性等其他纪律靠拢。那么有关架构的纪律也是敏捷实践要与之融合的候选之一吗？还是敏捷中已经收录了足够多的原则和实践，完全可以构建出一个强壮的架构了？
扫一扫
1856
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
