如何提高代码质量意识

13年前

在接下来的文章里我会讲到如何提高代码质量,会讲到一系列措施和工具,比如codereview、重构、findbugs、敏捷等等,这些东西对代码质量非常有用,但取决你是否行动了,你和你的团队是否具有强烈的代码质量意识,如果没有强烈的代码质量意识,这一切就像是在看我这个小丑在上演一场杯具,过往云烟,看过了就忘记了。学习一项技术很容易,但是学习一种意识,或者说改变一个人的习惯,很难!

诚然,意识和习惯是自身的觉悟,要改变的确很难,更何况众口难调,那我为什么要写这篇文章呢?我自己多少也有一些迷茫,大的环境是浮躁的,要改变就要付出代价。

============================================================================

当你跟别人合租房子时,你会主动把厨房打扫干净吗?如果是你自己的房子呢?

 

当你要写一份给自己看的心得是,你会把它写得很漂亮很有深度吗?如果早知道这份心得会抄送给全部门看呢?


当你在修复一个
bug时,你是否会首先确定这个bug的来源,如果是自己发现的?能解决就解决,不能解决或者太麻烦就这样吧,反正别人也没发现;如果是QA部门发现的?尽量吧,实在不行就推迟解决;如果是客户反映的,而且被领导盯着的?全力以赴,加班加点的干。

 

当进公司第一天写代码,是否有种要把自己的代码打造成完美的冲动?是不是敲入的第一字符不是代码而是自己的名字?是不是连一个变量名,怎么写注释都要纠结半天?不过一年之后呢?当你团队没有任何质量改进时,你是否还会这样严格要求自己?

 

主人翁精神

当你的努力能立马换来客户的赞扬,老板的赏识,更重要的是产品质量的日趋稳定,我们是不是有很大的成就感?我们是不是为自己的负责的产品或项目更加感到骄傲和自豪,我们需要这样的人,这种人会主动去干一些事情,最大的发挥程序员的生产力和创造力。

拥有主人翁精神的人会把自己发现的问题及时解决掉,但是要树立这种精神,会牵扯很多管理方面的科学,小而精悍的团队正是主人翁精神最大的受益者,它们会把自己的产品和项目上升到人生的高度,它们能立马看到它们负责的产品改进的效益,这是一个持续改进过程,良性的循环。

 

激励机制

我坚信,程序员是一个伟大的职业,它们在代码的世界里任意驰骋,构建属于自己的罗浮宫,我不知道有多少人认为程序员最大的成就感来源于它所负责的软件被用户所认可、被广泛的使用,但至少我是如此。

程序员希望被认可,不是通过悦耳动听的歌声,不是通过优美的诗歌,而是通过通宵达旦坐在电脑边日夜奋战编出来的代码,我们需要通过codereview得到同事和老板的认可,需要通过可运行的程序得到客户的赞扬,试问,如果连这些基本的途径都不具备,我们还有什么方式来表达我们心中的成就感?第一次挫败,第二次不会再像第一次那么努力和认真了,如果第二次也挫败,那么第三次,我们写代码还有什么期待?

 

问题所有化

大家有没有这样的经历?

发现有人早已经解决相同的bug;某些bug再次复现时,自己已经忘记了当初是怎么解决的;我们依赖其他的团队成果,他们改变了实现方式,但并未告知我们,等到QA部门发现问题并费了半天时间追查到底是什么原因时,才发现是这个原因。

每次我发现一个很诡异很复杂很有趣的问题并解决之后,就会发邮件全组告知,还可以在周例会上一起讨论更加完美的解决方法,我之所以这样做,一方面是让大家有个印象,另一方面是留一个记录,更重要的是,在这个过程中,大家一起讨论,一起出谋划策,不但彻底解决了这个问题,而且也提高了团队整体对项目代码的熟悉程度。

其实,最最重要的原因是,每当我觉得这就够了,我做的已经够多了,准备忍耐着不共享不舒服的煎熬时,我会对自己说,你要写一份心得发给全组哦,更加完美的解决这个问题吧。

 

团队代码质量氛围,破窗效应

相信大家小时候都发出过“豪言壮志”什么的吧,说什么要改变世界,可是绝大多数都是被世界所改变了。不是我们不坚持,只是长大之后才发现当时的幼稚,也发现了,人和社会是分不开的,我们经常在受别人的影响,也经常无意中影响着别人,特别是我们程序员。

我时常在想,如果从一开始,代码风格命名规则是严格统一的、每个字符都是通过了codereview的、单元测试覆盖率是100%的,谁还敢不按规范出牌?写bad code很容易,写good code就很难,只要有一个人不按规范出牌,规律就会向着破窗效应发展。

========================================================================

snake1987同学总结的很好:

1.决定这个项目的人就是一个注重代码质量的人,项目紧?没事,他顶着,有破窗份子?没事,他处理(或许是通过影响,多数人影响少数人)
2.在1的前提下有三种情况
a.新项目,从0开始,那太简单了,一切按正规来办
b.已经进行了一段时间的项目,这也简单,重构,每个人都要参与
c.如果是已经维护了很久的项目呢?外企过来的同事说了一个很好的例子:外聘,该外企请了几个很专业的人来把代码一点点地重构了,然后带着以前那伙人扎扎实实培训了一通

 

希望那些以时间为借口但对软件质量和代码质量又要求很高的管理者或者项目经理应该好好看看这段话。

转自:http://cantellow.iteye.com/blog/1040261