个人技术流程
单元测试
单元测试的完成步骤：
1、设置数据
2、使用被测试类型的功能
3、比较实际结果和预期结果
代码覆盖报告（Code Coverage Report）记录测试代码覆盖率，要达到100%才算测试完整。
好的单元测试标准：
1、单元测试应该在最基本的功能或参数上验证程序的正确性
2、单元测试必须由程序的作者或熟悉程序代码的人来写
3、单元测试过后机器状态保持不变（及时处理临时生成的文件）
4、单元测试的速度要快
5、单元测试应该产生可重复、一致的结果（不推荐单元测试中加入生成随机数，因为很难重复这种错误）
6、独立性：单元测试的运行结果不依赖其他测试（可以通过人为构造数据避开不稳定模块来测试）
7、单元测试应该覆盖所有代码路径（100%代码覆盖率不等同100%的正确性，代码覆盖率处理不了“应该写但没有写”这种错误、处理不了程序运行速度低的问题、处理不了多线程的同步问题。覆盖率包括函数的覆盖、语句的覆盖、分支的覆盖、条件的覆盖）
8、单元测试应该集成到自动测试的框架中（以便每日构建之后及时测试然后处理错误）
9、单元测试必须和产品代码一起保存和维护（以免单元测试滞后造成低效率）
回归测试
一个测试用例在旧版本能通过，但是在新版本测试用例失败，这就是倒退（Regression），这样的倒退可能是由功能的正常变化引起的，那么此时测试用例的基准（Baseline）就要修改。
修复了一个bug后要做一个回归测试（Regression Test），这是为了验证新的代码确实修复了缺陷，同时要验证新的代码有没有破坏模块的现有功能。
有时在项目的最后稳定阶段，需要所有人都参加全面的测试工作，把所有以前发现并修复的bug都找出来一个一个验证，确保没有这些问题没有复发，这就是一个大规模的回归测试。
效能分析工具
主要有两种分析方法：
1、抽样（Sampling）：程序运行时，工具时不时查看程序在运行在哪个位置，据此得到程序运行的大致时间分布，优点是不需要改动程序，运行较快，可以很快找到瓶颈，但是不能得到精确的数据。
2、代码注入：将检测的代码加入函数中精确测量，这一方法的缺点是程序的运行时间会大大加长，注入的代码可能会应该真实程序的运行情况。
一般情况下可以先用抽样的方法找到效能瓶颈所在，然后再对特定的模块用代码注入的方法进行测试。最后找到运行速度慢的位置，定位问题然后改进。注意也要避免不经分析的盲目优化。
个人开发流程Personal Software Process，PSP
软件工程师在接到一个工作后的任务清单：
工程师一般要在需求分析和测试阶段花费很多的时间，测试的时间基本和具体编码时间相当。
软件的设计原则有很多，如单一职责原则（Single Responsibility Principle）、开放-封闭原则（Open-Close Principle），使用这些原则的前提应该是需求的变化，如果不用考虑任何变化，那么多数的设计原则都是累赘。