作為軟件開發(fā)人員，有一個(gè)小秘密：不管你寫的代碼有多么優(yōu)秀，對(duì)另外一位開發(fā)人員來說，都毫無用處。

　　如果代碼足夠“干凈”，你都可以吃代碼上面的壽司，這沒什么。如果每次代碼顯示在屏幕上時(shí)，約翰·卡馬克（John Carmack）和LinusTorvalds都對(duì)這些代碼都佩服的五體投地，這也沒什么。但一些開發(fā)人員稱這些代碼是垃圾，而這些人通常就是你離開之后接手你代碼的人。

　　原因有很多，而且比較瑣碎：

• 在方法/函數(shù)中，你使用了字符串串聯(lián)，而不是StringBuilder類。所以，如果這種情況發(fā)生，那么做出這樣的決定就是有意的，因?yàn)橐话氵@樣的算法只會(huì)串聯(lián)3到4個(gè)字符串。下一個(gè)開發(fā)人員才不關(guān)心這些。

• 沒有按照規(guī)定把花括號(hào)放到應(yīng)該放置的那一行，而是放到了同一行（反之亦然）。

• 使用了switch語句，但大家（包括下一個(gè)開發(fā)人員）都認(rèn)為應(yīng)當(dāng)將其替換為狀態(tài)或者策略模式。難道你沒讀過《設(shè)計(jì)模式》這本書嗎？不要因?yàn)橹挥幸粋€(gè)switch語句導(dǎo)致沒有代碼重復(fù)而擔(dān)心。

• 在依賴注入（Dependency Injection）技術(shù)上，你采用Spring.NET，但下一個(gè)開發(fā)人員更喜歡使用Windsor。他們認(rèn)為只有白癡才使用Spring.NET（反之亦然）。

• 或者你自始至終一直都在采用依賴注入技術(shù)。依賴注入到底是什么鬼東西？現(xiàn)在我完全看不懂代碼！:(

　　盡管我們?yōu)橥昝来a而努力，但在真正的項(xiàng)目開發(fā)中，這是很難實(shí)現(xiàn)的。因?yàn)榇a會(huì)受諸如時(shí)間壓力之類的約束限制。不幸的是，從代碼中看不出約束來， 看到的只是這些約束造成的影響。當(dāng)下一個(gè)開發(fā)人員閱讀你的代碼時(shí)，他們是看不出這些代碼是在項(xiàng)目發(fā)布前的剩余1小時(shí)內(nèi)完成的。

　　然而我承認(rèn)，在被誤導(dǎo)性評(píng)論中傷之前，很難不先對(duì)這類評(píng)論采取一些措施，比如通過注釋在代碼中添加一些約束。例如：

public void SomeMethod()
{
/*
程序中至多有4到5個(gè)foo，所以，在這種情況下使用字符串串聯(lián)是可行的。這里有5篇有關(guān)性能討論的帖子的鏈接。
讓我休息一下，現(xiàn)在是凌晨3點(diǎn)了，我一直忙于Jolt，這個(gè)項(xiàng)目已經(jīng)逾期3個(gè)月了，現(xiàn)在我一點(diǎn)社交生活都沒有。放我一馬吧！...
*/
string result = string.Empty;
foreach(Foo foo in Foos)
{
result += foo;
}
return result;
}

　　這樣的防衛(wèi)看起來有點(diǎn)過分，不過分？在注釋中說明為什么制定一個(gè)特殊的、不明顯的設(shè)計(jì)方案，這沒什么問題。事實(shí)上，這也正是注釋的作用所在，而不是為了簡(jiǎn)單地重述一下代碼做了什么。

　　然而問題是，開發(fā)人員有時(shí)候彼此之間的制約很大，你用綠色寫論述（或者你的集成開發(fā)環(huán)境中注釋對(duì)應(yīng)的任何一個(gè)顏色）來標(biāo)明每一行代碼，因?yàn)槟悴恢缹?duì)下一個(gè)開發(fā)人員來說，什么才算是明顯的。

　　這也是為什么前幾天收到一個(gè)開發(fā)人員的電子郵件我非常高興的原因。這個(gè)開發(fā)人員繼承了我寫的一些代碼，并在郵件中評(píng)價(jià)了我的解決方案，在這里我引用他的原話：“寫的非常棒”。

　　真的？你不是在愚弄我吧？Ashton，你究竟躲在哪？

　　這很可能是你從別的開發(fā)人員那得到的最高稱贊。而且我認(rèn)為這不是因?yàn)槲艺娴氖沁@樣一個(gè)卓越的開發(fā)人員。我認(rèn)為真正應(yīng)該贊揚(yáng)的人是那位給出稱贊的開發(fā)人員。

　　我的意思是，當(dāng)我繼承別人的代碼時(shí)，我的反應(yīng)很有代表性，他們到底為什么要這樣寫代碼！？難道他們沒有學(xué)過如何編程么！？除了剛剛離開的那位前任開發(fā)人員，還有誰更適合做替罪羊？（編注：伯樂在線在前段時(shí)間編譯的《程序員：你的代碼為誰而寫》一文中就說到：“要評(píng)判很久以前寫出的代碼是優(yōu)是劣很不容易，因?yàn)楝F(xiàn)在已經(jīng)不知道當(dāng)時(shí)為什么編寫這些代碼，也不知道為誰編寫了這些代碼。”所以，這種替罪羊事情比較常見。）

　　幸好我比較機(jī)智，能將這些想法藏在心里。今后，我會(huì)在理解事情上更下功夫。當(dāng)我繼承別人代碼時(shí)，我會(huì)假設(shè)這些代碼是開發(fā)人員在72小時(shí)內(nèi)一次編碼完成的，他魔獸世界中的角色身邊到處都是蜜蜂和劫持的人質(zhì)，在一切真正開始變?cè)阒埃挥?個(gè)小時(shí)，并且是在一臺(tái)386的機(jī)器上來完成編碼。

　　鑒于那些情況，難怪那個(gè)笨蛋不使用IDisposable實(shí)例附近的代碼塊。

　　譯文出處：伯樂在線 - 職場(chǎng)博客
　　譯文鏈接：http://www.jobbole.com/entry.php/452

　　原文作者：Phil Haack　　編譯：伯樂在線 敏捷翻譯組 - 牛冬梅

　　如需轉(zhuǎn)載，但請(qǐng)注明原文/譯文出處、譯文超鏈接和譯者等信息，否則視為侵權(quán)，謝謝合作！

it知識(shí)庫(kù)：開發(fā)人員能夠得到的最好贊揚(yáng)，轉(zhuǎn)載需保留來源！

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