我眼中的 pro programmer

一個 pro programmer 工作者，在 team leader 的眼中，存在著某些決定性的條件，而以下是我個人認定，專業 Programmer 所該存在的幾項條件。

smart copy-and-paste coder

大部分的 programmer 都必須上網翻閱問題與資料，有時候可以直接找到其他人做的解決方案，有可能是個簡短的 hack，或是套用某個 library。

如果有製作一個完整功能經驗的programmer，不管是 library或是獨立的 APP，通常會發現，如果開發的時候，手上只有一份規格文件，以這樣的基礎去開發時，會遭遇到許多困難。這時如果已經有人把功能做出來了，直接閱讀他的範例，問題就解決一大半了。

smart copy-and-paste 並不是看到什麼就照抄，除了一些特殊的 hack codes 之外，搜尋到解決方案或 coding 方法之後，必須要先看懂別人寫什麼，然後再「適當」地套用在自己的專案上，不懂 code 的內容，閉著眼睛照抄，可能會帶來一些無法理解的副作用，還會落下一句「我不知道為什麼會這樣！」，不懂得前因後果就照抄是絕對不行的。

bug-free codes producer

基本上如果是 Java 這種 Strong Typed 語言，程式在編譯時，就已經檢查掉不少基本的語法錯誤了，而 bug 的發生，最常見的原因就是 programmer 「偷懶」，例如：method 的參數會發生 NullPointerException，就是 programmer 偷懶沒有寫檢查，因為他自己「假設」這個欄位不會是 null，或是一些參數，送入了預期之外的數值。

多寫幾行程式，就可以降低發生問題的機會，產出品質更高的 codes，如果實作時隨時都想偷懶，自己做了太多「假設」，bug-free codes 永遠都在遙遠的夢想中，尤其是business method 的界面與網頁 API 界面的參數限制。

有個概念是，越多程式碼，發生問題的機會越高，這也沒錯，但那是指業務邏輯的部份，在做程式分析時，必須想辦法釐清業務邏輯，以最精簡的判斷方式撰寫，一堆繞來繞去又重複檢查的程式邏輯，既會讓人讀不懂，又會增加發生錯誤的機會。

defect digger

每個系統都有自己的歷史包袱，有很多商業邏輯跟假設隱藏在裡面，資料庫的資料，也會有很多邏輯上的相關之處，例如，當 programmer 被分配到實作「為系統實作多國語言」這個功能時，可能只會想到，要修改界面上顯示的文字，但可能還有錯誤訊息，錯誤頁面要處理，錯誤訊息有可能是寫在 Server 直接傳送給 Client，或是系統發送給使用者的 email或通知，這些全部都得考慮多國語言。

重要的是，programmer必須要想到，因為這個功能，有可能影響到的所有其他的功能，在實作該功能的時候，要同時去檢查，有沒有影響到這些功能，或是反過來詢問 leader，這可能是一開始沒有考慮到的相關問題，該怎麼處理，把需求處理做得更完整。

考慮越周全，自然就能挖到更多系統的 defects。 如果 prgrammer 想說，這是 leader 下達的指令不夠周全，我只要照著要求的內容，去改寫程式就好了。這不是專業 programmer 該有的想法，因為 programmer 會是直接接觸程式碼的人，他可以從程式碼，去反向找到系統中所有相關的功能，熟悉系統商業邏輯的人，雖也可以做到類似的事情，但總是間接想到，也只能說「有可能」會影響到某某功能。

problem resolver/terminator

程式的問題可以分成兩種，一種是 bug，程式跑一跑，出現了奇怪的結果，一種是新功能，沒有人做過，不知道怎麼寫。

當程式遇到bug時，第一時間要做的，是懷疑自己是不是有考慮不周全的地方，也要思考，是不是自己的想法與寫法，或是程式的邏輯順序有問題，以此為前提，再往下深入去尋找，是不是有別的方法，可以解決這個問題。

要能被交代處理新功能，某方面就代表說，這個 porgrammer 是受信任，可以找到解決新問題的方法。一個能解決問題的人，總比一直製造問題、產生bug的人來得討人喜歡，且能受重用。

