|
|
作為軟件開發人員，有一個小秘密：不管你寫的代碼有多么優秀，對另外一位開發人員來說，都毫無用處。
如果代碼足夠“干凈”，你都可以吃代碼上面的壽司，這沒什么。如果每次代碼顯示在屏幕上時，約翰·卡馬克（John Carmack）和LinusTorvalds都對這些代碼都佩服的五體投地，這也沒什么。但一些開發人員稱這些代碼是垃圾，而這些人通常就是你離開之后接手你代碼的人。
原因有很多，而且比較瑣碎：
- 在方法/函數中，你使用了字符串串聯，而不是StringBuilder類。所以，如果這種情況發生，那么做出這樣的決定就是有意的，因為一般這樣的算法只會串聯3到4個字符串。下一個開發人員才不關心這些。
- 沒有按照規定把花括號放到應該放置的那一行，而是放到了同一行（反之亦然）。
- 使用了switch語句，但大家（包括下一個開發人員）都認為應當將其替換為狀態或者策略模式。難道你沒讀過《設計模式》這本書嗎？不要因為只有一個switch語句導致沒有代碼重復而擔心。
- 或者你自始至終一直都在采用依賴注入技術。依賴注入到底是什么鬼東西？現在我完全看不懂代碼！:(
盡管我們為完美代碼而努力，但在真正的項目開發中，這是很難實現的。因為代碼會受諸如時間壓力之類的約束限制。不幸的是，從代碼中看不出約束來， 看到的只是這些約束造成的影響。當下一個開發人員閱讀你的代碼時，他們是看不出這些代碼是在項目發布前的剩余1小時內完成的。
然而我承認，在被誤導性評論中傷之前，很難不先對這類評論采取一些措施，比如通過注釋在代碼中添加一些約束。例如：
public void SomeMethod()
{
/*
程序中至多有4到5個foo，所以，在這種情況下使用字符串串聯是可行的。這里有5篇有關性能討論的帖子的鏈接。
讓我休息一下，現在是凌晨3點了，我一直忙于Jolt，這個項目已經逾期3個月了，現在我一點社交生活都沒有。放我一馬吧！...
*/
string result = string.Empty;
foreach(Foo foo in Foos)
{
result += foo;
}
return result;
}
這樣的防衛看起來有點過分，不過分？在注釋中說明為什么制定一個特殊的、不明顯的設計方案，這沒什么問題。事實上，這也正是注釋的作用所在，而不是為了簡單地重述一下代碼做了什么。
然而問題是，開發人員有時候彼此之間的制約很大，你用綠色寫論述（或者你的集成開發環境中注釋對應的任何一個顏色）來標明每一行代碼，因為你不知道對下一個開發人員來說，什么才算是明顯的。
這也是為什么前幾天收到一個開發人員的電子郵件我非常高興的原因。這個開發人員繼承了我寫的一些代碼，并在郵件中評價了我的解決方案，在這里我引用他的原話：“寫的非常棒”。
真的？你不是在愚弄我吧？Ashton，你究竟躲在哪？
這很可能是你從別的開發人員那得到的最高稱贊。而且我認為這不是因為我真的是這樣一個卓越的開發人員。我認為真正應該贊揚的人是那位給出稱贊的開發人員。
我的意思是，當我繼承別人的代碼時，我的反應很有代表性，他們到底為什么要這樣寫代碼！？難道他們沒有學過如何編程么！？除了剛剛離開的那位前任開發人員，還有誰更適合做替罪羊？（編注：伯樂在線在前段時間編譯的《程序員：你的代碼為誰而寫》一文中就說到：“要評判很久以前寫出的代碼是優是劣很不容易，因為現在已經不知道當時為什么編寫這些代碼，也不知道為誰編寫了這些代碼。”所以，這種替罪羊事情比較常見。）
幸好我比較機智，能將這些想法藏在心里。今后，我會在理解事情上更下功夫。當我繼承別人代碼時，我會假設這些代碼是開發人員在72小時內一次編碼完成的，他魔獸世界中的角色身邊到處都是蜜蜂和劫持的人質，在一切真正開始變糟之前，他只有1個小時，并且是在一臺386的機器上來完成編碼。
鑒于那些情況，難怪那個笨蛋不使用IDisposable實例附近的代碼塊。
譯文出處：伯樂在線 - 職場博客
譯文鏈接：http://www.jobbole.com/entry.php/452
原文作者：Phil Haack 編譯：伯樂在線 敏捷翻譯組 - 牛冬梅
如需轉載，但請注明原文/譯文出處、譯文超鏈接和譯者等信息，否則視為侵權，謝謝合作！
it知識庫：開發人員能夠得到的最好贊揚，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
