源代码管理是项目管理的一个重头戏

 　   北大青鸟武汉宏鹏光谷校区：源代码管理是项目管理的一个重头戏

       现在很多管理者觉得业务才是必要的，开发的人不值钱，代码推到了可以重来，加加班，没有什么大不了的，对于技术不重视，对于源代码的管理就更加的忽略了，只有出现了问题，才说这说那的。

　　我觉得一个较好的代码风格，代码习惯，代码结构，代码管理工具，代码管理流程对于一个软件项目的成功尤为重要，对于一个产品项目，甚至是互联网项目来说，那就甚是重要了。至少不比业务次要，试想如果基础没有打好，业务再吹嘘也是徒劳。

　　当然了，业务也不能疏忽，我是觉得大家都是为了共同的目标，共同做事，分工不同，不应该分主次，厚此薄彼的。

　　代码管理可以从下面几方面入手来进行改进。

　　1.代码规范

　　根据自己公司和项目的情况，制定一个大概的代码规范，例如：前缀，后缀，方法的命名，变量的命名，必要的注释等等。这样不是为了框死每个人，而是为了大家好交流，减少无用沟通，使得整个开发过程更愉快，大家更容易进步，集中精力做事。但也不要太死板，造成大家无所适从。

　　刚开始有些人会不习惯，通过后面的 review，改掉不好的习惯，这样慢慢就会好起来了。

　　2.源码管理工具

　　找一款适合项目和团队的代码管理工具，充分使用源代码管理工具中的主干、分支及合并功能。这方面严重不微软的VSS，个人觉得太不能满足要求了。中心服务器方式的svn或者是cvs，甚至是分布式的git就更好了。

　　3.code review

　　代码的review很重要。更好可以找一个专人或者几个专人来做code review，重点模块、重点人的代码还是需要仔细review的。前面说过了，通过review，可以慢慢的调整整体的代码可读性和健壮性，还有代码的结构。

　　4.其他的方面就请大家补充了。哈哈!!!

　　接下来我说一下代码管理中关于主干，分支，合并的一些概念和使用场景。

　　1.多人同一文件同一时间的编辑需求

　　有一个文件，A正在编辑里面的一个方法methodA，这时候同时需要维护文件的methodB。

　　一种做法是A放下手上的活，赶紧来完成，但是完成后又不敢checkin，因为刚才有未完成的methodA，恐怕编译不过，就算编译通过了，可是功能没有测试，不敢保证methodA是正确的，头大了。

　　还有一种做法是A写完手头的再来维护，但是等不及了，就需要并行开发，头大了。

　　还有一种做法是由B来完成这次维护，但是文件被A签出，如果使用VSS的默认模式，是不支持多人签出的，而且VSS也不提倡多人签出，头大了。

　　并行开发，也是为了提高效率，加快速度，缩小迭代周期。

　　这时候就需要主干，分支的概念，或者允许多人签出，编辑完成之后，再进行合并。维护的人，就可以搞一个分支，去维护分支中的同一个文件，待后面再合并回来。

　　2.模块的开发和维护并行

　　使用VSS管理源代码，配置不允许多人checkout，模块1正在由B进行修改，B边开发边checkin，但是这些checkin的没有经过测试，这时候C需要维护模块2，模块1是模块2的后续处理，可是C获取新的时候，同时获取了正在修改的模块1的代码，是有点问题的，虽然可以编译通过，但是功能是错误的，就算C修改完了模块2也不能进行测试，因为B本地的模块1的代码不能正常运行，导致后续的模块2没有办法工作。

　　你也不能不让每个人checkin，或者只让可以测试的才checkin，或者checkout也不能，只能checkout测试没有问题的，你会发现，有了这些约束，就没有办法工作了。局面就是那个人都不敢checkin，那个人也不敢checkout。这样也不行啊。

　　究其原因，就是因为只有一个主干，大家都是在主干上面开发，导致一个人的修改对其他所有人都有影响，这就很可怕了，尤其是项目做得复杂了，时间长了，人员多了，问题就会更多。

　　这时候很需要主、分支概念，我觉得应该是有一个主干，然后每个人都有自己的一个分支，这样就可以较好的避免上面的问题。在自己的分支上进行开发，可以不获取别人修改但是又没有测试通过的代码。同时也支持，而且也提倡大家常常的checkin。而且构建可以构建主干的代码，不会因为大家的重构而影响主干的功能。因为重构之后可能还没有充分测试，但是又checkin了重构的代码。

　　这方面觉得git做的就更加好了，git是分布式的，本地也有一个git库，就是本地也存在一个代码管理库，也有版本管理的概念，不用时时联网才能提交或者获取。可以尽情的在本地建立版本管理，等到联网之后再提交或者更新，而且不用担心源代码管理器的完蛋导致所有版本都消失的恶果。

　　而且git的另外一个好处是-速度，因为他是打包上传，不是单个文件的上传，所以速度更快。

　　缺点就是git提倡完的开源，对于浏览和修改没有做任何的控制，不过这方面有一些第三方的方案可以借鉴，例如gitosis等等。估计也是因为git的完开源，才使得它更需要本地的版本库，才使得它更强大吧。

　　结论

　　当然了，工具毕竟是工具，它不是的，不能什么都交给它，希望它帮我们做好一切，那是不切实际的。

　　但是不可否认，一个好的工具，已经对于工具的正确使用，可以提高我们的效率，可以提高做事的愉悦程度，可以加快我们的进度。