發臭的代碼也能撐起一片天

打開一個工程，瀏覽幾個類，手不自覺地捂住了鼻子......

---

好幾個沒有使用過的變量
IO流沒有關閉（我相信只是忘記關閉而已，由於程序丸老是會說「我先這樣寫，後面會補上的」）
一個方法幾百行，幹了十件事
註釋要不沒有，要不就不知道寫的啥
......

---

即便把工程寫得像榴蓮薰得人發慌，也沒有妨礙這個項目的成功：符合業務的歡心、客戶滿意、性能ok，還能獲獎。真是前面客戶稱讚，後面程序丸罵娘。

作軟件是一項社會活動

若是作軟件中技術最重要，世上就不會有那麼多失敗的項目了。

一旦有一羣人在一塊兒作軟件，人與人之間的關係和互動，就構成了一個小社會，軟件過程會充滿了社會活動，這些社會活動是軟件成功與否的關鍵。

譬如，需求談不清楚，軟件使用最高精尖的技術也沒有用。需求如何能變清楚？就是在軟件過程當中經過人與人不斷溝通而變得清楚。

若是團隊是一個分佈式團隊，一部分在城東，一部分在城西，如何保證軟件各項進展順利？這不是用技術能解決的。

---

業務邏輯有無限種實現方式

用充滿設計模式來實現的功能，也能夠用幾個粗暴的長方法來實現，它們的區別只是好很差維護、好很差交接和好很差擴展而已，可是業務邏輯是同樣的，即亦是說核心是一致的，用不同的成原本提供一樣的業務價值。

因此，程序丸知道代碼寫得很爛，也會由於業務邏輯沒有問題而懶得修改。

因此，這就是爲何發臭的代碼也能撐起一片天，它們雖然臭，可是一直爲企業爲組織爲社會源源不斷地產生價值。

如何少寫發臭的代碼

雖然發臭的代碼也能抗起一片天，可是就不等於應該知足於此，畢竟對這類代碼付出的代價也會愈來愈大。那如何改善呢？

• 抽空讀一下《重構》這本書，好好學學怎麼寫代碼
• 掌握幾種經常使用的設計模式（是掌握，不是瞭解）
• 積累代碼規範和業界公認的良好實踐