代碼規範性與品質問題～

２００１年在delphibbs做“首屆Delphi編程競賽”活動(http://www.delphibbs.com/delphibbs/dispq.asp?lid=650664)的時候，曾就代碼的規範性與品質問題與大家進行過討論，摘錄一些言論如下：

=========================

3. 我們公司有個程式員，現在是專案經理。他原本是做圖形程式開發的，我看過它的一個工具的代碼，OHHHH，我當時差點沒有昏倒。——它的代碼做得就象方塊，每一行幾乎都一個樣子，似乎都在不斷重複。但是，這些代碼的運行效率居然比我見到的所有圖形開發包都快！

所以，我絕對同意“一個真正優秀的方案可能代碼很多，很精巧，也很複雜，但絕對在效率、速度上非普通方案可比”、“大道深處又至簡，一個非常出色的方案往往可以化複雜為簡單，化腐朽為神奇，達到代碼即方案，代碼即解釋，恍恍乎遊刃有餘”和“最出色的代碼不是代碼本身，而是代碼體現出來的出神入化的思維和境界。到達這個境界，代碼多少已經不再重要了”這樣的觀點。

4. 代碼的規範性我深有體會。我們公司現在正在展開的也是一個叫“代碼格式化規範”的動作。

但我要說的是一個小故事，我的一個組員總是在說My Code他看不懂，這看不懂那也看不懂；而另一個組員呢，將我一個寫了兩年的項目那個去看了一個多月，說懂了。前一個組員總是說My Code不“規範”，不“格式化”，用了太多的技巧，不用標準的寫法；而後一個組員卻什麼也不說。兩個組員最大的不同是：前一個組員只有兩年的編程經驗，而後一個，有十年的編程經驗。

如果，如果你用Delphi來寫一個“作業系統級程式”，那麼，你能用到的“標準的寫法”可能沒幾個，你可能必須用各種各樣的技巧，各種各樣離奇的思想。這不是一般人能夠想到的做到的。有興趣的人可以去看看QString這個字串處理單元，那絕對是不好讀的代碼，也絕對精鍊，效率也絕對高。但可能絕對“不標準”、“不規範”。

我並不是反對“代碼格式化”，我只是說，我們在這裡開展一個競賽，重點並不是要去格式化代碼，我們的主旨是“寫出好的思想”和“好的代碼”。那些格式化中存在的各種各樣的注釋和格式化用的空格，自然有工具去過濾掉它，你不必關心它們影響你的代碼位元組數。

5. 這個競賽的確是在“鼓勵提高個人能力”，但絕對沒有“忽視團隊精神”的意思。哈哈。

我們一直忽略了這點，沒有提出來說，算是我的工作失誤。其實中國現在的“程式高手”很多，但真正懂得“軟體工作”和組織“團隊開發”的人才之又少。事實上我現在也正在學這個，正在帶開發組，正在從最小的“團隊”做起。——我自認還做得非常非常差。印度培養出來的程式員象一個個標準大小的方塊，任意多塊放在任意位置都是有用的，但缺乏靈魂；中國培養出來的程式員象一個個釘子，放哪裡打都好用，靈氣十足，能力十足，但一大堆釘子放在一起，你的手碰都不敢碰一下。

但中國的程式員在國外卻是極好的。因為人家懂得如何組織釘子開發，而不是只懂得如何將方塊“積木”在一起。

不要因為中國沒有好的專案管理人員，就要求所有的程式員全變成方塊，這是舍本而逐末的事。

6. 好的雕刻師必須先是好的木匠，藝人必須先是匠人。

=========================

最後這句“藝人必須先是匠人”，我後來還在《Delphi實現可執行檔之源碼詳解》中引用過：

=========================

必先是匠人，之後才會是藝人，再之後才會是藝術家。程式員就是程式員，如果不靜下心來做代碼，好高騖遠則終將一無所成。

志存高遠而腳踏實地，此實地者，源碼也。