记一次千人大项目的感受

最近有幸参与了一个千人的大项目，深刻感受到了项目中存在的一些问题，做如下的记录。也希望大家能够讨论一下自己项目中面临的问题以及更好的解决问题方法。

1，测试用例的编写没有得到足够的重视

测试用例包括FT,UT以及ST。FT和UT都是有开发人员来进行编写的,ST由测试人员来进行编写测试。当然由于项目中实行的是敏捷管理方式,每个团队还包含了专职的QA来进行初步的ST测试。但是团队中的测试更多的是聚焦于功能方面的,所有上述工作完成之后,代码合入受控版本,会交由测试部门再进行测试,包括,功能,性能,可靠性,稳定性等方面,测试更加的细致。由于我所在的是开发部门,更多的体会是FT以及UT方面。首先测试工具是基于google的开源测试框架打造的,结合项目的具体特点,封装成为符合项目开发人员习惯理解方式来进行FT的编写。但实际开发过程中开发人员没有认真编写测试用例,开发者似乎更加更加热衷于实现某一个功能。造成这种现象的原因很多,例如管理方面,从上至下没有把UT,FT放在一个非常重要的位置,开发者往往只是为了FT和UT的覆盖率要求编写用例,为了赶进度,实现某个特性忽视了FT。这样就使得功能测试并不完备,为了凑覆盖率而编写和而不是验证某个功能去编写。有些问题隐藏的很深,FT能够方便的发现,ST则未必。我觉得FT的用例应该结合方案进较为详细的设计,测试用例至少要和功能开发发上同等的时间,甚至更多,因此TDD其实是一种很好的方法。

2,代码强推操作

项目中使用gerrit进行代码评审的工作,底层的版本控制是基于git的。当然git作为时下最为流行的版本控制系统,使用起来还是非常的方便的。本篇不是分析gerrit的优缺点,而是觉得即使最好的工具,如果在执行的过程中,不能够有效的控制人为的因素,那么对于版本的控制管理,也将是极为失败。因为在项目开发过程中发现,总有人会有强推代码的需求,即不通过CI上的各种验证流程,直接将代码入库。虽然这种强推的权限只是掌握在极少数的手中,但事实上强推的人总能够找到各种各样的理由,因此会不断的有强推。那么产生的问题也是显而易见的。首先,最严重的就是可能导致CI编译出现问题,对于大项目来说,这会影响很多人，因为这种级别的项目每天的CI执行会非常的频繁;其次,强推规避了pclint,覆盖率,复杂度,kw等各种检查流程。以pclint为例,强推代码中如果出现pclint问题,将会在下一次同样修改该文件的commit中暴露出来,这会增加下一次commit提交人的工作量,对于他也是不公平的,而且容易滋生怨言;还有就是破窗理论所述的那样,这种行为如果管理层不明确的进行约束和制止,会导致越来越多的人效仿,这将是一个严重的恶性循环。

3,代码走查问题

其实这个问题主要是走查人的问题,走查人对于代码质量的一个态度直接决定了版本库中代码的质量。实际的执行过程中发现,代码走查流于形式主义。走查代码最基本的是功能流程方面,这个一般人多的情况下都会考虑的比较周全，但是关于代码本身,例如变量的初始化,命名,可读性,注释,一些异常的统计等关注较少,即使注意到了,往往碍于同事之间的面子,也都同意入库了。我觉得代码走查的环节还是很重要的,因为通过我们不断的对于代码细节的推敲,库中所呈现的代码也是优秀的,这也会直接对后续的开发者产生积极的影响，因此不要轻易的code review +2,事实上在这个方面我也挺纠结。现实中我所看到的就是混乱不堪的代码导致后续的维护人员继续生产劣质的代码,又是破窗理论的再次验证。

4,人员素质参差不齐,测试返工憋成内伤

当管理者意识到可能在项目的截止日期前无法完成项目的时候,会做什么。其实你可能也会有体会,就是增加人力,加班等等,我就是在这种情况下加入项目的,这在我国的软件行业真是屡见不鲜了。无论是通过招聘还是不同部门之间的借调增加的人手都会存在这样一个问题,就是对于项目的业务不是很熟悉。同时每个人的专业知识,人员素质参差不齐。我当时参与的是一个具有庞大业务场景的软件,需要非常专业的业务知识。但是对于我这样参与进来的新人来说,仅仅经过两三周的培训,就投入了项目的开发之中。姑且不论代码质量,可能有的业务场景考虑的就不全面。因此在这种情况下生产的代码可想而知。已经被证明的是,后期产生的bug导致的不断修改所按入的人力非常的恐怖。而且代码质量真的会严重影响优秀程序员的身心健康。

5,真正开发者不需要那么多

如果领导按照他的想法安排了很多人,我倒是同意有的人的观点就是,只让少部分的人有提交代码的权限。其他身下剩下的人可以安排一些其他的工作,比如结对编程,一方面带带新人,做一下备份;另一方面也能够帮助开发者提提意见,毕竟旁观者清。还有的人可以去设辅助计ST的用例,编写一些说明手册等。因为当能够提交代码权限的人变多的时候,代码的质量是得不到保证的，这一点在4中已经验证。

6,部门团队间相互扯皮的情况多

当项目人员变多之后,尤其是跨部门的项目,相互之间推委责任的情况时有发生。因为每个人,每个部门都有考核,考核的依据可能就是每个人和部门引入的故障数量。因此呢,当出现问题的时候,每个人想到的不是如何解决问题,而是先尽可能的甩锅。其实把皮球被踢来踢去的过程的时间可能大于问题解决的时间。因此项目如何在制度上让员工在出现问题的时候第一时间想的是去解决问题还是蛮关键的。其实在公司工作这几年,我的感受是没有人愿意主动引入故障,都是希望项目能够顺利进行下去，因此以故障数量作为考核并不明智。还有就是测试部门和开发部门的长期对立。测试部以发现故障的数量为考核目标,这激励了测试人员去发现问题。但是由于在实际的执行过程中,测试部发现问题后并没有和特性开发人员进行充分的沟通,直接把现象扔过来,让开发人员去定位,有的时候可能是测试人员对于特性了解不充分,有的时候可能是别的特性引起的，开发人员的时间也是宝贵的,久而久之也会引起开发人员的反感。因此如何协调开发人员和测试人员的关系呢。

7,团队的氛围很重要

大的项目也是由一个个小的团队组成的,破窗理论前面已经验证了团队氛围的重要性,为了避免恶性的循环。团队的Leader是非常重要的。所谓兵熊熊一个,将熊熊一窝。首先团队的Leader要做到公平,能够准确的识别每个人的贡献,而不是加班时间。其次在一些小问题上,Leader要带头整改,树立团队人员的责任心。如果得过且过,然后发现问题也不想改正,小问题的不断积累最终成为大问题。最后,团队的Leader还是要多和团队成员交流,了解彼此之间的诉求和想法。

其实每个项目都会有这样或者那样的问题，这个时候管理者就会很关键。真正的发现问题并且思考解决问题其实值得每一个项目管理者重视。为了赶进度就增加人力，加班，强推代码也许暂时为自己推脱了责任，即使完成不了也可以和上层交代，但是于项目长远来说则是后患无穷。

本文为CSDN村中少年原创文章，转载记得加上小尾巴偶，博主链接 这里 。

作者：村中少年

来源：CSDN

原文：https://blog.csdn.net/javajiawei/article/details/89407192