敏捷开发

单元测试跟验收测试有什么区别？验收测试测试的是系统的外部行为，而单元测试是测试系统内部结构，它只测一个单元（类，甚至一个方法）。验收测试属于客户的，我们没有权利决定验收测试的内容。

本文讲述敏捷开发的必要技巧——保持代码的简洁。

从技术层面上来讲，"持续集成"的含义是指开发团队中的每个成员都尽量频繁地把他们所做的工作更改合入到源码库中，并且还要验证新合入的变化没有造成任何破坏。本文中，作者将介绍如何构建持续集成所需要的环境。

本文作者回顾了目前敏捷开发的大体框架。对于敏捷软件开发，目前理解期最重要的目的是识别软件过程中没有必要的任务或者是性能低下的任务，然后去除之或者改进之。

在雅虎的极限编程组有个很有趣的讨论，Gary Brown带出了一个耐人寻味的问题：几年来，我们教育和开导我们的客户使用敏捷，可是如果突然有一天，客户明显开始抵触敏捷开发了，我们的团队该如何应对？

本文讲述了敏捷开发中将注释转换为代码的必要性，需要注意的问题和具体的实例源代码，供大家参考！

在一个大型开发项目中，不能简单地将新人排除在外，而是应该积极地引导新人逐步走上正轨。本文将从小型的“仿真项目”谈起，给大家一个引导新人入门的解决方法。

敏捷架构设计一文到目前已经全部结束，由于架构设计是一个很大的话题，要在一篇文章中完全把架构设计讲清楚是很难的。因此本文的最后一个章节中提供了一组书籍和文章，这些资料都和架构设计有关，本文的写作过程也从中获益良多，故而推荐给有兴趣的读者。

我觉得推行一个新技术最大的阻力还是来自程序员自身。管理层一般不会关心开发方法和技术细节的问题。Struts的流行恐怕主要也是技术人员发自内心的认可和推崇造成的吧。毕竟这牵涉到他的切身利益——工作效率、成就感、乐趣......

以往的软件开发团队都被认为受到软件“铁三角”的限制。三角形的三个边分别是“范围”、“日程”和“成本”。Jim Highsmith认为这个铁三角大大限制了敏捷团队的灵活性，他建议使用另一种“敏捷三角形”。

要进行应用软件的设计，分层是非常重要的思想，掌握好分层的思想，设计出的软件是可以令人赏心悦目的。由于这一章的重要性和特殊性，本章的内容分为上下两节，并不采取模式描述语言的方式。

架构愿景是一个很简单的模式，在软件开发中所占的时间也很短。但是这并不意味着架构愿景不重要。相反，它会是设计过程不可或缺的一环。

本章我们对分层在实践中可能会遇到的问题做一个讨论。分层在架构设计中是一种非常常见的，但是又很不容易用好的技术。

迭代是一种软件开发的生命周期模型，在设计中应用迭代设计，我们可以得到很多的好处。

本章中我们对敏捷架构设计的4种过程模式做一个小结，并讨论4者间的关系以及体现在模式中的敏捷方法论特色。通过这一章的描述，大家能够对前面的内容有更进一步的了解。

本身传统开发和敏捷开发各有自己适用的场景。如果要实施敏捷开发，敏捷QA对人员的要求更高，对整个Team、公司的Agile文化也有要求，需要过程。

通过一个真实的案例进行产品部署失败的原因分析

XP非常强调简单的设计原则：能够用数组实现的功能决不用链表。在其它Agile方法中，简单的原则也被反复的强调。在这一章，我们就对简单性做一个全面的了解。

架构模型通过精化、合并等活动之后，将会直接用于指导代码。而这个时候，往往就会暴露出一些问题出来，通常在实际编码中，发现架构存在或大或小的问题和错误，导致编码活动无法继续。这时候我们就需要对架构模型进行修改了。而架构设计的过程本身是一个迭代的过程，这就意味着在每一次的迭代周期中，都需要对架构进行改进。

敏捷团队中需要英雄，例如架构师。在我们现在的网站项目中，我们所计划的很多功能都需要用到尖端的技术，但是大部分技术我们几乎没有经验。很幸运，我们的架构师很快理解了新技术。