晚上给单板软件做软件包的时候,发现SVN库上的软件编译不过,找到开发人员一问是否上库,给我的回答是,好像还没有吧。那我说赶紧给我上一下库,我需要这些脚本。

回到电脑面前,一如既往的git svn rebase,一看似乎没有更新啥。再查了一下git svn log,看了一下,时下已经是2月4日,之前那个开发人员的最后一次上库是1月4日。也就是说,一个月以来,他从来没有上库。在紧张的软硬件联调中,每天都会会涉及到代码修改,并且很多修改是反反复复的。开发人员没有自己的一套像样的本地版本管理,经常是xxx.bak,xxx.bak.1,xxx.bak.2这样简单的,浑浊的“版本管理”。美其名曰是”备份“,但一个月以后,我不相信你还能记得住每一个细节。万一,哪天代码突然丢失了,或者服务器崩溃了,磁盘损坏了,怎么办?

同事说,不要对人家要求太高。但我觉得,这并不是一个要求的问题。作为开发者,在开发的同时,也需要思考一下自己的工作。半年前,项目组上库困难,用的是苦逼的ClearCase。在我的再三坚持下,项目组切换成了SVN。换成SVN后,虽然没有git来的方便,但还好学习门槛不是那么高,就像是个自动挡的车,没有太多的难度,踩着油门就可以跑。大家都是本地准备一份代码,然后在服务器上调试好了,然后再手工合入到SVN库上。

其实这也没啥,如果搞定一个问题就上一次库,并且大致写了一下解决了什么问题,那么整个SVN的log价值就很高了。所以,我经常查看svn的log,虽然我只是一个小兵,如果我发现谁经常不写log,或者写的log没任何意义,我会提醒他log的重要性,让他知道对于他自己,以及对于团队的意义。从优秀的开源软件中,可以学到很多的东西,一个重要的原因就在于版本管理日志写的不错。小批量的,精确的上库,能够让后续的问题定位、合入变得更加容易。

例如真的发现一个暂时无法找到原因的问题,可以利用二分法(git也支持),从历史版本中来进行定位。小批量的上库,可以将问题找到,并且能够知道,当时是改了什么问题造成的。少量的代码,也容易定位出具体是什么代码出现了问题。要是,一个月不上库一次,最后上库的时候写了个”联调代码上库“,试问,后续找问题,你确定你能高效的找得到?到时候问一下,为什么这行代码这样改,你能回答的出来么?

切换成SVN后,也有一个好处,我在Linux服务器上就可以使用git svn来进行各种版本管理了。当然,整个团队也只有我一个人再用git,git学习曲线是比较陡峭。但上次我尝试了一下15个人,需要每天合入大量代码的情况下,用git非常高效的完成了整个任务。为了较少学习分支对大家的疑惑,我就一个分支。我给大家总结了标准动作:修改,验证,commit,push,不成功则pull,再编译验证,再push。一旦大家用熟了以后,即便不懂git,也非常完美的搞定了大量代码手工同步的问题。

我用git开发时,每次开发一个特性或者修改一个问题,都拉一个分支出来,并且修正一点,完成一点,就commit一下,等最后开发完毕,通常也就一两天时间,就rebase一下,将svn库上最新的代码搞下来编译验证,没问题后,dcommit到svn上。就这样,几乎没一个功能点,都可以回溯。后续如果出现了问题,还可以利用blame功能,找到问题点。我想,这样一定会比一个月一次上库,来得更高效吧。

我想,对一个合格的、对自己负责的开发人员来讲,在走向”软件工匠“的途中,需要学习一套实用的工具,并且在解决问题中,不断积累、改进工具。当自己的工作变得混乱时,就需要思考一下,是否有工具可以帮忙。当工具没有的时候,制造工具——我想,这就是人和动物的区别吧。

当然,如果你觉得要求过高,则后面你自己加班去吧。