谈谈代码质量

0 反思

代码质量永远是绕不过去的一个坎,如今公司人员扩招,更多进来的是初级工程师,慢慢意识到一个严重的问题,质量在下降,近处于失控的状态。
终于意识到一个是不能再采用原来的言传身教的模式去发展团队,二是绝对不能靠员工自觉性主动性去约束自己。
但是好像很悲观,提高代码质量历来是一个很难的东西,但我坚信这其中一定是有一些捷径是可以走的。今年一年也写了一年的代码了,可是我觉得我的代码质量根本没有提高,所有今天借这个机会反思自己这一年的工作,也给假期的工作做一个安排。

1 总结历史问题

  • 从git的提交记录中去总结
    在commit次数比较多的天数(一般都是deadline前或者测试阶段)中选十条commit去看看这些更改都是因为什么做的更改
  • 从服务器的err log中去总结
    把errlog 中无用的error给删掉,然后分类汇总
  • 从redmine中测试提的bug角度去总结
    是产品文档没写清楚还是代码的边界条件没理清楚
  • 从沟通成本的角度去总结
    因为什么出现了团队的沟通,时间一般都花在哪里,比如对接口的阶段问题比较多

2 再次思考这些问题

  • 把问题分类
    一类是代码的问题,一类是数据的问题,一类应该是workflow的问题
  • 每天都在忙着提交代码,这些代码都是因为什么原因要补上去的?
  • 每次大量时间花费在了复原bug上,能不能不需要完全复原数据环境,把bug的描述能不能在日志中体现详细一点
  • 都在说脏数据的问题,如何来检测数据是不是脏的呢?

3 解决这些问题

  • 1 善用工具(jenkins,gerrit)
    一类是部署相关软件,还有一类是IDE工具
  • 2 善于统计,每天的工作都要做什么
  • 3 善用脚本
  • 4 多用hook
  • 5 强调work_flow
  • 6 善于抽象
  • 7 如果把现在项目的代码减少到原来的10分之一,能不能做到
  • 8 树立一个好的coding_style,要多看优秀的代码是怎样的

4 反思以上的解决问题的方式能不能解决

我觉得最好的状态是 团队不要沟通,所有硬性规定,没有道理可讲,保证项目可控,尽量减少开会时间。

5 你的目标是什么

  • 减少沟通
  • 程序守时
  • 减少bug

6 别人怎么说

  • Coding standard + BDD/TDD + Good version control workflow + Code Review
  • 这个我觉着关键还是在于团队负责人这里,负责人可以先制定一个coding style,参考google的coding style https://code.google.com/p/google-styleguide/ 。有了统一的风格就比较好控制整体的编程质量。然后定期,团队内部做技术分享。再者么,定期做小范围的重构。负责人一定定期要做code review。只要团队内部整体上逐渐形成一种氛围,团队成员自然而然的会提高么。
  • 可以尝试code review, 如果原有的代码管理系统就是git,gerrit是一个不错的选择
  • 这类问题负责人不出面压根就没出头之日.码农每天bug一大堆哪有时间给你整这些东西.产品的,测试的都盯着你,没辙.质量慢慢降低.终于等到不得已而为之的时候再开整吧.上面关注的可不是你的代码有多优秀.功能需求全部ok成功80%了.最后ANR啊。Crash啊一个一个解决掉阿弥陀佛了就
  • 个人看法:
  1. 个人职业操守。部分人的节操和意识就那个层次,意识不到问题所在,或是即使意识到也懒得改进。
  2. 团队氛围。周围人都这么干,随大流吧。
  3. 公司的考核原则影响。代码写得好坏与否,反正不会太影响考核,特别是在大公司,会说话比会写优质的代码重要多了(无可奈何的认同);另外有人会认为与其花点时间写好代码,还不如把时间投入在一些其他的项目中,年度考核、晋级时还有东西可讲,短期上看,貌似ROI更可观。
  • 持续集成 SonarQube 代码质量管理系统 https://www.v2ex.com/t/227687

