代码管理

    团队开发时，最后做代码整合时，对于各个模块公共的部分，难度会非常大。大家马上会想到在项目的开始就使用代码管理工具，在同一个地方做修改，如果有问题很快就可以发现，而当时的修改代价是最少的。实际开发中有没有这样做呢？我所知道有这样去做的是少之又少。
    以前在华为时，他们用的notes确实是个好东西，对于项目管理确实是事半功倍，我们先不说它在项目沟通和bug管理方式的优势，我们只注意它在代码管理方面。刚进华为的时候，做LMT维护终端，那时那是个比较完善的软件了。所以基本上都是改BUG，当时修改完BUG，要把代码合入到notes中，是需要经过各种检查的，所以合入之后，很少会出现问题。不然像那么大的系统，肯定会出现很多的问题，由于没有经过全部检验的代码，是不能合入到代码库的，所以每次要出版本，直接从代码库取代码就可以了，不会引入什么新问题。这是任何软件公司都可以借鉴的。不过后来在做java版本的LMT时，就没这么幸运了，那时大家都是在各自的机子上做开发，所以后来到后面整合也出现混乱。可见再好的流程，运作时不去执行还是没有效果的。
    我有做过整个项目开发过程中的代码都是经过代码管理的，只有在泰又时做java版本的CAD和建物测量两个项目。那时使用JBuilder做开发工具，管理代码很是方便，所以在开发的过程中，遇到再大的困难也是坚持用下去，后来证实了这样虽然在开发的过程中会出现些问题。比如，公共部分的代码互相影响。但是采用这个方法，实际效果除会减少开发的时间之外，还有很多其它的优点，可以减少不少的代码，结构有问题的在开发的时候就会发现了。而且在开发进行的过程中，有相同相似的功能，能及时的发现，这有利于提取公用函数，提高代码的复用性和减少重复代码。很让人遗憾的是，我负责的最寄希望的那个项目《测量课业务软体》没有采用这种方法，开发时为了提高代码复用性，做了很多额外功。
    这次做碟中碟的项目（由于公司的一些限制，没办法在公司使用代码管理工具），在代码整合时，简直是个恶梦。我向别人提供代码时，都会完整的找出新增和修改的文件，然后写一份简单的修改文件说明。其它人整合代码时，只要按说明中的方式去添加，很容易就完成了。可是这次团队中的成员向我提供代码时，老是丢东丢西的，添加一次要找他们好几次拿落下的文件。我也要求他们写简易说明，可是一个个答应的很快，可是还是发一些丢三落四的文件过来，单单邮件就收了几十封，还是一句话，做事要规范，不然花费更多的时间。后来我让他们自己来合BUG，唉，这就出现更为有趣的问题，出现问题，在我的工程目录里面做了修改，出去的时候没有把它修改到自己的工程中，也每次过来合代码的时候，都是懒得去比较，直接用自己的代码覆盖整合工程里的文件，同样的问题一次次的出现。唉，一件事，第一次是不知道做错了，第二次是不小心做错了，第三次就是故意做错了，而他们老是一错再错，我都不知道有什么办法来提高他们了。
    结论：做项目的时候，不管项目多小，功能多简单，项目时间多紧。只要没有火烧眉毛，就该使用代码管理工具对代码进行统一管理。不过有一点很重要，就是管理工具足够好用，用起来足够方便，不然肯定会产生逆反心理的。平常人家都说代码是在晚上回去的时候合进去的，我的建议是在第二天进行新的开发之前合进去，不然你做错了，第二天又缺勤，完了，影响到别人就不知道怎么办了，往往就得牺牲自己的休假时间了。这样还有一个好处，早上来的时候，大家都在一起合代码，这样有冲突的地方大家都在，很快就能解决，如果晚上合的话，有问题，造成相冲突的人回去了，当时就没办法解决。还有合的代码一定是测试过的安全的代码，不要每次合入的代码都是有一堆的问题，那别人取版本不就每次都载些乱七八遭的代码下来。对于代码管理，要写一份使用说明，指导成员进行代码管理。像上面说的，人都是很懒的，不给他一个规范，等下做着做着就变味了。