为代码签名,供后人瞻仰或唾弃,你敢吗?

如何衡量代码质量的好坏,是否有一个标准,是否可以量化?

我认为答案是否定的。如果今年中央给各省下个死命令,要求年度GDP增长达到10%,我相信每个省一定都能完成任务。这几年,GDP增长都在8%以上,CPI增长不到4%,民族复兴完成了62%,这些都量化的,你是否满意?

回到开发的问题上来,有一些数字,比如bug的个数,reopen的次数能说明一定的问题,但不是全部。它只能描述系统的外在质量的一部分,这个外在质量可以由QA来保证。但是内部质量只能靠开发自己来保证,牺牲内部质量来保证功能和外在质量是不应该的。

内在质量意味着什么?举个例子,系统被发现有个坑,我们奉命去补上这个坑。来到指定的位置后,却发现周围没有可以用来填坑的土,要从很远的地方才能挖来土,这显然是不现实的,没有这么多时间。于是我们就从旁边隐蔽的地方挖了个坑,用挖出来的土填上了这个坑。通常我们都会想:“新挖的这个坑位置很偏僻,不会有人掉进去的”。或者,我们可能挖了3个小坑来填上一个大坑,至少掉小坑里面不会摔死人。最后在外部看来,坑被填上了,大家皆大欢喜。

我们在项目开发和修改bug的过程中毫不脸红的留下各种坑,常常是为了保证进度和外在质量。评审常常也不能解决内部质量问题,开发人员都意识到问题所在,但是“为了保证进度就只能这样了”。我们还在代码中留下注释,说这里有个坑,下次要把它补上。不过,经常没有下次的机会,因为更多任务在等着你。

这样,我们维护着一个有N年历史,被N个人改过N遍的系统,现在这N个人都找不到了,到处都是坑和看不懂的代码。
我们在不断制造新的坑。
我们也花了很多精力、冒着很大风险填以前的坑(比如你实在看不下去一段混乱的代码,抽时间修改了它,但是这个事情不完成任何业务功能,难以立项,常常也就不会有人测试,你甚至要用业余时间来做开发)。更多的时候,我们路过一个坑的时候不会去修补它,而是假装没看见,因为我们不能冒着踩雷的危险给自己找麻烦。

当一边诅咒前人一边修改程序的时候,我有时会想,是不是他也知道自己写了一坨屎,因此连个名字都没留下?
所以,我呼吁工程师们拿出专业的黑客精神,为自己的作品签名。在每个新建的源文件上签上自己的名字,对一个文件做了比较大的修改,就把自己的名字签在原作者的后面;如果只是添加或修改了一个方法,可以只在这个方法的注释上签名。

我不知道还有什么好办法可以解决内在质量的问题,但依靠开发人员的个人名誉来保证内在质量是肯定可行的。

为自己的代码签名,供后人瞻仰或唾弃,你敢吗?

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: 为代码签名,供后人瞻仰或唾弃,你敢吗?

黄理

花名叶离,淘宝网技术专家。

Latest posts by 黄理 (see all)

FavoriteLoading添加本文到我的收藏
  • Trackback are closed
  • Comments (4)
  1. 好文章啊

    • CC
    • 07/19. 2013 11:23am

    很多时候坑的出现是因为程序员没有经验,而有经验的高级程序员触碰新领域的时候,虽然能避免普通的小坑,但是依然会有艰深的问题会出现,就是传说中的天坑,一般发现不了,发现了也不是很好解决。
    比如,初级程序员很便宜,公司用,他在在dao查询的时候,虽然用hibernate,但它依然选择使用拼接sql而不是使用占位符。这就是小坑,以后有经验了,也许他会长进
    中级程序员是在在写sql语句的时候需要使用占位符,并且考虑where条件是否溢出或者哪个查询命中率高,但也当他触碰一些cs客户端而非他web前段的时候,也许系统层面的问题比如造成0day了。你需要指责坑的人么?或许它本身也不知道呢。
    所以spring,hibernate从1.0至3.0循序渐进。
    给自己的代码写注释,写明公用写明作者,写明修改者以及修改意图,这个都是代码素质,责任心的问题!习惯好的人注释自然会加,对付事儿的家伙,你说多少次,除非扣工资,不然他就是懒得弄!
    其实这都是程序员的代码成长的过程,无非你年轻的时候给别人挖挖坑,有经验的人帮你填上,等你老的时候,别人给你挖挖坑,你帮人填上

    • 劳希
    • 07/19. 2013 4:09pm

    好文点赞

You must be logged in to post a comment.

return top