一提交代码系统就崩溃? 给你8个避免此尴尬的技巧

当一群人作为一个整体同时进行一个程序的编写时，每个个体都会面临两方面的权衡：

●个人部分的实现——你需要保证你负责的代码部分可以正常运行；

● 整体部分的实现——你需要保证你的代码能和其他人的完美融合。

1、及时增减文件

很多程序员都会有这样的经历：提交了个人代码后，还没歇口气就接收到了build失败的报错信息，或者是来自队友气急败坏的邮件，但很快你就能意识到发生了什么——你在代码库中添加了一个文件，但忘记在其他的地方添加依赖或者做相应的修改。

忘记及时进行文件的增减是一个非常常见的错误，防止这种现象出现的方法之一就是允许源码控制插件自动向源代码控制中添加相应的文件。但工具的操作毕竟存在意外风险，作为一个程序员，每次对文件进行增减操作时还是有义务主动对源代码控制做出相应的修改。

2、编译代码

这是一个老生常谈的问题，但有些时候，程序员确实会直接提交没有编译过的代码。这种默认自己代码没有bug的行为非常危险，因为鲜少有人能在编译修正前真正实现代码的Free bug。当然，这种过分自负的人不多，更常见的是另一种近似行为：有些人仅在提交之前进行相应编译——因为他们相信自己的程序大体上不会存在太大问题。事实上这部分人总会被迅速打脸，且为团队带去各种麻烦。

3、保证不会对他人的代码造成干扰

编译问题本质来说就是不对他人的编程进程造成干扰。但干扰他人编程进度的情况并不仅限于编译问题，还包含对经常调用的方法进行修改等，比如出于一些原因你可能会对临时占位符代码进行修改，但在提交时忘记将相应的操作进行恢复，结果就是你的代码可以正常运行、而其他人却要花大量时间处理无数异常报错。

4、更新注释

注释是存在一定时效性的。当你对一些具有详细注释的代码进行修改，如修复一些bug时，必然会使一些注释内容失效，这种情况下，请务必要对相应的注释进行更新。因为如果依旧使用旧的注释，无论是你自己还是其他在未来会对这些代码进行进一步维护的人，都将有可能因此受扰。

如果真的嫌麻烦，那么即使是简单粗暴的对这部分注释进行删除也比任由失效的注释在那误人子弟来得强。不过，既然他人都愿意花费大量时间进行注释的编写，那么你花一点时间对注释进行修改也无可厚非。

5、删除临时代码

很多时候，这件事都无需被专门注意，特别是对那些所谓的极简代码倡导者而言，毕竟在拥有复杂代码调试器、可使用单元测试对简单代码进行覆盖的情况下，临时代码大多时候并不需要。

但这并不代表所有时候，诚然也确实存在一些情况需要我们使用临时代码来满足一些特殊的调试目的，这个时候，请务必记住在提交前对这些临时代码进行清除，因为这些临时代码不但会给程序带来无用的内存消耗，更可能进一步影响产品的最终性能。

6、进行unit test

无论团队是否有unit test组件，作为一个正常人人，总有那么一两次会在没有进行完整测试情况下提交程。而这种行为的背后是认为上述操作不会对总体造成影响的认知，但实际上，很多时候会被证明过于乐观。

7、进行静态分析

也许静态分析并不适用于所有情况，但很多时候却是非常必须的。目前，很多团队已经例行要求运行静态分析，有些则已将静态分析规则放入build当中。

如果你们的团队在这方面有一定的规章制度、甚至有强制执行的要求时，你甚至会在未编译的部分中进行检查。不过即使没有强制要求，如果你手头有相应的标准，也请保证你的代码在提交前能很好的通过静态分析的检测。

8、尽可能的自动化

为了保证最终整体整合的顺利进行，提交前需要注意大量事项。但如今的世界是一个需要频繁提交的世界，若每次提交前都要按照上述列表逐一确认，无疑能把人逼疯。

因此，尽可能让上述过程自动化，然后认真完成剩下的人工部分。