从卓越工程角度看微软中国开发团队的成长
开发团队的成长离不开优秀的人才，简捷有效的流程和高效率工具这三个卓越工程系统中的重要因素。本文作者从这三个因素分析了微软中国开发团队是如何“从优秀到卓越”的。
新闻
敏捷，架构和凌晨5点的产品问题
作者 Deborah Hartmann译者 李剑 发布于 2007年6月26日 上午1时25分
Michael Nygard把自己列为那些仍然相信有架构这种东西存在的人之一。他在InfoQ发表的文章敏捷，架构和凌晨5点的产品问题（Agile, Architecture and the 5am Production Problem）中抛出了一个神秘的问题，并引导读者走完了从发现到解决的全过程。他在文章的最后总结道，当我们为真实的世界而非QA来构建产品应用时，需要有面向失败的思维和扎实的防御性编程策略。该文向敏捷社区中那些关于“够用就好”的架构组成的思想提出了挑战。Nygard在Pragmatic Programmers出版的新书：“交付！设计和部署生产就绪软件”，在上个月牢牢占据了Amazon“热点新书发布”排行榜的首位。该文基于书中的一个故事进行了扩展，并把它与作者曾经经历过的敏捷过程——在那个时候，它们还被称为“轻量级方法学”——进行了结合：
敏捷方法告诉了我们很多关于如何构建能够灵活面对变化的功能性软件的方式。程序员们创建出一些诸如单元测试和 重构之类的技术来供其他程序员使用，并且将这些技艺完善推广。但是大多数情况下，敏捷方法只是关注于系统边界内的行为。在敏捷社区中，关于应该为系统边界 外的事物投入多大精力的争论一直在持续着。那些最极端的拥护者（他们算是“极限”的拥护者么？）声称，“让架构从持续的重构和强壮的单元测试中消失吧！”文章中讲述的那个神奇的问题只会在凌晨的一两个小时内，当网站的访问趋近於无了一段时间以后出现：一个应用每天早上5点都会宕掉，同时宕掉的还有一个只用于 查询的数据库。引发这个问题的地方——同时也是受害者——包括一个Web服务器，一个数据库服务器和一个防火墙。如果有些人的第一个想法就是：“如果你只 是查询的话，那根本不会导致死锁啊！”这些人就应该去看看Nygard到底发现了什么。
我是一个敏捷开发者和架构师，但是你应该把我算入……那些坚信系统实现中仍然存在架构的人中。一个好的架构可以在真实世界中存活下来。而一个坏的架构只会 在运行时发出吱吱嘎嘎的响声和艰难的呻吟，对人和计算机都是一种摧残。我常常都能看到一些架构师沉迷于自己的抽象中，创造出一些根本无法成功构建的架构。
Nygard用这个故事来阐述被他称之为“面向失败思维”的观点，这并不是说他期待着项目会失败，而是在他构建系统的时候，就一直在假设由于某种原因，在 某一天，架构中的任何一个地方都有可能出现问题。他在书中强力推荐大家在构建一套测试体系时要充满各种恶意，从简单的网络连接断掉，到使用错误的协议来发 出响应，这样才能更全面地模拟各种失败的场景。
Nygard在文中向敏捷社区发起了挑战，因为社区中那些成天为“够用就好的架构”唱颂歌的人到现在还不知道这种想法在实际应用中意味着什么。同样，在不知多少文章和书籍中推荐过的特征驱动开发和极限编程，在解决这种问题的时候还是鞭长莫及。Nygard相信，在敏捷，架构和凌晨5点的产品问题一文中提出的问题领域内，敏捷方法只能保持明显的缄默。
敏捷已经敞开了双臂拥抱测试纪律，而且最近也在努力和技术文档（译者注：特指那些说明如何使用软件的文档）和可用性等其他纪律靠拢。那么有关架构的纪律也是敏捷实践要与之融合的候选之一吗？还是敏捷中已经收录了足够多的原则和实践，完全可以构建出一个强壮的架构了？
查看英文原文：Agile, Architecture and the 5am Production Problem
相关厂商内容
很好，很和谐
发表人
凉粉 小刀
发表于
2007年9月5日 下午8时25分
Re: 很好，很和谐
发表人
霍 泰稳
发表于
2007年9月5日 下午10时7分
Re: 很好，很和谐
发表人
Xiaogang Guo
发表于
2007年9月7日 上午3时15分
所有的痛苦都是类似的
发表人
qiang zhou
发表于
2007年9月10日 下午8时35分
Re: 所有的痛苦都是类似的
发表人
霍 泰稳
发表于
2007年9月10日 下午9时0分
Re: 所有的痛苦都是类似的
发表人
浩 张
发表于
2007年9月27日 上午1时42分
-
这是多么彪悍的一篇文章啊
-
够用就好有时带来的问题是对前面所有的功能推翻重来，或者有时会造成难以收拾的后果，所以说按照中庸的思想，还是前期充分考虑架构，然后逐步敏捷实现比较好一些。
-
事后再回头看会觉得当初如果怎样怎样就好了，而忘了事前要正确地预测几乎是不可能的。试错的价值很难测量也很容易被忽略。在经过试错之前，正确完成的成本可能是无穷大，却很容易被当成是零。
-
我现在也被类似的问题困扰，20台机器突然从JMS的服务器上断掉。几分钟以后会自动恢复。也是个拔头发的问题
-
楼上的宕机原因找到了吗，有什么解决的办法？分享一下。这是个非常有意思的话题。
-
一旦流量开始升高，另外三十九个连接马上就锁定了。尽管剩余的一个连接还可以生成页面，但它迟早会被某一个线程占用，该线程阻塞在其余资源池的连接上。因此，唯一好使的连接也被阻塞线程占用了，整个网站也就掛了。
据我所知，一个线程同时拥有两个以上资源池是完全应该避免的。如果有这个现象，在一般场合也会导致资源池竞争。
6 条回复
回复