本文是從 Good code is cheap code 這篇文章翻譯而來(lái)。

　　長(zhǎng)久以來(lái)我一直主張：好代碼是廉價(jià)的代碼。

　　當(dāng)我跟做開(kāi)發(fā)的同事說(shuō)出這話時(shí)，他們的第一反應(yīng)是一種驚愕，然后是將近一個(gè)星期的嘲笑，把它當(dāng)作一個(gè)笑話來(lái)講。當(dāng)他們走近看我的表情、知道我是認(rèn)真的時(shí)，才收斂一點(diǎn)。

　　當(dāng)最初的驚愕消退后，他們會(huì)用一些這樣的話來(lái)反駁：“好代碼不廉價(jià)，好代碼是采用經(jīng)過(guò)數(shù)十年計(jì)算機(jī)科學(xué)研究和積累得出的最佳實(shí)踐設(shè)計(jì)模式和方法論建立起來(lái)的精心制作的程序代碼。”

　　我只好繼續(xù)解釋為什么他們給出的好代碼的定義有問(wèn)題的原因是(這是很多開(kāi)發(fā)人員都忽視了的一個(gè)原因)：知曉各種設(shè)計(jì)模式，框架，技術(shù)技巧只是事情的一方面，而知道何時(shí)該、何時(shí)不該應(yīng)用他們才是更重要的問(wèn)題。在不知道一種技巧方式如何能對(duì)系統(tǒng)的開(kāi)發(fā)有幫助的情況下，這種模式方法極有可能成為一種開(kāi)發(fā)的阻礙，而不是一種有益的幫助。

　　我還要解釋說(shuō)，我所說(shuō)的“廉價(jià)的代碼”是指這些代碼只需要很少的人/天數(shù)就能開(kāi)發(fā)出來(lái)，并不是說(shuō)是由沒(méi)有經(jīng)驗(yàn)的開(kāi)發(fā)人員、在很少的工資報(bào)酬下、用6個(gè)月封閉式、只有烤白薯和豆腐湯可吃的環(huán)境中開(kāi)發(fā)出來(lái)的東西。

　　但是…設(shè)計(jì)模式畢竟是個(gè)好東西…不是嗎？

　　當(dāng)然，但它們好在哪里？它們能提供什么好處？

• 容易維護(hù)
• 產(chǎn)品更健壯
• 容易理解
• 易于日后的改進(jìn)提高
• 更好的可跟蹤性

　　你會(huì)發(fā)現(xiàn)所有的這些最終都落到一點(diǎn)上：從長(zhǎng)期的角度看，它們能讓你更快的做事情。這事情有可能是系統(tǒng)遷移，或是增加一個(gè)新功能，不論是什么，通過(guò)運(yùn)用這些方法模式，你會(huì)在時(shí)間效率上獲得實(shí)實(shí)在在的好處。

　　這么說(shuō)，我們觀點(diǎn)一致嗎？

　　怎么說(shuō)呢，讓我給你們說(shuō)個(gè)例子，我們看看實(shí)現(xiàn)它的幾種方式。

　　系統(tǒng)

　　用php創(chuàng)建一個(gè)發(fā)郵件的表單，表單里有幾個(gè)表單項(xiàng)，用郵件把這些數(shù)據(jù)發(fā)送給某個(gè)人。除此之外，表單里的內(nèi)容還要存入MySQL數(shù)據(jù)庫(kù)里。

　　現(xiàn)在，用什么方式實(shí)現(xiàn)它們最好？按照傳統(tǒng)的說(shuō)法，采用最好的實(shí)踐設(shè)計(jì)模式，你可能會(huì)想到這些：

• MVC
• N-層設(shè)計(jì)，包括數(shù)據(jù)庫(kù)抽象層
• 對(duì)象關(guān)系映射(ORM)
• 可能用到的框架
• XML配置和相關(guān)模型
• 等等.

　　我可以說(shuō)，這簡(jiǎn)直是瘋了，客戶的這些需求完全可以用10幾行代碼、一個(gè)小時(shí)里(包括測(cè)試時(shí)間)完成，而且所有的那些方法模式所希望達(dá)到的效果(諸如可讀性，可移植性，穩(wěn)定性)都有了。如果使用上面列出的那些，反而真正的會(huì)達(dá)不到這個(gè)目標(biāo)，使代碼復(fù)雜化，難于理解和維護(hù)修改。

