源代码管理的新15条建议

时间:2022-10-12 17:39:11

作者:张克强    作者微博:张克强-敏捷307

建议之1:使用好的配置管理工具,也称为版本控制工具(Version Control), 比如Git,SVN。 请彻底抛弃 VSS,如果是新采用配置管理工具,CVS已经不再是选项。 配置管理工具与版本控制工具可以理解为指的是相同工具。


建议之2:抛弃古老的配置管理三库做法,常说的三库是指开发库(动态库)、受控库和产品库(静态库);做法是开发库->受控库->产品库。 在当年没有强大版本控制工具的“古代”,三库做法是不得不的选择,而在现代版本控制工具(比如CVS,SVN,Git等)的支持下,三库做法变得落伍了。


建议之3:纳入配置管理的文件的名称里不要含有版本号。当前的配置管理工具都有强大的版本控制功能,而只要在文件名中加入版本号,那么相当于放弃工具的版本控制功能,而只是把配置管理工具当成了普通的存储空间,就像共享目录、FTP一样。


建议之4:必须自己提交代码,而不是让别人代劳。有一些团队为了保证代码库的干净,让一个人专门负责审核和提交代码。这并不是一个好习惯。源代码管理并不是为了保持代码的纯净,起码在开发过程中不是这样。它的目的是让团队更频繁的集成各自的工作,当有问题的时候可以回退。


建议之5: 没有进入版本库,它就不存在,“工作进展的唯一标准就是代码进了版本库”。如果坚持执行这一条的话,发现其他的好习惯会随之而来。把任务分成小块所以经常提交代码,更加频繁的更新,集成代码。最重要的是,经常提交代码说明了正在做东西。


建议之6:识别代码配置项和非配置项。非配置项的例子有target目录,.class文件,.*path,.project, .sonar, thumbs,debug文件夹等等,利用ignore功能把非配置项忽略掉。代码配置项要完整,在别处能编译得到相同结果,但是又不干扰别处的工作环境。


建议之7:每个团队应当对代码配置项和非配置项有所说明,不要假设每个团队新人都是代码配置管理达人,小心自以为是的新手加入一些自以为是的垃圾。虽然可以删除,但发现再删除,其本身就是成本。


建议之8:依赖项也需要添加到版本库,或者维护好相应的库,其中最重要的是构件库。 同时也包括图片,编译脚本,数据库脚本,自动化测试等等。


建议之9:整体环境在云计算条件下也是可以成为配置项,环境中最突出的元素是基础数据。当需要多种不同的环境(比如干净环境、仿真环境、某个时间点环境)进行调试、测试的时候,得到配置管理的环境在1分钟之内部署出来,那是多么高效的事情。 测试人员爱死这个了!


建议之10:避免表面CMMI做法-只管理维护一个受控库,展现给评估组和应付各类检查,而实质上,项目团队使用另外的库开展日常工作,只在应付检查时才把强制要求的交付物复制到受控库。 这种做法满足CMMI评估,但实质上没有发挥配置管理的更多好处。古老的三库方案恰恰就是这样子的。


建议之11:了解最普通的多分支开发。多分支开发是最经典最常用的模式,无论是否采用,应当知道多分支是如何玩的:如何拉分支?什么情况下拉分支?如何合并到主干?如何再从主干更新到分支?如何合并到其它分支?什么情况下合并分支后不再维护分支?合并冲突如何解决?


建议之12:守护主干+先锋分支,在主干上修复缺陷以及应急响应,而把新功能放到分支上开发,在分支上测试通过后合并到守护主干,再发新版。这种做法适用于承担大量运维修改的情景。也许多数软件产品属于这种情景。


建议之13:主干开发。主干开发有两种情况,情况1:还没有掌握分支开发,只会主干开发;情况2:充分掌握了分支开发之后,主动选择主干开发。显然的建议是指情况2。主干开发风险高,效率也高,值得码匠们好好研究,实现高质量并且高效的主干开发并不绝对的困难,收益是绝对划算的。


建议之14:单分支开发。单分支开发其实与主干开发没有本质差别,需要采取主干开发的所有方法,日常工作在分支上进行,主干用于应急响应,两者需要频繁的双向同步。 这样的模式是兼有守护主干和主干开发的好处,但显然的复杂度提升了。


建议之15:所有的配置项一起得到基线管理。 主要包括源代码、文档和测试代码,如果不在同一个库中,那么需要专门的基线文件来说明同一基线的对应关系。这不能算建议了,这是配置管理的基本要求了,但往往被违反。



参考材料

程序员开发利器:源代码管理的十条建议

英文原版 http://java.dzone.com/articles/10-commandments-good-source 

中文翻译改写版  http://tech.it168.com/a2012/0307/1321/000001321198.shtml