2013年8月24日 星期六

你這是負責任或推責任?談『系統程式交接』


        我最感到幸運的,是這一路上遇到幾個願意帶我的師傅。其中一個待我相當嚴苛(當時我常常心裡有很多抗拒),然而現在回想起來,卻也從他身上學到、領悟許多。其中他讓我體悟到影響至深、最重要的一點,不是技術,而是某些做事態度,尤其是『程式交接』這件事


        所有工作職務交接,複雜度與困難度最高的前幾類型,我相信軟體程式絕對是其中之一。由於軟體程式天生的易變性與複雜度,身在這個領域中,一定能領悟維護前人留下的系統是多麼困難的一件事情(不管有沒有文件都一樣,因為文件不可信)。『垃圾』、『遺產』、『打掉重練』這些常用詞句在這個領域盛行之程度,完全可以反映這個領域要能成功的完成『交接』是多麼困難的一件事情

        所以,軟體公司最重要的資產是『』,工程師的流動率絕對不只是影響薪資開銷,而是會連帶影響公司現有系統的價值,原本可以維護修改的系統只因為一個關鍵人員流失,就變成沒人敢動的不動產(所以除了作案子打帶跑或是販賣工程師人力的資訊公司以外,其實一般軟體公司都不太受 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% -> ... 打掉重練的遺產,這樣的循環

        為了隨時培養系統的接手人員,我設計了一份投影片範本,讓每個系統的 owner 負責完成,並一這份投影片對所有人進行教育訓練。這份投影片範本在此分享給大家作為參考,也歡迎大家給予各種回饋與補充意見:


對於如何做好『系統程式交接』,你們會怎麼做呢?歡迎大家分享討論。 

不好意思,工商服務一下。

目前我所在的團隊正招募 DB Developer 成員:

熟悉 MSSQL 2005 以上版本的 DB Developer

地點:台北市永春捷運站附近

新創公司、工作富挑戰性、待遇優渥

生涯規劃、轉職的最佳選擇,有興趣的請傳訊或 MAIL 給我

Google+ Badge