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