從代碼裡你可以看到什嗎？

經常有小同事和我說，這程式的代碼寫的太垃圾了，什麼水平。

確實如此，大部分持續存在一段時間的程式碼品質都不怎麼樣。

從循環複雜度的角度看，超過15的代碼就很看了會頭疼了，但可怕的是循環複雜度到70,、80的也不是沒有。

誰要攤上改這種代碼，估計上吊的心都有：不改不行，改了誰知道出什麼問題？

 

從這種代碼裡能看出來什麼，很說明的人的心境。

說看到技術水平較差的大多是剛畢業的兄弟。

說看到利益糾葛，人心世道的大概就是成年老鳥了。

 

我持後一種觀點。

 

為什麼世界上會有這麼多垃圾代碼，這絕對不只是因為技術不行。

如果世界只由技術因素主宰，那麼按理說只要一個軟體存在的時間足夠長，投入的人力足夠多，代碼一定會變的足夠好。

但事實恰恰與這相反，存在時間越長的代碼往往越垃圾。

這可以做簡單理解。

既存的代碼錶征著一種市場價值，如果改了它那麼一旦造成的損失誰來負責？

程式員來負責？經理來負責？

沒人來負責，那麼只能破壞邏輯清晰性來保證妥當性，代碼自然就會變得越來越垃圾。

所以說這裡首先是利益糾葛問題。

這是非常有意思的一個課題，因為改好代碼長期有收益，短期必然有風險---再牛的人也沒辦法保證自己的修改毫無偏差。

宏觀來看，保證好代碼真的很簡單：找一幫有責任心的很牛的人，讓他們不考慮市場因素的持續進行重構，那代碼必然越變越好。

而關鍵則是，如果你是CEO，你願意這麼幹嗎？

所以說在閉源的前景下，誰要是真想保證代碼品質，先要擺平利益糾葛。

軟體工程離了這個就真像任人打扮的小姑娘，實質上可以是翠花、可以紅袖，但就不能是自己。

 

接下來是個人的問題，假設說是閉源的代碼，同時更進一步，Review不怎麼做，或者說做了也就意思一下，那會怎麼樣？

結果也很簡單，代碼這時候會成為負面心思的大集合。

想換工作的、家裡有事的、感覺公司裡不重視技術的都在寫代碼，趕進度的、加班熬夜的也在寫代碼，作為結果代碼也就成了種種心思的具體體現。

很多代碼一看就是沒怎麼思考，抱著能用就行的心思寫的。很多代碼一看就是為了安全起見寫的，寫的人大多時候應該能認識到，長期來看這不好。

當然前面說的技術不足也會和這些因素混合在一起影響最終呈現出來的代碼。

但要想代碼品質好，利益糾葛之後，要擺平人的心思--這大致就是人件的基本出發點。

 

國內很有意思的一個現象是ISO，CMMI這類東西往往會在異常火爆之後折戟沉沙。

很多人對此做不同的解釋，但如果讓我來解釋，我會講，純工程這個維度太沒力量，在利益糾葛，人心世道面前完全就不是個有重量的砝碼，所以方法論特別容易掛。

這不一定對，但同我個人的某些經曆以及看到的案例來驗證的話，也還算勉強有道理。

讓人開心的是，從各種報道來看，願意腳踏實地整代碼的組織似乎越來越多了。

 

最後說一句，從這個角度看，開源具有絕對的優勢。

雖然沒有官方統計，但至少從日常感受來看，開原始碼的品質遠高於閉源的代碼---學習或參與優秀的開源項目應該對技術提升非常有協助。