等重構完這系統,我就辭職

codebay發表於2018-07-27

作者:五五

白天搬磚,晚上砌夢想。相信每個人有故事,程式設計師更是有許多事故,書寫最接地氣的程式設計師故事。

Part.1

為什麼程式設計師一言不合就重構程式碼?

當你看到前任寫成一團毛球的程式碼塊;新增幾行程式碼需先捋半天邏輯的超級大函式;好不容易在迷宮裡找到方向,小心翼翼地新增上新程式碼,卻將別的呼叫系統給弄垮時;還有執行緩慢的老系統……

此時程式設計師只有兩個選擇:要麼忍,要麼重構。

忍是有極限的,重構的“三次法則”表示:程式設計師第一次看到亂程式碼可以繞過去,先將手上的程式碼堆好;第二次再碰上這塊,心裡雖反感但再一次勉強繞過;第三次肯定忍不住動手。

以下的場景是不是很熟悉:

測試:這麼小的功能,你為什麼改動300多個檔案?

開發:嘿嘿嘿,我順便將老程式碼挪了地方。

測試:你知道這給我增加多少測試工作量嗎?那些我都得迴歸一遍。

開發:不用測試,沒有風險的,我就整理下程式碼。

測試:你上次也這麼說,結果偷偷改了某介面,影響到下游系統。還有那次啊你……

產品:你又在弄重構?我這還有一大堆需求沒人開發。

開發:我這的重構系統也非常重要的。

產品:哪裡重要了?你浪費這麼多人力重構,使用者也看不出來系統有什麼變化,搞不好還弄壞老功能。求求你別重構了。

開發:我……

雖然重構不被其他角色認可,但你的程式設計師同事會理解和感謝你的,重構是優化程式碼設計,使程式碼可讀性更強。

只是重構是個大坑,不小心就掉坑裡。

Part.2

“等重構完這個系統,我就提離職。”龍哥說。

由於核心系統初期設計不當,權責界限模糊,只要沾點邊的程式碼都往上堆,造成系統過於龐大,邏輯混亂,一出現問題,造成核心業務癱瘓。

過老過大過中心的系統像個不定時炸彈,吃過幾次虧後,業務組決定拔掉這隱患:將系統重構,按照業務處理邏輯拆分成各功能單一的子系統,降低耦合度。

大夥把這事當作季度最重要的計劃來開展:熱火朝天的開會劃分系統,梳理程式碼邏輯,安排測試,宣告注意事項。

各人領了任務後,開始埋頭苦幹起來。

但是重構系統像從一個大迷宮捋線路,捋的過程耗費巨大,而且極易遺漏。產品後來提的新需求直接在重構後的系統裡新增。開發團隊進入惡性迴圈:新增功能有的人在老系統分支改,有人在新的改,導致提交的程式碼分支混亂,搭建過程緩慢,計劃的任務delay,最後測試人員發現很多遺漏點,又返工重構。

大家不斷埋頭地捋程式碼,重構,測試,想百分百完美地完成任務,而忽略整體專案進度的把控。

上線時間從9月份推遲到12月份,再到年後,最終來年6月份系統才上線完成,耗時一年多。

每個人被重構折磨得疲憊不已,還短時間看不出來效果,可已經投入人力物力,大家只好硬著頭皮往下走。

後來大家已經想不起當初為什麼要重構,到底要重構到什麼樣子,只想著這重構何時到頭,什麼時候才能解放。

從重構半年時開始有人離職,到上線時僅剩一個原專案組的產品,他說這專案終於結束,我也該走了。

Part.3

上面的重構沒有合理的專案規劃,還犯了重構的大忌:邊重構程式碼邊新增功能,這樣相當於將原系統推翻重做,風險極大。

那麼該如何合理的安排重構呢?

1.遵循“兩頂帽子”重構原則

在重構時,兩個不同的操作分開進行:重構程式碼和新增功能。

先在不改變原系統功能的基礎上修改現有程式碼的設計,這樣採用原有的測試方法可以輕鬆地驗證這些修改的正確性。

再在已重構好的基礎上增加新功能,使得新功能與老功能合理解耦。

上述例子裡,業務組邊重構邊在上面新開發功能,給測試人員的壓力巨大,原有的測試方法全不適用,增加回歸測試工作量。

2.使用“小步快跑”的重構策略

重構避免使用“大布局”規劃專案程式,如果從整理需求、設計介面、開發聯調、測試上線,經歷幾個月的時間,如果其間有問題,整個團隊又得人仰馬翻地去調整方向,試錯成本過高。

“小布快跑”是讓我們重構時只關注一個問題點,只解決這一個問題。小改動,小區域性優化,耗時短,見效快。

這便需要我們將重構當作一個習慣,融入在每一次程式碼修改中。

3.測試驅動開發

上文例子裡將程式碼的質量保證全丟給測試人員,光是對整個系統介面的效能測試就耗費大半個月的時間,等測試人員將問題列表整理後又得重新改程式碼,不單浪費時間,還可能引入大風險。

正確的重構姿勢是將測試融入在每一次重構中,小步快跑,修改一塊程式碼便自測這塊,等調通後再繼續往下走。重構有風險,開發測試兩手捉。

《重構》一書裡說道:任何一個傻瓜都能寫出計算機可以理解的程式碼,唯有寫出人類容易理解的程式碼,才是優秀的程式設計師。

相關文章