程式設計師能夠得到的最好讚揚

原文作者 Phil Haack 從1997年開始從事軟體開發，曾擔任微軟的 ASP.NET MVC 框架的高階專案經理，另外也負責ASP.NET的部分特性。Phil 認為：開發人員能夠獲得的最大讚揚，就是其他開發人員的給予的讚揚。即：同行的讚揚！

---

作為軟體開發人員，有一個小祕密：不管你寫的程式碼有多麼優秀，對另外一位開發人員來說，都毫無用處。

如果程式碼足夠“乾淨”，你都可以吃程式碼上面的壽司，這沒什麼。如果每次程式碼顯示在螢幕上時，約翰·卡馬克（John Carmack）和Linus Torvalds都對這些程式碼都佩服的五體投地，這也沒什麼。但一些開發人員稱這些程式碼是垃圾，而這些人通常就是你離開之後接手你程式碼的人。

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

• 在方法/函式中，你使用了字串串聯，而不是StringBuilder類。所以，如果這種情況發生，那麼做出這樣的決定就是有意的，因為一般這樣的演算法只會串聯3到4個字串。下一個開發人員才不關心這些。
• 沒有按照規定把花括號放到應該放置的那一行，而是放到了同一行（反之亦然）。
• 使用了switch語句，但大家（包括下一個開發人員）都認為應當將其替換為狀態或者策略模式。難道你沒讀過《設計模式》這本書嗎？不要因為只有一個switch語句導致沒有程式碼重複而擔心。
• 在依賴注入（Dependency Injection）技術上，你採用Spring.NET，但下一個開發人員更喜歡使用Windsor。他們認為只有白痴才使用Spring.NET（反之亦然）。
• 或者你自始至終一直都在採用依賴注入技術。依賴注入到底是什麼鬼東西？現在我完全看不懂程式碼！:(

儘管我們為完美程式碼而努力，但在真正的專案開發中，這是很難實現的。因為程式碼會受諸如時間壓力之類的約束限制。不幸的是，從程式碼中看不出約束來， 看到的只是這些約束造成的影響。當下一個開發人員閱讀你的程式碼時，他們是看不出這些程式碼是在專案釋出前的剩餘1小時內完成的。

然而我承認，在被誤導性評論中傷之前，很難不先對這類評論採取一些措施，比如通過註釋在程式碼中新增一些約束。

例如：

這樣的防衛看起來有點過分，不過分？在註釋中說明為什麼制定一個特殊的、不明顯的設計方案，這沒什麼問題。事實上，這也正是註釋的作用所在，而不是為了簡單地重述一下程式碼做了什麼。

然而問題是，開發人員有時候彼此之間的制約很大，你用綠色寫論述（或者你的整合開發環境中註釋對應的任何一個顏色）來標明每一行程式碼，因為你不知道對下一個開發人員來說，什麼才算是明顯的。

這也是為什麼前幾天收到一個開發人員的電子郵件我非常高興的原因。這個開發人員繼承了我寫的一些程式碼，並在郵件中評價了我的解決方案，在這裡我引用他的原話：“寫的非常棒”。

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

這很可能是你從別的開發人員那得到的最高稱讚。而且我認為這不是因為我真的是這樣一個卓越的開發人員。我認為真正應該讚揚的人是那位給出稱讚的開發人員。

我的意思是，當我繼承別人的程式碼時，我的反應很有代表性，他們到底為什麼要這樣寫程式碼！？難道他們沒有學過如何程式設計麼！？除了剛剛離開的那位前任開發人員，還有誰更適合做替罪羊？（編注：伯樂線上在前段時間編譯的《程式設計師：你的程式碼為誰而寫》一文中就說到：“要評判很久以前寫出的程式碼是優是劣很不容易，因為現在已經不知道當時為什麼編寫這些程式碼，也不知道為誰編寫了這些程式碼。”所以，這種替罪羊事情比較常見。）

幸好我比較機智，能將這些想法藏在心裡。今後，我會在理解事情上更下功夫。當我繼承別人程式碼時，我會假設這些程式碼是開發人員在72小時內一次編碼完成的，他魔獸世界中的角色身邊到處都是蜜蜂和劫持的人質，在一切真正開始變糟之前，他只有1個小時，並且是在一臺386的機器上來完成編碼。

鑑於那些情況，難怪那個笨蛋不用using 把IDisposable例項包起來。

 

英文：Phil Haack　　編譯：伯樂線上/牛冬梅