導讀： 原文來自geekm.ag 上一篇《 Good code is cheap code》，由國內整理編譯《好代碼不值錢》。作者認爲好的程序員和偉大的程序員之間的區別就在於偉大的程序員理解他們的模式。
以下是文章內容：
當我跟做開發的同事說出這話時，他們的第一反應是一種驚愕，然後是將近一個星期的嘲笑，把它當作一個笑話來講。當他們走近看我的表情、知道我是認真的時，才收斂一點。
當最初的驚愕消退後，他們會用一些這樣的話來反駁：“好代碼不廉價，好代碼是採用經過數十年計算機科學研究和積累得出的最佳實踐設計模式和方法論建立起來的精心製作的程序代碼。”
我只好繼續解釋爲什麼他們給出的好代碼的定義有問題的原因是(這是很多開發人員都忽視了的一個原因)：知曉各種設計模式，框架，技術技巧只是事情的一方面，而知道何時該、何時不該應用他們纔是更重要的問題。在不知道一種技巧方式如何能對系統的開發有幫助的情況下，這種模式方法極有可能成爲一種開發的阻礙，而不是一種有益的幫助。
我還要解釋說，我所說的“廉價的代碼”是指這些代碼只需要很少的人/天數就能開發出來，並不是說是由沒有經驗的開發人員、在很少的工資報酬下、用6個月封閉式、只有烤白薯和豆腐湯可吃的環境中開發出來的東西。
但是 … 設計模式畢竟是個好東西 … 不是嗎？當然，但它們好在哪裏？它們能提供什麼好處？
- 容易維護
- 產品更健壯
- 容易理解
- 易於日後的改進提高
- 更好的可跟蹤性
你會發現所有的這些最終都落到一點上：從長期的角度看，它們能讓你更快的做事情。這事情有可能是系統遷移，或是增加一個新功能，不論是什麼，通過運用這些方法模式，你會在時間效率上獲得實實在在的好處。
這麼說，我們觀點一致嗎？
怎麼說呢，讓我給你們說個例子，我們看看實現它的幾種方式。
系統
用PHP創建一個發郵件的表單，表單裏有幾個表單項，用郵件把這些數據發送給某個人。除此之外，表單裏的內容還要存入MySQL數據庫裏。
現在，用什麼方式實現它們最好？按照傳統的說法，採用最好的實踐設計模式，你可能會想到這些：
- MVC
- N-層設計，包括數據庫抽象層
- 對象關係映射(ORM)
- 可能用到的框架
- XML配置和相關模型
- 等等.
我可以說，這簡直是瘋了，客戶的這些需求完全可以用10幾行代碼、一個小時裏(包括測試時間)完成，而且所有的那些方法模式所希望達到的效果(諸如可讀性，可移植性，穩定性)都有了。如果使用上面列出的那些，反而真正的會達不到這個目標，使代碼複雜化，難於理解和維護修改。
那現在，假設客戶又來了，要求做一些改動，比如要增加一個管理員的界面。這樣的話，你就勝利了，你已經實現了很多很有用處的東西；然而這是因爲你在第一次開發這個系統時付出了很大的代價。我要向你聲明的是，即使我現在把這些簡單的代碼進行重構，增加一些簡單的業務層，也仍然比按你要求的那種過度技術化的初始實現方案要簡單的多。
再說了，如果客戶要求的只是在表單裏增加一個屬性，那你的N-層設計方案會讓你痛苦不堪，因爲你需要改動各個層，包括那些CRUD代碼。
SCRUM
我發現Scrum能吸引我的最大一個原因是它能迫使你敏捷開發；它能迫使你在每個Sprint結束的時候把東西都實現、發佈。它不會讓你做出目前用不到的多餘的東西；它不會允許你在實現東西上有任何所謂“正確方式”的奢侈行爲。
相反，在你需要的時候你纔去重構。當然，這會有一定的風險，因爲在實現某些功能上你會花去比當初已經做了一些基礎工作的情況下要更長的時間。然而，產品開發就像是一個沙漠中四處漂移的沙丘，你永遠不可能準確的知道一個產品在將來會做如何的改動。所有的你花在實現這些很有吸引力的各種模式上的時間很可能會成爲一種完全的浪費。
複用性
有些人會指出，我所說的方式產生的代碼不具有太多的複用性，不能在新開發的一些其它系統中使用。我對這個問題的回覆就是，在根本不知道某些東西是否/如何/在哪將會被複用的情況下去設計一個可複用的東西，這就跟去實現一些你根本用不到的功能或你的應用裏跟本用不到的功能一樣愚蠢而糟糕。如果你有一個清楚的遠見，知道什麼地方會複用這些東西，這就不同了，因爲你確實有一個內部的業務需求在指導你正確的開發方向。
我的最後的思考 …
- 我想，如果
- 瞭解你的設計模式，知道它們各自的好處(我一直認爲，好的程序員和偉大的程序員之間的區別就在於偉大的程序員理解他們的模式)；
- 讓你的代碼廉價：
- 當模式能夠給你帶來好處，而且爲你省時時纔去使用它們；
- 如果不是這樣就不要使用它們(例如：想想你最近的一次爲什麼要把系統遷移到一個不同的數據庫上？)；
- 當框架能夠幫你提高開發速度時才使用它們；
- 在必要的時候重構，不要做一些超前性的開發；
你能按照這些指導原則做事，你會發現開發週期變短、實現的代碼更簡潔，易於調試，易於維護修改。
譯文鏈接：好代碼不值錢