如何衡量程式碼質量的好壞，是否有一個標準，是否可以量化？

我認為答案是否定的。如果今年中央給各省下個死命令，要求年度GDP增長達到10%，我相信每個省一定都能完成任務。這幾年，GDP增長都在8%以上，CPI增長不到4%，民族復興完成了62%，這些都量化的，你是否滿意？

回到開發的問題上來，有一些數字，比如bug的個數，reopen的次數能說明一定的問題，但不是全部。它只能描述系統的外在質量的一部分，這個外在質量可以由QA來保證。但是內部質量只能靠開發自己來保證，犧牲內部質量來保證功能和外在質量是不應該的。

內在質量意味著什麼？舉個例子，系統被發現有個坑，我們奉命去補上這個坑。來到指定的位置後，卻發現周圍沒有可以用來填坑的土，要從很遠的地方才能挖來土，這顯然是不現實的，沒有這麼多時間。於是我們就從旁邊隱蔽的地方挖了個坑，用挖出來的土填上了這個坑。通常我們都會想：“新挖的這個坑位置很偏僻，不會有人掉進去的”。或者，我們可能挖了3個小坑來填上一個大坑，至少掉小坑裡面不會摔死人。最後在外部看來，坑被填上了，大家皆大歡喜。

我們在專案開發和修改bug的過程中毫不臉紅的留下各種坑，常常是為了保證進度和外在質量。評審常常也不能解決內部質量問題，開發人員都意識到問題所在，但是“為了保證進度就只能這樣了”。我們還在程式碼中留下注釋，說這裡有個坑，下次要把它補上。不過，經常沒有下次的機會，因為更多工在等著你。

這樣，我們維護著一個有N年曆史，被N個人改過N遍的系統，現在這N個人都找不到了，到處都是坑和看不懂的程式碼。
我們在不斷製造新的坑。
我們也花了很多精力、冒著很大風險填以前的坑（比如你實在看不下去一段混亂的程式碼，抽時間修改了它，但是這個事情不完成任何業務功能，難以立項，常常也就不會有人測試，你甚至要用業餘時間來做開發）。更多的時候，我們路過一個坑的時候不會去修補它，而是假裝沒看見，因為我們不能冒著踩雷的危險給自己找麻煩。

當一邊詛咒前人一邊修改程式的時候，我有時會想，是不是他也知道自己寫了一坨屎，因此連個名字都沒留下？
所以，我呼籲工程師們拿出專業的黑客精神，為自己的作品簽名。在每個新建的原始檔上籤上自己的名字，對一個檔案做了比較大的修改，就把自己的名字簽在原作者的後面；如果只是新增或修改了一個方法，可以只在這個方法的註釋上簽名。

我不知道還有什麼好辦法可以解決內在質量的問題，但依靠開發人員的個人名譽來保證內在質量是肯定可行的。

為自己的程式碼簽名，供後人瞻仰或唾棄，你敢嗎？