文/Scott Johnson, WebSphere Application Server JSP 團隊負責人, EMC

　　英文原文：Scott Johnson: Take a lifetime to be a good (and happy) programmer

　　高速通道和長途旅行

　　就編程實踐，計算機科學博士、Google 的 Search Quality 總監寫了一篇很不錯的文章，名為“Teach Yourself Programming in Ten Years”。這篇文章中提出了一個大問題：為什么人們這樣急于學習編程呢？是因為他們希望能夠速成呢，還是因為大家認為計算機是最容易學習的？不管什么原因，做一個好的程序員并非快速學習的結果，而需要深入認真學習，并需要明智地選擇學習的內容。關于這點，本文給出了六條建議，供那些準備開始（或已經開始）用一生的時間實現做個好程序員的夢想的人參考。

　　通過好的例子學習

　　有些程序員很幸運。他們有良師指導，能告知他們成功解決軟件設計和編碼的各種成功方法。他們學習了如何區分設計的好壞，如何辨別健壯的實現與不可靠的實現。他們的導師還對如何在編程領域謀得良好的職業生涯給出了建議，而且他們還了解了如何才能獲得成功和認可，應該接手哪些項目，應該避免參與哪些項目。

　　有良師的指導效果非常好，而且很有必要。如果有兩個程序員，并給其中一個指派了好的導師，有人指導的程序員將不斷進步，而沒有人指導的程序員則可能會手足無措地原地踏步。

　　通過反面例子學習

　　不過，如果沒人指導的程序員了解如何“自救”，他便能夠發現學習編程實踐技巧的很多其他方法。通過閱讀他人編寫的代碼就是一種所有程序員在其職業生涯中都可以采用的方法，而幾乎所有的新程序員在進行代碼維護時都不得不進行這樣的工作。

　　在我早期所做的一份編程工作中，在維護我的新上司編寫的代碼時，我學到了不應該做什么。這個上司是一家正在快速發展的小公司的老板之一，但并不是一個好老師。我們主要用 FORTRAN 進行編碼，我進這家公司的時候，他已經編寫了很多代碼。他使用的變量名稱都是 a、b、c、aa、bb、cc，諸如此類。我那時剛開始學習 FORTRAN，但即使這樣，我也明顯地覺得這種方式很不好。他還通過將這些變量放入 FORTRAN 公共代碼塊中，使其成為全局變量，這很明顯是太糟糕了。這樣做就不能在源代碼樹中搜索變量以進行重命名，也不能對它們進行任何處理。據我所知，當時并沒有良好的 FORTRAN 集成開發環境可用于幫助處理這種情況，因此我對很多這樣的代碼進行了手工清理，并保證編寫更好的新代碼——從良好的變量名稱開始。

　　從這個反面例子中，我們知道了：要編寫可讀性好的代碼；包、類、方法和變量的名稱要反映出其功能；避免采用最流行的命名約定，等等。在上個世紀 90 年代，我嘗試過在 C++ 中使用匈牙利標記法，而現在我非常贊同在 Java™ 標識符前使用 m_。對這些構件進行適當的命名是進行良好編碼的基礎。恰當的命名不但有助于構建良好穩健的體系結構，還可以幫助其他人理解您的代碼。但要進行恰當地命名并不容易，Tim Ottinger 就此給出了一些不錯的技巧。

　　認識鐵三角的影響

　　當然，程序員可以進行一定的工作，以提高項目的效率。但也同樣有一些東西經常超出我們的控制范圍，從而使得項目的成功完成頗具挑戰性。請隨時謹記鐵三角，即使您的管理團隊并沒有對此引起足夠的重視，也不可大意。鐵三角描述項目的三個方面，通常定義為時間、資源和功能，這三方面共同影響項目的質量。程序員通常不能控制項目的這三方面，這些方面通常由市場營銷部門、公司股東、重要客戶等其他人確定。盡管程序員不能參與設定項目的這些方面的過程，但需要在項目進行過程中對項目的鐵三角加以注意，特別在經常出現問題時更要如此。以下內容有助于對這方面的了解：

1. 通過發現軟件開發過程中效率低下的地方，使程序員和編程團隊成功實現目標，擺脫由于要求嚴格和資源不足帶來的限制。
2. 從專業的角度出發，告知程序員可能是繼續進行下一步工作的時候了。
3. 至少能夠說明，為什么盡管大家都在努力工作、傾力而為，但要成功完成項目還是顯得如此難。

