tdd的开发实践保证了代码的可测试性那么当tdd的t变的非常难写的时候是不是现有的代码已然变的可测试性非常的差呢其中一些非常典型的场景就是test的setup太难而造成这个的一个主要原因就是贫血的model和万能的service。因为model没有行为所以很多时候可以通过测试model来完成的测试却不得不通过测service来完成而万能的service做的事情又太多需要依赖的东西也太多而这个时候你本来一个简单的测试就为了setup这个service的依赖而变成一个巨型的测试。你总有做behavior verification的冲动而behavior verification本身就是邪恶的。记得《xUnit test pattens》这本书说到”任何需要白盒测试的时候往往都是代码设计的问题“。Assert太多了一个简单的测试却要有一堆的assert语句。问题很简单被测试的对象承担了太多了职责。脆弱的测试这里我看到了有两个原因第一共享的fixture第二想当然的assert比如你只是想assert这个collection有没有你要的那个instance因为你想当然的认为此时collection里只有一个instance造成后人对于这个collection加入另一个不同instance依然会break你的测试。Kent Beck说过当你的测试出现问题退后一步往往就是一个设计问题。项目初期设计framework好吗很多人开发人员迷恋framework迷恋framework设计的优雅以及对于开发的便利。我曾经也是其中一员但是现在我站在了这个观点的对立面。首先项目初期的时候framework的设计在大部分都是猜测刚开始的时候这些猜测大部分都很准因为这个时候距离是framework的设计者可以看到了这就如同你站在原地你能看到外的东西随着项目时间的增长这个距离也在增长在加上中间需求的一些变更就如同一个小弯这时候的位置已经不是framework的设计者所能看到的距离了。这个时候framework对于开发限制开始突出而开发人员碍于修改framework成本太高很多时候被framework所牵制。既然我们只能看到米外的东西那么我们为什么要做米外的设计呢其次framework的设计思想也会随着项目人员的进进出出项目进度的压力大家都没有实践仔细的去看framework。framwork的设计思想变的不再清晰大家开始按照自己的对于framework的理解来写代码后来着更不理解framework会照那些前面未必正确的理解的代码来书写。构建环境一个稳定而快速的构建环境对于团队的开发效率和开发人员的心情影响非常的大。想象一下下面两种情况如果你每次提交代码都让build变红而你花了几个小时检查之后发现问题出在构建环境上你是什么心情如果你每次提交代码测试都要跑个小时你会选择多久提交一次代码呢个人理解的解决方案就是讲build环境也版本管理理想的情况下新修改build脚本导致构建环境不稳定可以快速的revert到上一个版本的构建环境。团队团队一个团队是不仅是在维护一份源代码更重要的是维护这个项目所承载的知识。而这些知识不应该只记在某些关键人物的脑中应该记在所有团队成员的脑中更不应该只记录在文档之中。而这知识包括架构设计的知识架构设计的知识只有进入所有开发人员的脑中才能得到正确的实现。因此架构设计不应该只从技术角度考虑也应该从团队知识传递的角度考虑。一个的设计而团队成员只能理解分那你觉的最后的软件是多少分呢所谓的局部知识很多时候一些开发人员觉得我做的东西只有我一个人在做比如build脚本所以我可以选我熟悉的东西就好。而这种所谓局部知识的想法非常不可取因为当你有这个想法的时候就意味着你变成这个项目的瓶颈。固定角色在团队中固定角色就意味着划定了各个角色的边界而每个角色对于自己角色外的东西已然不是外面的世界很精彩。这个时候很多时候它做得决定都是基于自己的角色而不是整个团队的角度