歌頌程式維護人員

TP_funny發表於2014-12-24
追溯到 1984 年,我剛剛畢業,準備受聘於開發人員的職位。我被一家跨國公司僱傭了……很快被安排到了現有應用程式的維護小組。在當時,這個決定貌似合情合理。現在回顧起來,真的很蠢。實際上,一個更好的描述應該是“瘋狂至極”。

維護比新的開發工作要更加艱難。把我這種剛畢業的、“乳臭未乾”的開發人員放在維護現有應用程式的工作上,就像讓剛畢業的醫學院學生為總統做腦部手術—有理智的人都不會這樣乾的。我當時維護的現有應用程式在支撐著公司;另一方面,在開發的應用程式與公司運作關係不大(儘管它們對公司的未來有一定影響)。

開發中的系統與生產環境上的系統的區別,取決於一個關鍵特徵:如果開發中的系統崩潰了,沒人會在意的。另一方面,如果你搞砸了生產環境上的系統,很多人都會來找你,而他們以前都懶得留意到你(我們不想問,我是怎樣知道的)。

我現在明白了把我放在維護位置上的、邏輯上的真實原因了:公司 IT 部門需要很多“手和腳”。畢竟,IT 部門 75% 的時間花在了維護上,因此推測出,他們在維護上需要的人數是開發所需人數的三倍。但是,把幾乎沒有實際工作經驗的人放在需要工作經驗的應用程式上,是行不通的。

“手和腳”的解釋也解釋不了為什麼新開發專案中的開發人員被普遍地視作英雄。退回到那時候,忙於新專案的人們相較於程式維護人員,有著更高的地位……我敢打賭這是真的。根據“提供的價值”,程式維護人員比開發程式設計師有著更多的價值。程式維護人員基於現有程式碼庫開發,結果,與任何新開發小組可能管理的功能相比,程式維護人員用較少成本交付了更多功能。

程式維護人員的技能

當我最後轉向新的開發工作後,實際上我丟掉了一些技能,而這些技能對於程式維護人員的工作是必備的。做維護工作,我差不多是個程式設計師,我還是歷史學家和偵探。

例如,當我做維護時,收到了被分配的問題,去追蹤一個 bug,它偶爾引起我們的程式崩潰,隨之留下一些髒資料。這個 bug 首次出現在 4 年前(比我加入公司還要早得多)。這個 bug 潛伏了一段時間,但是上週它再次出現了。

因為我是程式設計師,我掃了一眼程式碼,但是,由於我是第三或第四個被分配到這個問題(我還缺乏經驗)的人,貌似我不太可能發現前任開發人員都沒有發現的問題。如果它不是程式碼,我推測它一定是資料……這讓我根據 bug 報告的時間進行了劃分。最終的曲線比較有意思:剛開始 bug 出現得相當頻繁(3-4 次/天),到了如今,頻率逐漸減少,這個 bug 每個月只出現幾次。

根據這些證據,我得出了結論,在 bug 首次出現之前,一定發生了什麼,而該 bug 導致資料庫埋下了髒資料。當應用程式處理到髒資料時,程式就崩潰了,然後有人介入並修復資料。當我向組內其他人員(他們比我在公司的時間要長得多)演示這個分析時,他們立即定位到了問題:在 bug 首次出現之前、已經被執行的一個資料轉換程式。有了這個資訊,我們能夠找到其餘的髒資料,並修復該 bug。

程式維護人員一直是這樣做的:區域性偵探、區域性歷史學家,偶爾地扮演成開發人員。他們也是軟體考古學家(深挖打了拙劣補丁的程式碼層)和精神病專家(搞清楚比你先來的開發人員的動機)。

當我最終做新開發工作時,我很開心得到“提拔”,因為在維護小組待過之後,目前這份工作是如此地輕鬆。或許這是你調入開發的真正理由:隨著年齡的增長,你開始失去優勢,你沒有被下放;相反,你被調到了不能做任何有害事情的工作上——新的開發工作。

英文原文:In Praise of the Maintenance Programmer
來自:部落格園
相關閱讀
評論(1)

相關文章