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

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

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

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

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

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

这样,我们维护着一个有N年历史,被N个人改过N遍的系统,现在这N个人都找不到了,到处都是坑和看不懂的代码。

当一边诅咒前人一边修改程序的时候,我有时会想,是不是他也知道自己写了一坨屎,因此连个名字都没留下?

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

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

(全文完)

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

相关文章:

  • 2021-07-22
  • 2021-11-10
  • 2021-06-14
  • 2021-07-12
  • 2021-08-30
  • 2021-10-20
  • 2021-11-27
猜你喜欢
  • 2021-12-05
  • 2021-07-08
  • 2021-11-06
  • 2021-04-27
  • 2021-07-19
  • 2021-11-28
相关资源
相似解决方案