敏捷、架构和凌晨五点的产品问题
重构和单元测试是否真的可以创建强壮、可用的软件，并且让其在现实世界中生存下去？下面的内容节选自Michael Nygard 的书《Release It!》，他认为“抽象有漏洞”：我需要考虑架构（甚至在Agile项目中），以便保证当基础抽象层没有正常工作时，我们也不会遇上这类5AM问题。
InfoQ
十月 332,438名独立访问用户
赞助商链接
Sun科技日2008
11月19日于广州
11月21日于北京
与Sun一起分享国
际化开源软件平台
六折SD2C门票
InfoQ中文站读者
独享6折技术大会
门票，限量提供
杭州OSUG活动
12月29日周日下午
OSUG邀您共话
GlassFish的OSGi
模块化架构分析
OpenSolaris专题
下载OpenSolaris
尝试其超酷功能
参与本地用户组
活动，即刻访问
主题/标签专用视图
评论 Content on InfoQ
最新“评论”相关专题内容
用了敏捷实践就是敏捷项目吗？
采用敏捷方法学的人越来越多，但是这也带来了新的挑战：当团队只是简单的把敏捷实践拷贝到项目中而不是在实践中逐步掌握，没有理解就直接加以实现，这又怎么谈得上敏捷呢？也许是时候该讨论一下如果没有正确的教授一些基本知识会对团队最重要的资产——诚实，守诺以及客户的信任——带来怎样的负面影响了。
“评论”相关新闻
James Shore：敏捷的衰落
James Shore声称敏捷正在走向衰落。他说，很多团队在用“sprints”和每日例会，但是却不采用那些可以在长期内产出高质量软件的技术实践。在他的估计中，已有无数个Scrum团队将敏捷用的如此之烂，不仅失败已成必然，而且会将敏捷的发展跟他们一起拖入泥潭。
诚实——是敏捷的价值观吗？
在一篇引人深思的博客中，Declan Whelan引用了他从Mishkin Berteig那里了解到的想法：诚实，是敏捷团队之所以成功的一个（不言而喻的）原则。这个想法很简单：如果个人不够坦诚，绝大部分的敏捷实践无法发挥作用。
关于TDD的观点：质量是反复思考的结果，仅靠解决Bug无法获得
“单元测试可以改善代码质量”这一观点已经得到广泛认可。培训师、顾问兼咨询师Michael Feathers在最近的一个帖子中对其提出了质疑。他谈及单元测试、集成测试、TDD和净室软件开发（Clean Room Software Development），认为代码质量是反复思考的结果，仅靠解决bug无法获得。
客户应该在意敏捷吗？
在敏捷项目中，客户的参与被视为理所当然，然而，很多时候（自觉或不自觉地），客户可能对这个敏捷实践有所抵触。在极限编程讨论组有个很有趣的讨论，试图解释这种情况，并找到可能的解决方法。
枕边用户故事：牛仔与童话
David Longstreet宣称“敏捷软件开发”只不过是一个试图将“牛仔式”开发正统化的童话。Geoff Slinker邀请他基于严谨的逻辑论据和引用来源重新写一篇严肃的文章。
Cockburn谈测试：真正的程序员都有良好的单元测试
Alistair Cockburn在休闲的时候，注意到了我们可能在为那些不合逻辑的所谓“测试先行”或者“先编码后测试”找一种说辞。对于一个专业程序员而言，最重要的是要进行良好的单元测试（Good Unit Tests，GUTs）。 Eureka！
TDD真的可以确保质量？
加拿大工程学院的国家研究委员最近进行了一项关于测试驱动开发的研究。其他人对研究结果进行分析后，得到了一些有趣的结论，它涉及到测试先行方法相对于传统的后测试方法，能够在多大程度上、或者是否能够改善软件的质量。