敏捷、TDD(测试驱动开发)、OO--前奏

　　刚接触开发时，尽管就已经明白，瀑布模型并不是一个很实际的模型，但心中还是有一种向往：根据需求建立软件模型，搭出一个框架出来，然后让开发人员添砖加瓦，最终形成一幢漂漂亮亮的房子出来。
　　但实际的接触中，才发现，软件开发实际是一场恶梦，根据80/20原则，我们有80%的精力都花在客户实际上重要而又并不是很重要的20%的需求上，比如一些提供便利性的操作，让人非常头痛，也没有一个很好的模式能够解决，无论是对象复用还是代码生成都做过十分深入的研究，但最终发现，我们仍然要不断地调整调整再调整。
　　对于我们的团队来说，软件开发中，有两个浪费时间的修改：一是UI界面，二是数据访问，两者大量的人力物力。业务层次因为有专门的业务分析专家与良好的建模人员，实际上，基本业务上的改变，对我们来说，并不会有太大的影响。但可恶的是，业务上的改变，往往会追加一些新的字段，引起数据访问与UI界面的变化，造成自上而下修改。
　　实质上，罪恶之源还是业务变化。
　　我们曾经追寻O/R Mapping来减轻数据访问的开发负担，但效果并不理想，因为.NET下并没有一个十分成熟的O/R Mapping组件，然后又再次追寻使用代码生成器，甚至专门成立了一个小组研究代码生成器，但效果十分不理想，因为现实变化因素实在是太多了，代码生成器很难做到周全，不过，在做了多少算多少的基础上，仍然提高了不少的效率。
　　我一直很厌恶：做完需求就作数据库的分析，然后围绕数据库进行UI开发。也许，这是一种有效的形式，但可惜的是，那么多年来，总有一种诱惑让我不要这样去做，事实也告诉我们，这样做的结果有时很严重的。
　　软件一开始的需求建立，最原始的驱动力来自于业务分析人员给出的需求，在需求的描述中，领域的走查是非常重要的。项目一开始，与用户的需求否到位有很大的关系，当然，这不是全部，毕竟不能把球都踢给做需求的，很多业务分析人员，对软件开发并不能哆很好地适应，也不能给出能够使用的模型。
　　团队中，最可怕的事情就在于团队的整体素质出现水桶效应，很多团队让技术并不是很好的人去做测试代码，我觉得这是一种旋涡，因为一个良好的开发人员本身应该会对所从事的开发项目较为熟悉，对于模型的验证与代码复审都有良好的经验，他们把握测试关，肯定会做得历非常好。但是，总不能把好一点的人员都分配到测试组里吧？