程序员写完代码之后该做什么？

程序员写完代码之后该做什么？

根据个人多年开发经验，为了有效提升项目代码质量，应该从程序员开始做一些能够提升代码质量的工作。一方面是对bug 的进一步筛查修复，另一方面，也能够对项目进行复盘，优化代码结构，提升代码质量。

下面四个代码测试工作，我个人认为比较重要，而且也是应该是程序员分内的工作。完成一些以下四个方面的工作，能够有效提升代码质量和项目质量。

• 单元测试（unit testing）
• 代码评审（Code review）
• 静态分析（Static program analysis）
• 动态分析（Dynamic program analysis）

下面是对应的详细介绍：

单元测试（unit testing）

单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

注：在本人的工作经验中，这一部分大部分是程序员自己做的。写一写代码块的单元测试，对项目代码的高内聚，低耦合都有好处。尤其是多人合作项目，一定量共享的单元测试脚本，能在相当程度上避免扯皮。

代码评审 （Code review）

注：在本人的工作经验中，这一部分相当的工作是由项目小组组长做的。一般在某一时间片段内（例如一天），对SVN或者git上提交的所有的代码变更，进行审查。这样可以让小组长能掌握组内所有成员的代码进度情况和质量情况。而且在提交的时候，能够有效的形成组长和组员的良性交流和互动，让组长能够及时的了解组员最近一个时间段内代码编写情况。在沟通过程中，也能对小组成员的代码质量完成点评，对组员的代码质量提升也很有帮助。

另外的代码审查方式有：结对编程（两人互相完成code review）。

静态分析（Static program analysis)

静态程序分析是对没有实际执行程序的计算机软件进行分析。(对执行程序进行的分析称为动态分析)。在大多数情况下，分析是在源代码的某个版本上执行的，在其他情况下，则是某种形式的对象代码。
这个术语通常应用于由自动化工具执行的分析，而人工分析被称为程序理解、程序理解或代码复查。软件检查和软件演练也用于后一种情况。

注：以本人的项目经验，静态程序分析一般就是指自动化工具执行的分析。通过Sonar oclint 等脚本自动化完成对代码质量的分析。一般是项目组或者整个个公司，共用一套分析工具，例如使用 jenkins+Sonar构建统一的代码质量管理平台，能够完成项目的自动集成和代码质量分析，并完成相关的代码质量报告生成。

下图就是Sonar分析代码质量报告的图例：

Sonar是一个用于代码质量管理的开源平台，用于管理Java源代码的质量。通过插件机制，Sonar 可以集成不同的测试工具，代码分析工具，以及持续集成工具，比如pmd-cpd、checkstyle、findbugs、Jenkins。通过不同的插件对这些结果进行再加工处理，通过量化的方式度量代码质量的变化，从而可以方便地对不同规模和种类的工程进行代码质量管理。同时 Sonar 还对大量的持续集成工具提供了接口支持，可以很方便地在持续集成中使用 Sonar。此外，Sonar 的插件还可以对 Java 以外的其他编程语言提供支持，对国际化以及报告文档化也有良好的支持。

动态分析（Dynamic program analysis)

动态程序分析是计算机软件的分析，它是通过在一个真实的或虚拟的处理器上执行程序来执行的。为了使动态程序分析更有效，目标程序必须通过足够的测试输入来执行，以产生有趣的行为。使用软件测试措施，例如代码覆盖率，有助于确保已经观察到程序的一系列可能行为的适当部分。此外，必须注意尽量减少仪器对目标程序的执行(包括时间属性)的影响。不充分的测试可能导致灾难性的故障，类似于Ariane 5火箭的首次飞行，在这种情况下，动态执行错误(运行时错误)导致了车辆的破坏。
动态分析与静态测试相反。单元测试、集成测试、系统测试和验收测试使用动态测试。

注：动态分析要比静态分析更加依赖于工具，例如在macOS/iOS 编程中，使用Xcode 可以对整个程序运行时的状态进行监控调试。而且可以限定外部环境，例如变更定位的经纬度，变更不同的网络状态（高速网络，拥塞网络等），这样能够让程序员更加便捷的了解程序的运行状态，从而对程序运行的相应情况更加了解。

下图是Xcode 对一个iOS 程序的运行时的监控界面：