前些天，有位同学软件工程课的作业上，对于读完《构建之法》之后问了几个问题，其中两个问题我印象比较深刻：一个问题是关于单元测试的，是不是必须所有分支，覆盖率达到100%；另一个问题是关于如何结对编程的。
在读2.1.2 好的单元测试的标准时，在P27中读到了上文，作者说代码覆盖率需要考虑到每个模块是否覆盖到了每个函数，是否覆盖到了每个语句，是否覆盖到了每个条件分支，是否覆盖到了每个布尔表达式的TURE|FALSE。但是在实际的软件工程中，在进行单元测试时，我们真的要保证有100%的代码覆盖率吗？是否只要保证了单元测试覆盖了所有的代码路径之后，像是语句覆盖之类的就可以不用全部代码覆盖了呢？就像如果出现了《100％代码覆盖率的悲剧》中提到的情况那样，某段代码功能看起来很简单，没有条件，没有循环，没有转换，没有任何复杂的东西，只是一段简单的老胶水代码。那么这时候我们也需要对它们进行代码覆盖，进行测试吗？这类的代码我们是否也要对它们保证完全覆盖呢？
在读4.5.2 为什么要结对编程时，在P85页读到了上文的内容，作者说两人结对编程时，程序的质量将取决于水平较高的一位，也就是说在编程过程中是由水平较高的程序员作为主导。但是这样的话，在进行编程的过程中，是否会出现水平较高的程序员长时间的掌控着键盘，而水平较低的程序员是否也会觉得由水平高的写代码能够更好地完成项目或者课设，然后自己基本上没有做什么核心任务这种情况呢？那么到项目结束时，就会出现不会的人还是不会，会的人更加会了的情况。像这样的情况在我们的课设中也是可以看到的。如果我们想要避免出现这样的情况，那么在编程初期我们应该怎么样分配工作才能够保证即有质有量地完成编程任务，不会出现代码来不及写的情况，又能够让两个人都能够都参与到主要代码的编程中？怎么样的工作量才能够让结对编程的两个人都能够有所收获呢？
我上学时也有过类似的困惑。当年因为自学了一些编程技术，所以有机会在学校的网络中心兼职，负责维护、改版学校的网站。日常的网站开发，也没有用啥软件项目管理知识，纯粹就是小作坊式开发，毕竟网站也不算复杂，也还运行的不错。
大三的时候我和另一个兼职的同学都转到软件学院去了，第一学期学的就是软件工程，一学期课程上完，觉得软件工程讲的太好了，以前的做法简直是土到家了，一点不科学。恰逢网站要改版，和同学一商量，都觉得项目开发，要文档先行，一定要按照软件项目管理的流程，先把需求分析文档、设计文档写好，再着手开发！
关于文档的重要性那是记得滚瓜烂熟，毕竟考试前刚背过，但是对于如何写需求分析文档和设计文档，却是两眼一抹黑，那时候网上资源也不算太丰富，源代码到处都是，偏偏文档找不到可以借鉴参考的，于是整天都在琢磨如何写文档。结果到我们毕业的时候，文档也没憋出来，那次网站改版也宣告流产了！
这让我对软件工程产生了怀疑，为什么我按照软件工程讲的反而做不出项目来了？
随着时间推移，项目经验的丰富，已经把这事都快忘记了，这两个问题倒是让我又有机会去反思一下：为什么实际的项目和书本的介绍总是会有些出入？完全按照书本去做有时候反而画虎不成反类犬？
如果只看单元测试问题：
单元测试的目的是什么？保障代码质量。换个角度说，就是单元测试是保障代码质量的手段之一。再回想下软件项目管理里面的铁三角，四个要素：时间、范围、成本和质量之间是相互影响和制约的。
单元测试写得好，可以提高代码质量，但是需要更多的时间和成本，到底要把单元测试写到什么程度，完全取决于要如何平衡这几个要素之间的关系。
一味的追求单元测试的覆盖率，就陷入了教条主义的陷阱，错把手段当目的！
再看结对编程和文档的例子，也是类似的问题，结对编程和写文档，都是提高项目质量可以应用的手段，但并不是最终的目的。
在教科书上，各个章节都是相对独立的，都是一个个的知识点，而现实的软件项目是立体的，是需要将各个知识点组合在一起的。在学习这些知识点时，如果不能站在更高的角度去综合看待，而是孤立的只看这一个知识点，就容易陷入教条主义之中，错把手段当目的。
要对这类问题不困惑，总还是离不开做中学（Learning by Doing），在实际的项目积累经验，对课本上理论知识进行印证。这样遇到各种不同的项目场景的时候，能抓住重点和本质，采用适合的手段来达到项目的目标。Make it run, make it right, make it fast！
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。