good communicator

當遇到問題你不知道怎麼處理時，除了問google之外，最快的方式是先問問同事，可能已經有人處理過類似的狀況。問問題，不是把問題丟出去就好了，你必須要讓其他人感受到你的責任感，問的時候，要加上自己的觀察，聽的時候，要思考並從回答中，找出模糊地帶，再繼續追問下去。

定期會議或是每天的站立會議，必須要把自己的狀態、進度，有沒有遇到特別的狀況卡住很久了，需不需要幫忙，這些重點事項言簡意賅地說明清楚。

如果有機會面對了客戶，為求專案順利在跟客戶打交道拉關係的前提下，必須跟客戶保持適當的距離，客戶的需求一定要經過 PM 才能接受。

心裡有什麼疙瘩，或是覺得團隊有什麼狀況，要直接跟 leader 或其他同事溝通，悶在那邊是無濟於事的。

aggressive learner, conservative implementater

積極地學習新的技術並了解新的工具與概念，但在團隊合作上，卻要採取比較保守的方式，而不是學了一樣新東西，就想在專案上實驗並套用上去。

新技術相對就帶來了新的風險，當專案時程游刃有餘，或是在前期的研究階段，新技術的測試與實驗是必要且有效的，但在處理舊專案時，必須適當地遷就舊有的程式碼，因為這些程式都是經過多次測試驗證的結果，沒有相當大的好處，或是有絕對的理由，不能輕易放棄既有的東西，但相對地，一旦確認有足夠要放棄的理由，也要義無反顧，適當的提出建言與舉證，強烈地建議要除舊佈新。

good job handler

明確掌握自己的工作進度與心理的狀態，如果有卡住一段時間的問題，主動去問問同事或 leader，自己悶著頭去做，只會讓團隊其他人搞不清楚你在做什麼。做的事情、研究的東西都必須讓團隊確實掌握。

除了自己的狀態，還要注意其他人的進度與狀態，整體的進度必須跟著團隊前進，如果自己落後了，要及時反應狀況，由leader決定需不需要其他人的支援，當然進度超前時，也要及時回報，由leader分配其他的工作。

industrious but agile documentator

在實作某些功能前，前期的業務分析結果，還有一些開發期間用來測試與驗證的 sql & test scripts，必須要確實地紀錄在專案的文件區裡面，而程式碼中，撰寫註解要勤快，撰寫文件與註解並不是無限上綱，規定每一個method、每一個參數、每一個邏輯判斷都要寫上註解，而是要在適當的時機去做這件事，當發覺自己花了一段時間，才釐清該怎麼撰寫時，就是個明確要寫下文件的時機點，寫文件，沒有標準的格式，要以自己認為最適當的方法記錄下來。

rush but careful stepper

積極且迅速的工作效率，但同時也要步步為營，把每一件相關的工作都做好。

如果 leader 每一次來問，都回應說做好了，但是「做好」多少的程度雙方的認知會有落差，通常 leader 認定的做好了，是指都全部測試過，都正常了，而 programmer 認定的做好了，是我把這個 task 完成了，這個 task 也測試過了，但改完這個會不會影響到其他地方，這就跟我無關了。

leader 說的都是針對整個系統，programmer 說的常都是針對某一個工作，因此當 programmer 回應給 leader 時，要清楚地告知有沒有測試，測試了多少項目等等附帶的資訊與條件，leader也會根據這些資訊，得到下一個階段工作的重點項目，或是決定某一個大範圍重新測試的時間點。

結語

當個 team member 跟 leader 的心情與想法是截然不同的，「換個位置就會換個腦袋」，這種情況是無可厚非的，只能說，不管自己在什麼位置，要時時提醒自己，換個角度去看這些事情，自然就可以轉換自己的心情與想法。

其實 team leader 掌握團隊的時候，同時也必須扮演 boss 的手下的角色，也需要一些角色轉換的技巧，才有辦法在這兩者之間，動態自由地轉換。

下次或許該找個人，談一談在他眼中一位 pro team leader 是什麼樣子。