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