專家評論: Scott Johnson：做一個快樂一生的程式師
IBM WebSphere 開發者技術期刊
級別: 入門
Scott Johnson, WebSphere Application Server JSP 團隊負責人, IBM
2005 年 8 月 17 日
快樂的程式師知道自己的擅長之處，也知道在那個他/她期望的有些像天上掉餡餅一樣的工作中到底涉及到什麼。受一篇關於普通程式師急於學習程式設計的文章的啟發，作者就此與我們分享了他的觀點。
高速通道和長途旅行
就程式設計，電腦科學博士、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 就此給了一些不錯的技巧。
認識鐵三角的影響
當然，程式設計師可以進行一定的工作，以提高專案的效率。但也同樣有一些東西經常超出我們的控制範圍，從而使得項目的成功完成頗具挑戰性。請隨時謹記鐵三角，即使您的管理團隊並沒有對此引起足夠的重視，也不可大意。鐵三角描述專案的三個方面，通常定義為時間、資源和功能，這三方面共同影響專案的品質。程式設計師通常不能控制專案的這三方面，這些方面通常由市場行銷部門、公司股東、重要客戶等其他人確定。儘管程式設計師不能參與設定項目的這些方面的過程，但需要在專案進行過程中對專案的鐵三角加以注意，特別在經常出現問題時更要如此。以下內容有助於對這方面的瞭解：
透過發現軟體發展過程中效率低下的地方，使程式設計師和設計團隊成功實現目標，擺脫由於要求嚴格和資源不足帶來的限制。
從專業的角度出發，告知程式師可能是繼續進行下一步工作的時候了。
至少能夠說明，為什麼儘管大家都在努力工作、傾力而為，但要成功完成項目還是顯得如此難。
我在那家小公司工作時，該公司的管理層與全世界最受認可的一家醫療保健單位談成了一項大的業務。我們要在一年內為他們提供所需的軟體功能；需要聘傭一些新的程式設計師；這的確令人興奮。但隨後一些現實的問題開始顯現出來。透過需求分析，發現一年時間明顯不夠。然後我們又發現我們所知道的需求並不完整——他們將“逐步提出”。該公司沒有聘傭新程式設計師，但卻引入了新的專案需求，員工根本就沒有辦法處理全部的工作。
在業務達成後，我決定將項目時間延長至三年，隨後又增加了四年——總共用了七年時間——最後終於交付了最初計畫的功能程式碼。宣佈這項業務達成後的一年，這家小公司被一家大公司收購了；由於鐵三角的影響，在業務達成之前，這個項目就是金塊，而在幾年之後，卻變成了臭雞蛋。
保持簡單
在滿足需求的同時，使您的軟體設計盡可能簡單。這可能會要求放棄初期工作的成果，總結早期工作的經驗教訓，然後重新開始。這並不意味著在項目結束時才進行設計。在專案處於設計階段時就應該設計程。即使不負責進行實現，也要考慮到實現時的情況。理解過於複雜的設計（以及據此進行程式設計）需要花額外的時間和精力。作為程式師，我們處於業務需求和創建良好的設計與編寫出色的程式碼之間的中堅地帶。聘傭您進行程式設計工作的公司需要盡可能快地拿到軟體，以達成交易，獲得收益。有效簡化軟體設計的能力需要多加實踐才能獲得。但這值得化精力去學習，因為從長遠來看，這將節約時間和工作的投入量。
與他人進行良好的合作
程式設計師是團隊的一員，成功的程式設計師要能夠與其他人進行良好地合作；如果在這方面存在不足，可能會妨礙某些非常出色的人才的職業發展，因為他們很有可能被排除在較高層次的決策過程之外，而總又不能與決策者進行良好地合作，但他們帶來的價值需要掩蓋他們在組織方面的不足、羞澀或令人生厭的性格。對於我們大部分人而言，我們的才能並不能抵消這方面的缺點，因此我們必須培養良好的團隊工作能力：
首先，在本地設計程式設碼，以避免破壞生產版本。
其次，請求他人進行程式碼檢查時，要虛心接受批評，並從別人的評審中獲得思想上的最大提高。
在別人請您進行評價時（而非自己想這樣做時），提出一些建議，以進一步加強團隊合作。
對他人的出色工作予以稱讚（因為別人也能出色地完成工作），從而使團隊合作達到一個新的層次。
在適當時間主動承擔不甚舒適的工作（那些資深開發人員所進行的工作），特別在需要早起（而您夜裏工作很晚）或晚歸（如果您習慣早起）時，從而最終發展成為優秀的團隊成員。組織有時喜歡自己的員工有危機感。
知道什麼令您真正快樂
現在，軟體架構師的角色是很多程式設計師夢寐以求的。如果問從事入門級工作的年輕程式設計師他們希望做什麼，您會發現他們希望成為架構負責人，借助其很多年開發實踐積累的經驗確定整個軟體組織的方向。為什麼初級程式設計師認為自己會成為架構師呢？因為他們並不真正瞭解架構師角色的意義。
他們認為軟體架構師僅僅借助自己的技術權威領導一個團隊或更大的組織，以正確的方式設計軟體，選擇恰當的技術工具，如此等等。但架構師除了是技術角色之外，也是行政角色。很多技術專家在發現自己必須談判、和解、做生意、回復每天 200 封電子郵件，而完全放棄埋頭程式設計的快樂時，他們就不會太高興了。
對於那些希望進行人員管理工作的程式設計師而言，他們的命運也與此類似。當出現這種情況時，真正愛好程式設計的人應停下來認真地分析一下當時的情形。是否由於他們不是一個好的程式設計師才轉向管理？是否因為他們擅長程式設計，並希望從程式設計團隊的角度進行管理，才這樣做？作為程式設計管理人員，他們日常必須進行哪些工作？最重要的是，他們做這個工作時會快樂嗎？
學習技能，瞭解各種角色，瞭解自己喜歡什麼和適合自己的位置。然後，勾畫出一條美麗的人生軌跡。
文章來源 developerWorks台灣
IBM WebSphere 開發者技術期刊
級別: 入門
Scott Johnson, WebSphere Application Server JSP 團隊負責人, IBM
2005 年 8 月 17 日
快樂的程式師知道自己的擅長之處，也知道在那個他/她期望的有些像天上掉餡餅一樣的工作中到底涉及到什麼。受一篇關於普通程式師急於學習程式設計的文章的啟發，作者就此與我們分享了他的觀點。
高速通道和長途旅行
就程式設計，電腦科學博士、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 就此給了一些不錯的技巧。
認識鐵三角的影響
當然，程式設計師可以進行一定的工作，以提高專案的效率。但也同樣有一些東西經常超出我們的控制範圍，從而使得項目的成功完成頗具挑戰性。請隨時謹記鐵三角，即使您的管理團隊並沒有對此引起足夠的重視，也不可大意。鐵三角描述專案的三個方面，通常定義為時間、資源和功能，這三方面共同影響專案的品質。程式設計師通常不能控制專案的這三方面，這些方面通常由市場行銷部門、公司股東、重要客戶等其他人確定。儘管程式設計師不能參與設定項目的這些方面的過程，但需要在專案進行過程中對專案的鐵三角加以注意，特別在經常出現問題時更要如此。以下內容有助於對這方面的瞭解：
我在那家小公司工作時，該公司的管理層與全世界最受認可的一家醫療保健單位談成了一項大的業務。我們要在一年內為他們提供所需的軟體功能；需要聘傭一些新的程式設計師；這的確令人興奮。但隨後一些現實的問題開始顯現出來。透過需求分析，發現一年時間明顯不夠。然後我們又發現我們所知道的需求並不完整——他們將“逐步提出”。該公司沒有聘傭新程式設計師，但卻引入了新的專案需求，員工根本就沒有辦法處理全部的工作。
在業務達成後，我決定將項目時間延長至三年，隨後又增加了四年——總共用了七年時間——最後終於交付了最初計畫的功能程式碼。宣佈這項業務達成後的一年，這家小公司被一家大公司收購了；由於鐵三角的影響，在業務達成之前，這個項目就是金塊，而在幾年之後，卻變成了臭雞蛋。
保持簡單
在滿足需求的同時，使您的軟體設計盡可能簡單。這可能會要求放棄初期工作的成果，總結早期工作的經驗教訓，然後重新開始。這並不意味著在項目結束時才進行設計。在專案處於設計階段時就應該設計程。即使不負責進行實現，也要考慮到實現時的情況。理解過於複雜的設計（以及據此進行程式設計）需要花額外的時間和精力。作為程式師，我們處於業務需求和創建良好的設計與編寫出色的程式碼之間的中堅地帶。聘傭您進行程式設計工作的公司需要盡可能快地拿到軟體，以達成交易，獲得收益。有效簡化軟體設計的能力需要多加實踐才能獲得。但這值得化精力去學習，因為從長遠來看，這將節約時間和工作的投入量。
與他人進行良好的合作
程式設計師是團隊的一員，成功的程式設計師要能夠與其他人進行良好地合作；如果在這方面存在不足，可能會妨礙某些非常出色的人才的職業發展，因為他們很有可能被排除在較高層次的決策過程之外，而總又不能與決策者進行良好地合作，但他們帶來的價值需要掩蓋他們在組織方面的不足、羞澀或令人生厭的性格。對於我們大部分人而言，我們的才能並不能抵消這方面的缺點，因此我們必須培養良好的團隊工作能力：
知道什麼令您真正快樂
現在，軟體架構師的角色是很多程式設計師夢寐以求的。如果問從事入門級工作的年輕程式設計師他們希望做什麼，您會發現他們希望成為架構負責人，借助其很多年開發實踐積累的經驗確定整個軟體組織的方向。為什麼初級程式設計師認為自己會成為架構師呢？因為他們並不真正瞭解架構師角色的意義。
他們認為軟體架構師僅僅借助自己的技術權威領導一個團隊或更大的組織，以正確的方式設計軟體，選擇恰當的技術工具，如此等等。但架構師除了是技術角色之外，也是行政角色。很多技術專家在發現自己必須談判、和解、做生意、回復每天 200 封電子郵件，而完全放棄埋頭程式設計的快樂時，他們就不會太高興了。
對於那些希望進行人員管理工作的程式設計師而言，他們的命運也與此類似。當出現這種情況時，真正愛好程式設計的人應停下來認真地分析一下當時的情形。是否由於他們不是一個好的程式設計師才轉向管理？是否因為他們擅長程式設計，並希望從程式設計團隊的角度進行管理，才這樣做？作為程式設計管理人員，他們日常必須進行哪些工作？最重要的是，他們做這個工作時會快樂嗎？
學習技能，瞭解各種角色，瞭解自己喜歡什麼和適合自己的位置。然後，勾畫出一條美麗的人生軌跡。
文章來源 developerWorks台灣
來膜拜吧，這兩個才稱得上宅！！