7 普遍的坏味道

  • 意义不明
    能力差的程序员容易写出意义不明的代码,他们不知道自己究竟在做什么.
  • 不说人话
    很多程序员喜欢简单的东西:简单的函数名、简单的变量名、代码里翻来覆去只用那么几个单词命名;能缩写就缩写、能省略就省略、能合并就合并。这类人写出来的代码里充斥着各种g/s/gos/of/mss之类的全世界没人懂的缩写,或者一长串不知道在做什么的连续调用。

还有很多程序员喜欢复杂,各种宏定义、位运算之类写的天花乱坠,生怕代码让别人一下子看懂了会显得自己水平不够。

简单的说,他们的代码是写给机器的,不是给人看的。

  • 不恰当的组织
    不恰当的组织是高级一些的烂代码,程序员在写过一些代码之后,有了基本的代码风格,但是对于规模大一些的工程的掌控能力不够,不知道代码应该如何解耦、分层和组织。

这种反模式的现象是经常会看到一段代码在工程里拷来拷去;某个文件里放了一大坨堆砌起来的代码;一个函数堆了几百上千行;或者一个简单的功能七拐八绕的调了几十个函数,在某个难以发现的猥琐的小角落里默默的调用了某些关键逻辑。

不恰当的组织

这类代码大多复杂度高,难以修改,经常一改就崩;而另一方面,创造了这些代码的人倾向于修改代码,畏惧创造代码,他们宁愿让原本复杂的代码一步步变得更复杂,也不愿意重新组织代码。当你面对一个几千行的类,问为什么不把某某逻辑提取出来的时候,他们会说:

“但是,那样就多了一个类了呀。”

  • 假设和缺少抽象
    这类程序员往往是项目组里开发效率比较高的人,但是大量的业务开发工作导致他们不会做多余的思考,他们的口头禅是:“我每天要做XX个需求”或者“先做完需求再考虑其他的吧”。

这种反模式表现出来的后果往往是代码很难复用,面对deadline的时候,程序员迫切的想要把需求落实成代码,而这往往也会是个循环:写代码的时候来不及考虑复用,代码难复用导致之后的需求还要继续写大量的代码。

一点点积累起来的大量的代码又带来了组织和风格一致性等问题,最后形成了一个新功能基本靠拷的遗留系统。

  • 烂代码还有很多种类型,沿着功能-性能-可读-可测试-可扩展这条路线走下去,还能看到很多匪夷所思的例子。

那么什么是烂代码?个人认为,烂代码包含了几个层次:

如果只是一个人维护的代码,满足功能和性能要求倒也足够了。
如果在一个团队里工作,那就必须易于理解和测试,让其它人员有能力修改各自的代码。
同时,越是处于系统底层的代码,扩展性也越重要。
所以,当一个团队里的底层代码难以阅读、耦合了上层的逻辑导致难以测试、或者对使用场景做了过多的假设导致难以复用时,虽然完成了功能,它依然是坨翔一样的代码。

  • 而相对的,如果一个工程的代码难以阅读,能不能说这个是烂代码?很难下定义,可能算不上好,但是能说它烂吗?如果这个工程自始至终只有一个人维护,那个人也维护的很好,那它似乎就成了“够用的代码”。

很多工程刚开始可能只是一个人负责的小项目,大家关心的重点只是代码能不能顺利的实现功能、按时完工。

过上一段时间,其他人参与时才发现代码写的有问题,看不懂,不敢动。需求方又开始催着上线了,怎么办?只好小心翼翼的只改逻辑而不动结构,然后在注释里写上这么实现很ugly,以后明白内部逻辑了再重构。

再过上一段时间,有个相似的需求,想要复用里面的逻辑,这时才意识到代码里做了各种特定场景的专用逻辑,复用非常麻烦。为了赶进度只好拷代码然后改一改。问题解决了,问题也加倍了。

几乎所有的烂代码都是从“够用的代码”演化来的,代码没变,使用代码的场景发生变了,原本够用的代码不符合新的场景,那么它就成了烂代码。

7 等上面的都处理的差不多了再来看下面的文章吧

  • http://blog.2baxb.me/archives/1343

你可能感兴趣的