如何提高代码质量意识

 

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

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

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

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

 

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

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

 

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

 

主人翁精神

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

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

 

激励机制

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

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

 

问题所有化

大家有没有这样的经历？

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

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

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

 

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

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

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

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

snake1987同学总结的很好：

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

 

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

评论

11 楼 ggokind 2011-05-22  

很欣赏cantellow的观点。
做软件需要一批有着这样精益求精精神的人，并且要有很强的团队意识。

不过说到实际的项目，进度进展和人力缺口大是十分常见的问题。
这是基本规律，也可以说是软件项目的常见困局。所有人都要迈过这道坎。我经历了很多的项目的开发、也了解很多项目的开发情况，进度、人力、规模能够很好匹配的项目基本没有。
怎么办？开发团队要内外兼修，这要看项目经理的水平和团队的潜质了。

内部成员，如果都有cantellow的意识，我想这个团队将会很有战斗力。做产品，需要一种执着和偏执；其实做软件也一样，没有这种执着和偏差，哪来的动力挑战困难？依靠不断的物质激励，不是长久之计。

团队文化、团队价值观非常重要，不是一个两个人可以扭转过来的。正如楼主所言，在一个消极的团队中，一个积极的个体很容易被排斥。团队成员很多当前也是激情满怀，虽不想做出些成绩？但是持续的挫折对于大家的工作态度造成了影响。我们需要做的是，项目经理带领大家做出要一些树立团队信心、激励团队士气的改进，进步虽小但是意义重大。软件工程不需要轰轰烈烈的变革，需要的是持续沉淀的改良，要持续获得小步成功，然后固化，以及以此激发起的团队战斗力。

对外，需要团队领导者能够协调好项目和周边相关人的关系。控制好用户期望、领导的期望、项目范围、项目进度。（说起来简单，做起来不容易啊。）

“唯一不变的就是xx时刻在变”，其实这个“xx”适用与“需求”，也适用于你，适用于我，适用于整个团队。
给你一份信任，看你能否撬动整个团队。
这种事，我干过。当做这种事情的人得到团队的尊重的时候，并且有一群追随你的人的时候，你的团队的文化已经在酝酿着变化了。

希望cantellow可以在1年以后，继续保持当前的冲劲。期待你的团队的变化。

10 楼 cantellow 2011-05-12  

aaronwong_best 写道

我就是因为对项目的寒心而离开现在这个公司的，虽然从感情上我不愿意离开，当程序员与码农是有区别的，写代码要有“it’s my baby”的心态

我去年的年终总结主题是，程序员要有爱...是不是太矫情了点？

9 楼 aaronwong_best 2011-05-12  

我就是因为对项目的寒心而离开现在这个公司的，虽然从感情上我不愿意离开，当程序员与码农是有区别的，写代码要有“it’s my baby”的心态

8 楼 cantellow 2011-05-12  

snake1987 写道

其实这问题看似很复杂，但其实不是那么一回事
最近发现的一些东西
1.决定这个项目的人就是一个注重代码质量的人，项目紧？没事，他顶着，有破窗份子？没事，他处理（或许是通过影响，多数人影响少数人）......

其实我也一直想说，不是每个人都觉得这篇文章只是夸夸而谈理想（或许那些踩这篇文章的人们都是这样的心理吧），觉得现实中根本不会存在，那只是那些乱接项目的小公司的印象，个人的经历决定了他说话的分量，我知道中国也有些公司很注重代码质量（你懂得），但是我不是当事人，也没有权利在这篇文章中细谈。你所说的各种情况让那种把时间来当做借口的人无地自容，但是我不希望这是针对普通的程序员，我希望针对的是中国目前项目经理这一类的人，你们究竟要把行业心态带向何方？

7 楼 snake1987 2011-05-12  

其实这问题看似很复杂，但其实不是那么一回事

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

说了一堆废话，其实说白了就一个问题，“老板”如果很注重这块，那肯定会很完善，这根本不是我们下面这些码农的事情，即使你整个团队都是新的，大家都是很注重代码质量的，“老板”不注重，很快，这个团队也会变成只会产生代码垃圾的码农
而老板注重与否，这也容易诠释为另一个概念：业务。之前的公司，即使你代码很完善很完善，甚至完美，对业务真正有帮助吗？你知道的，几乎没有，最大的好处可能就是当框架有很大的变动时，他手下的人能少纠结几天，仅此而已

再说明白一点（个人认为）：代码质量的好与坏，取决于你生产的软件，软件的功能与质量是否是主要卖点

