程序员提交代码的几个好习惯

April 18, 2017

技术管理

提交代码是每个程序员日常工作中的一个重要事情,但是往往又不受重视。一些良好的习惯可以帮助你提高效率。

代码版本管理工具

作为程序员,除了写代码本身这个主技能外,代码版本管理工具的使用是一个必要的辅助技能点,应该说没有哪个程序员不会用,只是用得好不好,溜不溜而已。既然是辅助技能,所以一般不用点满,够用就行。

我从 08 年参加工作的第一天,就开始使用代码版本管理工具了,之前根本没听说过。后来在不同的公司接触了不同的代码版本管理工具。有 CVS,SVN,Git。这些工具各有优缺点,这里不展开讨论,因为我用的也不多,辅助技能嘛。

当前 Git 比较流行,不代表 Git 就是比其他好。跟玩户外一样,玩户外就有这么一种人,唯装备论,他们非常专注于攀比装备的等级,品牌。难道没有冲锋衣就没资格爬山了吗,爬个香山,穿一线品牌的比穿国产品牌能爬出啥优越感?好装备就是比差装备好,有装备就是比没装备好,但是得看场景。

当然,工具如果妨碍了开发工作,那么是应该换换了。

常规协同开发

代码版本管理工具的重要功能之一就是协同工作。当开发团队大于等于 2 个人的时候,就必须使用代码版本管理工具了,这一点没有啥好讨论的。

代码版本管理工具的另外一个重要功能是记忆功能。记忆功能可以帮助我们分析引入 bug 的代码,并且可以“滚回之前的版本”。

工具是死的,人是活的。有些团队人不多,项目不复杂,但是查找起问题来特别费劲,不能很轻松的确定引入问题的版本和影响范围,有些团队人很多,项目也比较复杂,但是却能很快速的定位到问题,找到引入的版本,找到改动内容,给出影响范围。造成这些区别,一定程度上,是使用工具的人的习惯问题。

代码提交的习惯

一次代码提交只完成一件事情。

首先,你需要养成一个习惯,一次代码提交只完成一件事情。这和咱们平时讲的程序设计的单一职责原则相似。代码千万不能攒一大推再提交。比如说修改 bug,我习惯于每一个 bug 修复都是一次单独的提交。bug 一个一个改 ,改完一个验证一个,验证完一个提交一个。

如果是在做功能的时候,不是说等整个功能都做完了再提交,而是可以把一个大的功能分解成多个小功能,把一个大的任务分解成多个小里程碑,每完成一个小单元就提交一次。这样,我总是觉得我的工作是一点一点往前推进的。我之前也有攒一大堆的习惯,但是有几次碰见这样的情况,功能做了一半了,发现思路有些问题,但也不是全都错了,怎么办?不好办啊,全回退回去舍不得啊,毕竟还有好些代码是对的,他们是无辜的啊。回退部分?不好找了,改动太多了,而且很分散。最后只能一行一行的过,还容易出错。

吸取这个教训,后来我都是差不多完成一个小功能,小模块,小里程碑,我就提交一次。用 Git 的话,我就做一次本地的 commit,这样再遇到之前的问题的时候,很容易撤销当前的修改,也很容易回退到之前的版本。

不提交不相关代码

另外一个习惯是,不提交不相关代码。经常有人把一些无关的代码改动也都提交到代码仓库中了,比如一些日志打印,一些调试代码,一些增加了又被注释掉的代码,一些格式化后引起变化的代码。

这是一个常见的案例。你花了几天时间,反复调试一个很复杂的问题,来来回回修改了超过十个文件,增加了超过一百行日志打印,最终找到了一行代码里有个边界判断错误,调试成功了,大功告成,提交代码。你应该是只提交一行代码还是应该提交十个文件的代码?

如果你实在割舍不下这些调试过程中的日志,你可以对这些日志做一次单独的提交。一个提交修复 bug,一个提交打印日志。不管是日后自己查看,还是别人review,都非常清晰地知道你做了什么。

这个也适用于格式化代码。当年我刚进 R 公司的时候,有次我新增了一个代码文件,提交前又忘记格式化代码了,提交后想起来了。我偷偷问我的 Leader,是不是下次提交的时候顺便把这个代码格式化一起提交了。我的 Leader 说,绝对不允许这样做,你单独提交一次对这个代码的格式化。

所以,每次提交代码的时候,要有习惯自己 review 一下代码,一行一行过,把没必要的改动撤销回去。一行一行 review,如果你自己都不喜欢 review 自己的代码了,你也不会好好 review 别人的代码,而如果有人认真 review 你的代码,你应该感到愧疚。

及时提交代码

如果你有第一个习惯,那么及时提交代码肯定是顺理成章的事情了。每当你完成一个小的完整的单元的时候,都会习惯性的提交代码。

程序员是非常害怕思路被打断的,但是这又是很难避免的。每次在被打断回来的时候,我会先看一眼代码的变更,看看我刚才都做了些什么改动,回忆一下,接下来我将要什么。

有时候也碰见过这样的人,代码在自己本地放了好几天,最后再一起提交。这样有两个风险,一是,长时间没同步,你的代码可能已经和别人不在一个频道上了,特别是团队成员比较多的项目,最后处理冲突代码肯定是非常痛苦的。另外一个风险是,万一你的电脑坏了,你这几天的努力都废了,概率很小,但是我确实碰见过。

--- EOF ---

添加新评论