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

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

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

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

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

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

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

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

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

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

(全文完)