　　我在那家小公司工作時，該公司的管理層與全世界最受認可的一家醫療保健單位談成了一項大的業務。我們要在一年內為他們提供所需的軟件功能；需要雇傭一些新的程序員；這的確令人興奮。但隨后一些現實的問題開始顯現出來。通過需求分析，發現一年時間明顯不夠。然后我們又發現我們所知道的需求并不完整——他們將“逐步提出”。該公司沒有雇傭新程序員，但卻引入了新的項目需求，員工根本就沒有辦法處理全部的工作。

　　在業務達成后，我決定將項目時間延長至三年，隨后又增加了四年——總共用了七年時間——最后終于交付了最初計劃的功能代碼。宣布這項業務達成后的一年，這家小公司被一家大公司收購了；由于鐵三角的影響，在業務達成之前，這個項目就是金塊，而在幾年之后，卻變成了臭雞蛋。

　　保持簡單

　　在滿足需求的同時，使您的軟件設計盡可能簡單。這可能會要求放棄初期工作的成果，總結早期工作的經驗教訓，然后重新開始。這并不意味著在項目結束時才進行設計。在項目處于設計階段時就應該編寫代碼。即使不負責進行實現，也要考慮到實現時的情況。理解過于復雜的設計（以及據此進行編碼）需要花額外的時間和精力。作為程序員，我們處于業務需求和創建良好的設計與編寫出色的代碼之間的中堅地帶。雇傭您進行編程工作的公司需要盡可能快地拿到軟件，以達成交易，獲得收益。有效簡化軟件設計的能力需要多加實踐才能獲得。但這值得化精力去學習，因為從長遠來看，這將節約時間和工作的投入量。

　　與他人進行良好的合作

　　程序員是團隊的一員，成功的程序員要能夠與其他人進行良好地合作；如果在這方面存在不足，可能會妨礙某些非常出色的人才的職業發展，因為他們很有可能被排除在較高層次的決策過程之外，而總又不能與決策者進行良好地合作，但他們帶來的價值需要掩蓋他們在組織方面的不足、羞澀或令人生厭的性格。對于我們大部分人而言，我們的才能并不能抵消這方面的缺點，因此我們必須培養良好的團隊工作能力：

1. 首先，在本地編譯代碼，以避免破壞生產版本。
2. 其次，請求他人進行代碼檢查時，要虛心接受批評，并從別人的評審中獲得思想上的最大提高。
3. 在別人請您進行評價時（而非自己想這樣做時），提出一些建議，以進一步加強團隊合作。
4. 對他人的出色工作予以稱贊（因為別人也能出色地完成工作），從而使團隊合作達到一個新的層次。
5. 在適當時間主動承擔不甚舒適的工作（那些資深開發人員所進行的工作），特別在需要早起（而您夜里工作很晚）或晚歸（如果您習慣早起）時，從而最終發展成為優秀的團隊成員。組織有時喜歡自己的員工有危機感。

　　知道什么令您真正快樂

　　現在，軟件架構師的角色是很多程序員夢寐以求的。如果問從事入門級工作的年輕程序員他們希望做什么，您會發現他們希望成為架構負責人，借助其很多年開發實踐積累的經驗確定整個軟件組織的方向。為什么初級程序員認為自己會成為架構師呢？因為他們并不真正了解架構師角色的意義。

　　他們認為軟件架構師僅僅借助自己的技術權威領導一個團隊或更大的組織，以正確的方式設計軟件，選擇恰當的技術工具，如此等等。但架構師除了是技術角色之外，也是行政角色。很多技術專家在發現自己必須談判、和解、做生意、回復每天 200 封電子郵件，而完全放棄埋頭編程的快樂時，他們就不會太高興了。

　　對于那些希望進行人員管理工作的程序員而言，他們的命運也與此類似。當出現這種情況時，真正愛好編程的人應停下來認真地分析一下當時的情形。是否由于他們不是一個好的程序員才轉向管理？是否因為他們擅長編程，并希望從編程團隊的角度進行管理，才這樣做？作為編程管理人員，他們日常必須進行哪些工作？最重要的是，他們做這個工作時會快樂嗎？

　　學習技能，了解各種角色，了解自己喜歡什么和適合自己的位置。然后，勾畫出一條美麗的人生軌跡。

　　關于作者

　　Scott Johnson 從事專業編程工作 22 年。他目前在 WebSphere Application Server 的開發團隊工作，是 JavaServer Pages 容器團隊的負責人、WebSphere 基礎體系結構委員會的助理架構師，同時還是任 JSR 245、JavaServer Pages 2.1 規范的 IBM 代表。