　　那現(xiàn)在，假設(shè)客戶又來(lái)了，要求做一些改動(dòng)，比如要增加一個(gè)管理員的界面。這樣的話，你就勝利了，你已經(jīng)實(shí)現(xiàn)了很多很有用處的東西；然而這是因?yàn)槟阍诘谝淮伍_(kāi)發(fā)這個(gè)系統(tǒng)時(shí)付出了很大的代價(jià)。我要向你聲明的是，即使我現(xiàn)在把這些簡(jiǎn)單的代碼進(jìn)行重構(gòu)，增加一些簡(jiǎn)單的業(yè)務(wù)層，也仍然比按你要求的那種過(guò)度技術(shù)化的初始實(shí)現(xiàn)方案要簡(jiǎn)單的多。

　　再說(shuō)了，如果客戶要求的只是在表單里增加一個(gè)屬性，那你的N-層設(shè)計(jì)方案會(huì)讓你痛苦不堪，因?yàn)槟阈枰膭?dòng)各個(gè)層，包括那些CRUD代碼。

　　SCRUM

　　我發(fā)現(xiàn)Scrum能吸引我的最大一個(gè)原因是它能迫使你敏捷開(kāi)發(fā)；它能迫使你在每個(gè)Sprint結(jié)束的時(shí)候把東西都實(shí)現(xiàn)、發(fā)布。它不會(huì)讓你做出目前用不到的多余的東西；它不會(huì)允許你在實(shí)現(xiàn)東西上有任何所謂“正確方式”的奢侈行為。

　　相反，在你需要的時(shí)候你才去重構(gòu)。當(dāng)然，這會(huì)有一定的風(fēng)險(xiǎn)，因?yàn)樵趯?shí)現(xiàn)某些功能上你會(huì)花去比當(dāng)初已經(jīng)做了一些基礎(chǔ)工作的情況下要更長(zhǎng)的時(shí)間。然而，產(chǎn)品開(kāi)發(fā)就像是一個(gè)沙漠中四處漂移的沙丘，你永遠(yuǎn)不可能準(zhǔn)確的知道一個(gè)產(chǎn)品在將來(lái)會(huì)做如何的改動(dòng)。所有的你花在實(shí)現(xiàn)這些很有吸引力的各種模式上的時(shí)間很可能會(huì)成為一種完全的浪費(fèi)。

　　復(fù)用性

　　有些人會(huì)指出，我所說(shuō)的方式產(chǎn)生的代碼不具有太多的復(fù)用性，不能在新開(kāi)發(fā)的一些其它系統(tǒng)中使用。我對(duì)這個(gè)問(wèn)題的回復(fù)就是，在根本不知道某些東西是否/如何/在哪將會(huì)被復(fù)用的情況下去設(shè)計(jì)一個(gè)可復(fù)用的東西，這就跟去實(shí)現(xiàn)一些你根本用不到的功能或你的應(yīng)用里跟本用不到的功能一樣愚蠢而糟糕。如果你有一個(gè)清楚的遠(yuǎn)見(jiàn)，知道什么地方會(huì)復(fù)用這些東西，這就不同了，因?yàn)槟愦_實(shí)有一個(gè)內(nèi)部的業(yè)務(wù)需求在指導(dǎo)你正確的開(kāi)發(fā)方向。

　　我的最后的思考…

• 了解你的設(shè)計(jì)模式，知道它們各自的好處(我一直認(rèn)為，好的程序員和偉大的程序員之間的區(qū)別就在于偉大的程序員理解他們的模式)；
• 讓你的代碼廉價(jià)：
  • 當(dāng)模式能夠給你帶來(lái)好處，而且為你省時(shí)時(shí)才去使用它們；
  • 如果不是這樣就不要使用它們(例如：想想你最近的一次為什么要把系統(tǒng)遷移到一個(gè)不同的數(shù)據(jù)庫(kù)上？)；
  • 當(dāng)框架能夠幫你提高開(kāi)發(fā)速度時(shí)才使用它們；
• 在必要的時(shí)候重構(gòu)，不要做一些超前性的開(kāi)發(fā)；

　　我想，如果你能按照這些指導(dǎo)原則做事，你會(huì)發(fā)現(xiàn)開(kāi)發(fā)周期變短、實(shí)現(xiàn)的代碼更簡(jiǎn)潔，易于調(diào)試，易于維護(hù)修改。

it知識(shí)庫(kù)：好代碼不值錢，轉(zhuǎn)載需保留來(lái)源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。