我和我的同伴是如何用具体的代码例子，说明源代码管理的基本操作

  在我和我的同伴练习源代码的过程中，了解到源代码必须由最熟悉代码的人来写，因为代码的作者了解代码的目的、特点和实现的局限性。所以，写源代码没有比作者更适合的人选了。然后问题就逐渐的产生了，比如说：我和我的同伴总有一个人有不得空的时候，那能不能请求别人的帮助呢？答：如果忙到连源代码都没有时间写，那么你也没有时间写好这个功能。在一些极限编程的方法中，是可以考虑让别人来做源代码的，但是，程序的作者还是要对源代码负责。对于写好的源代码我们也有一些建议：1. 在源代码测试过后，机器状态保持不变。如果源代码在数据库中创建或修改了记录，那么也许要删除或恢复这些记录，或者每一个源代码使用一个新的数据库，这样可以保证源代码不受以前源代码实例的干扰。2. 源代码要快（一个测试的运行时间是几秒钟，而不是几分钟）3. 源代码应该产生可重复、一致的结果。比如说：如果用随技术以增加测试的真实性，好么？答：一般情况下不好，如果某个随机数导致程序出错，但是下一次运行又不能重复这一错误，则于事无补。我们还是要用随机数等办法“增加测试的真实性”，但不是在源代码中。源代码不能解决所有问题，不必期望它会发现所有的缺陷。4. 独立性——源代码的运行／通过／失败不依赖于别的测试，可以认为构造数据，以保持源代码的独立性。5. 源代码应该覆盖所有代码路径。（出自构建之法P26）

    之后我们又探讨到了代码复审这一部分，在我们看来，要做到代码更加完美，需要一遍遍的复审代码，不容许有一丝错误的存在，那么就会存在一个问题：若果开发者做到完美，那么复审者的时间和精力就是一种浪费了？答：不对，即使是完美，代码复审也还有“教育”和“传播知识”的作用。更重要的是，不管多么厉害的开发者都会或多或少地犯一些错误，有欠考虑的地方，如果有问题的代码已签入到产品代码中，在要把所有的问题找出来就更困难了。大家学习软件工程都知道，越是项目后期发现的问题，修复的代价越大。代码复审正是要在早起发现并修复这些问题。另外，在代码复审中的问题与回应能帮助团队成员互相了解，就像练武之人相互观摩点评一样。团队有新成员加入时，代码就附身能非常有效的帮助新成员了解团队的开发策略、编程风格及工作流程。（出自构建之法P70）