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