我最感到幸運的，是這一路上遇到幾個願意帶我的師傅。其中一個待我相當嚴苛（當時我常常心裡有很多抗拒），然而現在回想起來，卻也從他身上學到、領悟許多。其中他讓我體悟到影響至深、最重要的一點，不是技術，而是某些做事態度，尤其是『程式交接』這件事。
所有工作職務交接，複雜度與困難度最高的前幾類型，我相信軟體程式絕對是其中之一。由於軟體程式天生的易變性與複雜度，身在這個領域中，一定能領悟維護前人留下的系統是多麼困難的一件事情（不管有沒有文件都一樣，因為文件不可信）。『垃圾』、『遺產』、『打掉重練』這些常用詞句在這個領域盛行之程度，完全可以反映這個領域要能成功的完成『交接』是多麼困難的一件事情。
所以，軟體公司最重要的資產是『人』，工程師的流動率絕對不只是影響薪資開銷，而是會連帶影響公司現有系統的價值，原本可以維護修改的系統只因為一個關鍵人員流失，就變成沒人敢動的不動產（所以除了作案子打帶跑或是販賣工程師人力的資訊公司以外，其實一般軟體公司都不太受 22K 風氣影響，老板通常會盡可能想辦法留住人員）。
記得這個師傅開始帶我時，很快就丟給我一個前人的遺產（Legacy component）：「Tom，這支程式以後交給你負責。」
「好。」除了程式碼，這東西什麼文件都沒有。但當時我想都沒想，就傻傻地答應了。
反正一個客戶普遍用了幾年的元件，凍結了多年未動，應該沒啥大事啦～。
沒想到，接下這遺產沒幾天，客戶就遇到問題。師傅打開程式碼專案 review，指著被報出問題的那段程式碼嚴厲地對著我說：「Tom，這地方寫什麼鬼？為什麼可以這樣寫！？」
「那又不是我寫的啊⋯。」
師傅雙眼緊盯著我：「那天我說這東西交給你『負責』對吧？而你也答應了。那你現在這樣回答，是在『推卸責任』還是在『負責任』？不管這是不是你寫的，你接下了，這些就全部都是你的 code！」
「ㄜ ⋯⋯。」小丸子的三條線。
「我再問你一次：這裡為什麼可以這樣寫？」師傅的眼神更嚴厲了。
「給我一點時間研究一下，等下回答你。」我立刻埋首，花了不知多少時間，trace 整份程式碼，就算沒有全懂，也把這來龍去脈搞清楚七八成。
這次經驗之後，我知道不管接手什麼東西，我都不能以：「這當初不是我做的。」這樣的理由來搪塞，唯一能做的，只有兩件事：要就徹底把它從頭到尾看懂、要就把難懂部分用自己能理解的方式重寫。
目標只有一個：讓自己百分百掌握接手的這個東西。
最近帶的團隊，雖然沒有人員流失的問題，但因為工作模式與任務導向的改變，所有人都面臨要接手其他人產出的程式。當天分派好所有模組的領養人，我就把上面的故事講給所有組員聽，之後強調：
「我要說的，是從現在開始，你只有想辦法怎麼讓自己扛起來，沒有藉口說：這是某某某寫的，我不清楚。不懂？就去問原作者問到懂。」
「我要說的，是從現在開始，你只有想辦法怎麼讓自己扛起來，沒有藉口說：這是某某某寫的，我不清楚。不懂？就去問原作者問到懂。」
很慶幸從那天起，目前接手的組員表現狀況都算良好⋯，除了一個某元件外。
系統內目前有個構造精巧，複雜度極高的核心元件，最近頻頻被爆出許多邏輯的漏洞。然而這個元件的歸屬權已經易手，但原作者因為擔心此次的修正難度太高，所以又接回去自己修正完後歸還。
接班人跟我反應：「那東西內部現在變得非常亂，有些地方我真的看不懂為什麼要這樣寫，這樣的東西我真的不敢接手維護。」
曾經我表達過：真的怎麼都看不懂的地方就用你能懂的方式改寫，否則你怎麼樣都無法負起責任，最後只會有受害（被迫承擔）的感受。
但這其中參雜了『接班人是否要尊重原作者的堅持和設計？』的人際問題（若原作者已離職當然就沒這樣的顧慮）。
事實上這次的修正，原作者已經因為擔心接班人無法勝任而帶回去自己處理，這已經很明顯地暴露這東西的『交接障礙』，雙方其實都心知肚明。真正的交接，不該是有出問題就只能靠原作者處理再歸還。
當然，對工程師而言，自己寫出的程式就像自己懷胎生下的孩子，若看到被別人改成不是自己期望的樣子，有時難免會有些感受上的失落或不舒服。但是既然決定好責任的交接，就該真正放手才能讓另一方真正扛起。
每次程式交接，若接班人可以從原作者那邊理解、接收到 70% 的知識，這已經是非常優秀難得的狀況（過去經驗大部份只看到 50% 以下），剩下 30% 是真的極困難理解。若每個接班人都不透過『重構』來解決那 30% 無法維護的部分，那再下一任的接班人就只剩下 49%（70% * 70%）對手上東西不到一半的理解度！更遑論再下一任的接班人，或是那些從剛開始接手就低於 70% 理解度的東西了！
東西會演變成遺產或是只能打掉重練的演化，就是依循著這樣的交接品質而來的！
身為接班人，我們唯一能做的，就是想辦法讓手中的 70% 透過自己理解的方式重構來提升到 100%，這樣下一次的交接，至少還能再保持 70% 的知識傳承出去，如此問心無愧後，剩下就看下一任有沒有那個肩膀和他自己的造化了。
若每次交接都能做到這樣，系統的知識就能保持在 100% -> 70% -> 100% -> 70% -> 100% 這樣的健康循環，而不是變成 100% -> 70% -> 49% -> 34% -> ... 打掉重練的遺產，這樣的循環。
若每次交接都能做到這樣，系統的知識就能保持在 100% -> 70% -> 100% -> 70% -> 100% 這樣的健康循環，而不是變成 100% -> 70% -> 49% -> 34% -> ... 打掉重練的遺產，這樣的循環。
為了隨時培養系統的接手人員，我設計了一份投影片範本，讓每個系統的 owner 負責完成，並一這份投影片對所有人進行教育訓練。這份投影片範本在此分享給大家作為參考，也歡迎大家給予各種回饋與補充意見：
對於如何做好『系統程式交接』，你們會怎麼做呢？歡迎大家分享討論。
不好意思，工商服務一下。
目前我所在的團隊正招募 DB Developer 成員：
熟悉 MSSQL 2005 以上版本的 DB Developer
地點：台北市永春捷運站附近
新創公司、工作富挑戰性、待遇優渥
生涯規劃、轉職的最佳選擇，有興趣的請傳訊或 MAIL 給我
沒有留言:
張貼留言