《高效团队开发》书评

理论意义大于实践意义

这本书花了2天时间粗略过了一遍，据说这本书还得了什么奖，看下来感觉并没有想象的那么好。书的内容可分为两部分，一部分是普及敏捷开发的概念，作者举出了一些开发中“常见”的例子，通过这些案例对比，很通俗直观的表现出了敏捷开发的优势所在。还有一部分就是讲解敏捷开发会用到的一些工具的用法。作者似乎非常的推崇敏捷开发，可实际上“敏捷开发”的一些实践还颇多争议，而有一些即便没争议也夸大了实际的效果。本书的前几章举了一个例子，说某个团队在开发过程中不用版本控制软件，代码都是拷贝粘贴备份这种方式，之后作者引出了svn和git这样的版本控制软件，说有了这个神器，就永远告别了前面这种代码和文档的原始的管理方式了。作者说法自然是没有问题的，可是这都2016年了喂！还有不用版本控制的团队吗？本书的前面的好多章都是类似这样的内容，且不说现在几乎没有团队还以如此原始的方式开发项目，即便真的像作者说的这样，我认为也没有必要用这么多的篇幅来说明这件事，完全可以直接把使用这些工具的好处列举出来就可以了。当然如果有人想详细的了解一下这些开发的流程，还是可以买来参考一下的。本书还用大篇幅介绍了另外一个概念：TDD。作者认为TDD能让我们的项目质量可控，代码质量可控。真是这样吗？就我个人的经验来看，实际开发却并非如此。换句话说TDD这种东西只能领会其精神，不能一成不变的直接套用在项目开发中的。如果严格的遵循TDD的标准去编写方法级别粒度的测试用例，覆盖所有逻辑分支，其代码量往往是项目代码的好几倍。如果还需要多个系统之间的集成测试，整个测试过程会变得更加不容易，加上测试数据与测试环境的准备，会让编写测试代码和测试代码的后期维护变成一个极为沉重的负担。而如果系统逻辑本身很简单，这又会使得测试代码的编写成为一种多此一举的行为，测试代码也会变成一种形式化的“自我安慰”。比如：假定代码遇到某些输入边界会抛出一个异常，程序员写了一大坨代码来触发去验证程序逻辑是否正确，这种测试代码写得会让人很抓狂！而且测试还有另外一个问题，同一个用例项目编码早期可能跟发布时的代码有天壤之别，项目代码都是边开发边优化。而测试却是很实现细节的表现，过早的编写测试就意味着后面每一次主体代码的修改都伴随着测试代码维护逻辑一致性的修改。一些极端的TDD甚至主张的实践团队甚至会要求程序员先编写测试用例，在写符合测试用例的代码，他们认为这样就能保证项目的质量。这种做法更是加剧这个问题的产生，诚然，测试先行确实能一定程度的保证项目逻辑的正确性，但是仅因为这一点好处，就让开发本身变得负累过重值得吗？一旦出现这些问题，就一定会导致另外一个问题，因为维护性的问题使得代码质量会急剧下降。试想，如果程序员还没有编写测试用例，可能当他发现实现代码可以优化时顺手就修改了。如果同时还有许多测试代码对实现代码的引用，那么他必然就要对测试代码做出修改，可能是自己写的代码还好，无非多动动手多改两处就好，而如果是别人写的代码呢？他本可以优化实现代码，却由于有测试代码的同步修改而对测试代码的不熟悉使得他就不愿意去修改了！其实单方面的过于强调这些概念，都是十分愚蠢的掉书袋的行为！依据项目的情况作出合适的选择，这才是正确的项目开发之道。