请来认识敏捷开发。

“综合“不知道你所指的确切意义。 我暂且理解为“代码先放到一起（比如一个类，一个方法）中“ ，不知道是否符合你得原义？

解耦我认为主要发生在两个方面：
* 概要设计阶段。 在概要设计阶段划分系统模型的“层次“问题，如果能够清晰的认识这个“层次”问题，那么在后面的coding出来的代码会更清晰一些，层次，架构也更好。
   可以指导开发人员遵循一些必要的原则：
                    # 合理的包依赖
                    # 整体行对系统有清晰的层次结构，并将这个层次结构反映到代码中的包依赖，类依赖上。
                    # 严格警惕包的双向依赖


* 重构阶段。 这个阶段的解耦比上一阶段更细致，不仅从代码的角度来来验证概要设计，而且还罗理整理一些循环依赖。

“综合“是对某一功能的从需求开发的“大局观“，这个和上面的解耦并不冲突。
偏重任何一方都不好，概要设计阶段做好清晰的层次分析，以及更多一些的工作，这些工作很多部分属于“解耦“的元素，而在针对需求进行TDD的话，从顶向下，是一种综合的元素，代码可以组建在一个类，一个方法上演进下来。这样的演进属于一种对 功能实现的“综合观”，但是并不影响后期用“重构“的手段对其进行合理的“重整“，其中自然包括必要的“解耦“ 。

还想对 “解耦“多罗嗦几句，在重构出合适的对象，以及合适的功能分解方面，是属于非常主观的东西，但是有几个依据可以成为客观的元素：
*  类的代码不宜超过太大，合理的数据似乎是 3-400行
* 每个方法的代码不宜超过 50行，如果自认自己水平更高的话，这个行数可以降到20-30行。
* 当类的代码太大时，请考虑extract class 并且使用delegate模式 。 这个时候，注意一点，当extract class时，可以适当考虑“功能分解“以及“功能解耦“。不仅是在做代码的重构，此时，也可以做更细致的功能分解，罗理更清晰的对象结构。 
  说到delegate技术，我觉得它在重构和模型设计中扮演者一个非常重要的元素，因为几乎所有的工作都可以用它来得到完满的解决。

* 类的依赖不能太多。

* 合理的把依赖的行为代理到依赖的直接对象上。  a.getB().getC().dologic(...) ,这样的编码应该被警惕。 更可行的是 重构为---> a.dogloci(..)  , a作为当前对象的“直接对象来看待“，所有的行为都不应该过多依赖于“间接对象“

虽然我是从看外国老的话 走入XP的，到现在也经过几个年头了，期间用了很多个项目反复照着 “外国老“说的来做，确实很多效果并不好。 原因正如你说的：人云亦云。
但是，经过这么多的实践，和足够的反思。 上面这些话更多的是我一种经验之谈。也是表达我一个普通coder对XP的理解。

这个理解的“每一句话“并不是“人云亦云“，希望我的理解 能够让你从中受到启发。

如果你只是照着你上面的态度来看待我的观点，那我只好说声“走好！“。

如果这个是个标准那我们现在写的东西是不合标准的，但是我记得重构那本书了的推荐类代码行数是2000行，而且我们现在项目基本上符合2000行的要求，同时方法的行数一般都在100行以下，我想这个是由非常复杂的业务逻辑造成的,因为我想如果把方法拆开对我们的业务逻辑来说确实不怎么合理，这种情况下我们需要提炼方法吗

“* 合理的把依赖的行为代理到依赖的直接对象上。 a.getB().getC().dologic(...) ,这样的编码应该被警惕。 更可行的是 重构为---> a.dogloci(..) , a作为当前对象的“直接对象来看待“，所有的行为都不应该过多依赖于“间接对象“
我以前的代码中就患了这个错误，当时也实在不应该，开始重构。

最关键的是方法。
类的行数达到2000行，可以先对这个类进行合理的重构，着重先看方法之间是否有重复的代码，无论多和少，重复的部分都应该仔细考虑是否可以重构出一个特定的方法。

如果觉得这个类里面的方法确实没有什么可以重构的啦，那么请观察这个类是否和别的类有相似的逻辑部分，可以考虑把共同的逻辑放到一起。

上面的都做过了，这个类还是很大的话，你可以有几个选择：

* 不理会，反正method都很清晰。 代码也很易读 。

* 是否这个类负责的功能需求太多了？ 是否可以按照业务类型来把需求分离出去？ 组成一个新的业务类？

后者或许更好一些。代码层次也清晰一些。

因为敏捷讲究驱动测试，包括单元测试和验收测试。就是开发人员在编写代码之前先写单元测试代码，以便告诉开发人员系统在某一点上是否正常“工作”。而客户在开发人员定义了素材后就写验收测试计划，以告诉团队系统是否执行用户希望它执行的操作。

小弟不才，但火哥对mock,test 粒度，实现步伐，重构类和方法责任等的看法,却也道出了小弟的心声

ps:
总觉着书上说的太理想，开发中还要pragmatic一些

哪里在用敏捷 请前辈推荐几家公司？

感谢火老大的细致说明.

我这里的"综合",是指各个构件的协作。
先撇开测试不谈，构件之间要完成特定任务，就需要相互协作。要测试某个构件，不论用什么方法，都需要模拟它能够感知的其他构件。这就涉及到解藕，通过增加新概念，比如：接口，IOC等等，可以达到此目的。但也增加了繁复。而且像什么单子，静态方法之类的，就最好收藏起来。

有没有更加简明、优美的方法呢？想把它拆开就拆开，想直接的协作，就直接的协作。

看来你就没有主见啊。书上的一定不好吗？没有书上的能有你的吗？