代码审核
　　众所周知，在团队中进行代码审查（Code Review）可以提升代码质量，分享项目知识、明确责任，终达到构建更好的软件、更好的团队。
　　代码审核及其重要，一般来说每周都要做一次代码审核。首先，代码审核有利于你跟踪项目进展情况，我们能真实地看到手下的人进展如何，并且更早发现他们是否误入歧途。有时候，手下人会说“完成得差不多了！”，你去看代码时发现什么都没有或者只是一堆垃圾，诸如此类，总之离完成还很遥远。在管理中，这种情况是让人讨厌的，所以我认为代码审查是避免这种麻烦的佳途径。
　　单元测试
　　要认识单元测试，首先要明白什么是“单元（Unit）”。所谓“单元”指的是代码调用的小单位，实际上指的是一个功能块（Function）或者方法（Method）。所以单元测试指的是对这些代码调用单元的测试。
　　单元测试是一种白盒测试，是必须要对单元的代码细节很清楚才能做的测试。所以，单元测试的编写和执行都是由软件工程师来做的。相对于单元测试，还有集成测试。集成测试基本都是黑盒测试，主要是由测试人员根据软件的功能手册来进行测试，需要有专门的测试环境配合。集成测试又分功能测试、回归测试等。
　　需要单元测试的代码实际上是开发人员自己写的逻辑，测试逻辑所依赖的环境是否正常不是单元测试的目的。在环境访问代码中引入逻辑，只会让逻辑更难测试，导致逻辑代码无法进行单元测试。因此，可单元测试的代码，才能够采用单元测试。判断可测试的代码还有一个方法，是看这个方法能否用一个 main 函数直接运行，如果可以的话是可单元测试的代码。可测试的代码还有另一个特征，是该方法单元的参数，开发人员可以自由模拟，不需要依赖外部环境。
　　集成测试
　　集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。一些局部反映不出来的问题，在全局上很可能暴露出来。
　　集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的借口是否正确。它根据集成测试计划 ，一边将模块或其他模块组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各个组成部分是否合拍。集成测试的策略主要有自顶向下和自底向上两种。也可以理解为在软件设计单元、功能模块组装、集成为系统时，对应用系统的各个部件（软件单元、功能模块接口、链接等）进行的联合测试，以决定他们能否在一起共同工作，部件可以是代码块、独立的应用、网络上的客户端或服务器端程序。
　　系统测试
　　系统测试阶段包括系统测试方案及用例编写、功能性测试、性能测试、稳定性测试。
　　为了验证需求分析确定的功能是否齐全并被正确实现，同时还要对安装、部署、适应性、安全性、界面等非功能性需求进行测试。系统测试也有测试人员负责，应该在需求分析完成后进行设计，在集成测试完成后进行实施。
　　功能性测试一般由独立测试小组采用黑盒方式来测试，主要测试系统是否符合“需求规格说明书”。在经过以上各阶段测试确认之后，把系统完整地模拟客户环境来进行的测试。系统测试是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试，其目的是通过与系统的需求相比较，发现所开发的系统与用户需求不符或矛盾的地方，从而提出更加完善的方案。
　　性能测试验证系统的稳定性和效率，检查系统是否满足规定的性能要求。性能测试通常选择一些典型的功能，检验这些功能在大量用户同时使用系统时系统是否稳定。性能测试由测试人员负责，可以在系统测试完成后进行，也可以对重要模块先进行性能测试，可以贯穿整个测试周期，目的是尽早发现系统的性能瓶颈并提早解决。
　　稳定性测试和性能测试都必须等到系统基本没问题、趋于稳定时再进行才有效果，否则很难顺利测下去，出现异常也不能定位究竟是系统架构的问题，还是功能上的缺陷。
　　稳定性测试（亦可称可靠性测试）通过给系统加载一定的业务压力，让系统持续运行一段时间（一般为 7x24 小时），检测系统是否能够稳定运行。
　　产品发布
　　产品发布是系统测试结束后的后一步，通常在软件产品开发过程中不需要产品试制环节，可以直接上线，只需要系统测试员输出系统测试报告并批准产品发布（上线）可以了。
　　产品发布前需要通过产品发布说明会形式，对整个产品开发过程从立项开始回溯过程，指出整个过程中的不足点，总结经验，为下一个项目提供经验案例。这一会议可以通过正式会议形式召开，需要召集产品经理、主要开发人员、测试人员、上级领导等参与，准备充分，尽大可能说清楚这个产品发布之后的效果、效益，为上线后的价值评估做准备。这一环节不可缺少，即便在互联网公司，迭代速度很快的情况下，这一环节也需要满足。
　　开发过程复盘
　　其实开发过程体系里并没有这一过程，但是我个人认为它非常重要。
　　所有的总结，只有带着问题去思考才会有收获，这是复盘。不论我说多少，如果没有过类似的经验，很难有很强的共鸣。我觉得看清一个问题好的方式，是你曾经处在一个问题的两个不同的角色中。
　　总结项目经验教训的目的，在于总结问题、分析原因，避免以后犯同样的错误，而不是追究谁的责任。
　　假设一个需求理解的缺陷，如果在需求阶段发现，修改一下可能只要一个小时，但是如果到了设计完成时发现这个缺陷，因为涉及的人员、文档增多，估计要时间，而如果等到代码都编写完成时才发现这个缺陷，可能需要十天八天了。如果缺陷没被发现，而是直接到了生产系统中呢？这不是工作量的问题了，估计损失难以估计了。在质量管理的理论中，缺陷每延迟一个阶段被发现，修复的代价要乘上十倍。
　　写在后
　　敏捷开发、极限开发等等模型是为了解决需求不明确、时间紧迫情况下的快速迭代，而不是为了从根本上否定研发流程，该设计还是要设计，只是将生命周期进行切分，将过程横向切分为若干个周期。软件开发是一门工程性要求很严谨的学科，让我们坚持严谨的态度、高效的工作方式，打造高可用、高质量的软件产品。