6 楼 zjshan 2011-05-12  

感同身受，有时候觉得自己有“codereview癖”

5 楼 yzhw 2011-05-12  

做到了很难，人们的想法不同，大部分都以赶进度为理由，说以后再改，可是有几个回去改的？！

4 楼 cantellow 2011-05-12  

tfwin2 写道

简单说说吧，
第一个，主人翁精神，自从我进公司以来，所有自己写的代码或者别人跟我合作开发的项目，都要求代码一定要达到当时的满意程度......
第二个，激励机制，小公司经常遇到的是不顾利润，抢到单子再说，招标文件设计写的天花乱坠，最后全是程序员的任务，设计与调研又不给充足时间，开发一催再催，恨不得今天需求出来......

首先，很感谢你回复了这么多。
对于第一个问题，你的情况跟我很类似，一开始也严格要求自己，现在也不得不考虑团队氛围的因素，人事处理的确是一个很麻烦的事情，我做的太多，别人反而会更加反感，我的感触是作为普通开发人员，尽量找到和你志同道合的人，道不同不相为谋，如果是经理级别的，手中握有生杀大权，那么就比较好办了。
对于第二个问题，我目前还不能感受，因为我刚毕业一年，只在一家公司任职，没有感受到那种小公司接项目天花乱坠的恐怖，我们公司有自己成熟的产品，当然，各有各的好处。
对于第三个问题，感同身受，看来我跟你的是一路人
第四种，时间和质量如何取舍，我一直也为这个很头疼，这就像鱼和熊掌不能兼得，中国整个行业都很浮躁，这个是事实，有改变必须得付出代价。

3 楼 tfwin2 2011-05-11  

简单说说吧，
第一个，主人翁精神，自从我进公司以来，所有自己写的代码或者别人跟我合作开发的项目，都要求代码一定要达到当时的满意程度，即使赶进度，也绝不写烂代码，宁可短期完不成拖一拖。但是有一个问题是，很多时候，你的主人翁精神感动不了别人，一个团队里浑水摸鱼的人会严重拖累你，写的代码质量不高而且用这种人的原话就是完成任务就行，所写的代码根本每次维护都要推倒重写，甚至变量命名都会埋坑，CODEREVIEW成了每天例行修改任务，另外你也没有开人的权利，顶多只有建议的权利，这个时候再有主人翁精神，也容易把自己搞的疲惫，毕竟敲代码是简单的事，人事处理比这个要麻烦的多。
第二个，激励机制，小公司经常遇到的是不顾利润，抢到单子再说，招标文件设计写的天花乱坠，最后全是程序员的任务，设计与调研又不给充足时间，开发一催再催，恨不得今天需求出来，明天项目就出来，然后需求一改再改，验收经常一拖再拖，成本拖到光，说实话，不说激励，工资能按时发都是很庆幸的了，这个时候就看自己的调节水平了，说实话，这种项目至少有一个强处是设计完全是自己把握，对整个开发的思维程度提高是随着任务经历的多少翻倍增长的。
第三个，问题所有化，还是涉及到前两个问题，当项目组里有对技术没什么追求的人，这种分享就是浮云，如果有用，早在这些人的代码REVIEW的时候就已经有所察觉了，让我难以接受的是，居然有程序员以自己是本地人，不需要追求那么高的薪水，只想轻松加愉快的度日子为理由，拒绝回顾自己的代码，因为这是浪费他宝贵的时间。另外一个是，加班时间赶进度赶的连文档都没时间做，何况分享问题。
第四个，破窗效应，很多时候不是程序员不想将所有代码都规范，简捷，有些时候屈从时间与领导，已经写了糟糕的一点代码，厌恶情绪上来的时候，就领导你说什么我就做什么，代码规范就成浮云了，这个时候，全部代码靠项目经理来把握质量，简直就是滑稽，但我接触这行业的很多公司，基本上没有不赶工的，凡是赶工的东西破窗效益你就避免不了，甚至有些项目到了做了一半，主干走了，推倒重做，再做了一半，主干又走了的怪圈，最后企业完全靠忽悠客户生存。业绩比产品质量重要，可以说，在中国，这算是整个行业的悲哀了。

2 楼 cantellow 2011-05-11  

allen_java 写道

意识这个东西完全在于自己的觉悟~~~关键在于自身~~

所以我才说，改变一个人的觉悟，很难！
就像文中所说的破窗效应一样，我希望这篇文章也能影响一些人吧。

1 楼 allen_java 2011-05-11  

意识这个东西完全在于自己的觉悟~~~关键在于自身~~