编译和调试的效率：想起PM的点滴(2)

    我们在PM中强调的开发效率，一般倾向于指狭义的代码开发的效率。实际上影响开发效率的因素很多，可以说贯穿整个研发流程始末，在其中有两个不容忽视的地方。一是编译的效率，项目规模越大，影响越大；二是调试的效率，你的调试工具和方法有多先进，那么你的开发越高效。

1.  编译效率
    嵌入式开发中，由于开发的平台是X86，而产品的平台是其它CPU，所以使用的是交叉编译工具。一般交叉编译工具是由CPU供应商以SDK的方法提供，而X86平台程序的编译工具使用开源工具，无论哪种情况，编译的脚本和方法都是自行完成。那么，编译方法的选择和编译脚本的优化，直接决定了编译的效率，最直观的指标就是编译时间。百万行代码级及以上的项目规模，全编译的时间不可小视。
    记得曾经有个domain的代码，全编译时间要2h+，这实在让码农们等得蛋疼。后来在一个tools同事的主导下，优化了编译方法和脚本，终于将编译时间压缩至20分钟左右，大家都感觉很爽，不用等那么久了。而且，由于采用了紧凑的make库函数，编译脚本大大精减，脚本行数压缩了10倍左右。这又极有利于编译脚本的维护和再优化。当然，编译出来的elf文件有什么差别和影响，可以用binutils工具包来查看和分析，比如显示目标文件信息的objdump，还有列举目标文件符号的nm，显示elf格式文件内容的readelf等，此处不详述。
    有的时候为了实现智能的自动化编译，比如自动将新的cc文件和head文件加入到项目中并编译，可能会使编译脚本复杂化，甚至影响编译时间。这个时候需要权衡利弊，优先照顾编译效率。

2.  调试效率
    为了统一接口和方便管理，项目中版本的发布一般采用大包+补丁（load+pacth）的方式。编译一个大包的时间比较久，而涉及到每个人的每次调试，可能只针对少数的进程和代码。基于此，如果按照分离原则，采用部分编译的方式，将会大大缩短调试时间。另一方面，软件正常发布的流程一般是下载安装完后会重启系统。如果调试中能够不重启系统，而是直接更新进程，也会加速调试过程。也有采用热补丁技术直接更新进程的，不过那是倾向于软件正式发布方面。
    举一个简单的例子。编译整个domain的可执行程序（executed file）并打包成package花时15分钟，load package的下载及系统重启又花去5分钟，环境重新设置和重拉进程再花去5分钟。然后开始调试，估计用时5分钟。这样一次调试用时25+5=30分钟。一天调试10次，用时300分钟=5小时，加上一些杂事和休息时间，一天工作8个小时消耗得差不多了。如果采用部分编译和直接更新进程的方法，那前面的25分钟将减少到5分钟以内，加上真正调试所花的5分钟，那么一次调试用时5~10分钟。前后相差3~6倍，一天调试10次，用时50~100分钟即1小时左右！而且紧凑的调试更能连续的发现并解决问题，如果加上这个差别，效率提升更为惊人。那么，省下来的3个多小时，你去喝喝咖啡或写写总结吧~~~毕竟大脑的过度单一使用，本身也会降低研发的工作效率。
    为了实现部分编译，开发者应该对make工具和编译脚本有一定的了解，学会简单拆分各进程的编译。同时为了不重启系统而直接更新进程，也要理解平台进程的start/stop机制。还有很多特殊场景下的调试技术，感谢身边的同事让我学到了很多，大大助推不同场景下的调试。当然，为了保证软件的稳定性，最后一次验证时还是要按正常发布的流程进行编译并运行。