2014/1/15

我眼中的 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 是什麼樣子。