如何衡量代码质量的好坏，是否有一个标准，是否可以量化？
我认为答案是否定的。如果今年中央给各省下个死命令，要求年度GDP增长达到10%，我相信每个省一定都能完成任务。这几年，GDP增长都在8%以上，CPI增长不到4%，民族复兴完成了62%，这些都量化的，你是否满意？
回到开发的问题上来，有一些数字，比如bug的个数，reopen的次数能说明一定的问题，但不是全部。它只能描述系统的外在质量的一部分，这个外在质量可以由QA来保证。但是内部质量只能靠开发自己来保证，牺牲内部质量来保证功能和外在质量是不应该的。
内在质量意味着什么？举个例子，系统被发现有个坑，我们奉命去补上这个坑。来到指定的位置后，却发现周围没有可以用来填坑的土，要从很远的地方才能挖来土，这显然是不现实的，没有这么多时间。于是我们就从旁边隐蔽的地方挖了个坑，用挖出来的土填上了这个坑。通常我们都会想：“新挖的这个坑位置很偏僻，不会有人掉进去的”。或者，我们可能挖了3个小坑来填上一个大坑，至少掉小坑里面不会摔死人。最后在外部看来，坑被填上了，大家皆大欢喜。
我们在项目开发和修改bug的过程中毫不脸红的留下各种坑，常常是为了保证进度和外在质量。评审常常也不能解决内部质量问题，开发人员都意识到问题所在，但是“为了保证进度就只能这样了”。我们还在代码中留下注释，说这里有个坑，下次要把它补上。不过，经常没有下次的机会，因为更多任务在等着你。
这样，我们维护着一个有N年历史，被N个人改过N遍的系统，现在这N个人都找不到了，到处都是坑和看不懂的代码。
我们在不断制造新的坑。
我们也花了很多精力、冒着很大风险填以前的坑（比如你实在看不下去一段混乱的代码，抽时间修改了它，但是这个事情不完成任何业务功能，难以立项，常常也就不会有人测试，你甚至要用业余时间来做开发）。更多的时候，我们路过一个坑的时候不会去修补它，而是假装没看见，因为我们不能冒着踩雷的危险给自己找麻烦。
当一边诅咒前人一边修改程序的时候，我有时会想，是不是他也知道自己写了一坨屎，因此连个名字都没留下？
所以，我呼吁工程师们拿出专业的黑客精神，为自己的作品签名。在每个新建的源文件上签上自己的名字，对一个文件做了比较大的修改，就把自己的名字签在原作者的后面；如果只是添加或修改了一个方法，可以只在这个方法的注释上签名。
我不知道还有什么好办法可以解决内在质量的问题，但依靠开发人员的个人名誉来保证内在质量是肯定可行的。
为自己的代码签名，供后人瞻仰或唾弃，你敢吗？
