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