6 天時間，才改了 1 行代碼

英文：Ed Weissman，編譯：ITEYE

www.iteye.com/news/25109

導讀：產品研發是一項綜合性的工作，需要多個部門參與。但協作過程中，往往會出現各種各樣的問題，如部門協作困難、全局監控難等，這困擾著大多數的企業。本文是一個真實的案例。

昨天看了艾德的《老闆說 10 分鐘可搞定，為什麼我卻幹了 3 小時》，今天繼續他的另外一篇《6 天時間，才改了 1 行代碼》。

菲利普（主席）：我們工廠中有 10% 的員工沒有充分利用，要麼我們開始處理更多的積壓工作，要麼進行裁員。我寧願每個人都很忙。我們該如何做？

李（業務部經理）：公司政策規定，我們要處理3個月內的積壓工作，如果改成4個月，我們將有大量的工作。

菲利普：好。現在，我們該如何實現？

李：我不是很確定。我認為，我們需要更改傳統的軟體設置。

大衛（IT總監）：沒問題。可能只需要更改核心程序中的一行代碼。（填寫一個清單，提交給IT部門）。

朱迪（IT管理員）：我正分派這個單號為 #129281 的需求。但是這需要目前的商務項目做完，並由主任簽字。

大衛：這是菲利普交代的，我們不立刻做的話，就必須裁員。

朱迪：OK，我會馬上填寫，並標記為緊急任務。

2 天后

大衛：#129281目前狀態是什麼？

朱迪：它是開發人員任務隊列中的緊急任務，前面還有14個緊急的Bug報告需要處理。

大衛：忘記任務隊列。將它標記為緊急，立即發給艾德（程序員）。

1 小時後

艾德（程序員）：在模塊ORP572的第1252行中，我將寫死的變數MonthsOfBacklog（積壓月份）值從「3」改成了「4」。然後，運行了2批測試用例，成功進行單元測試。業務工作量增加了10%，這是預期數據。我正準備提交代碼審查，並交給Homer進行用戶驗收測試。

雪莉（代碼審查）：這違反了公司的政策，你必須在參數文件中做個記錄。此外，還有2箇舊的調試命令，1個無指定的變數警告消息和1個寫死的Employee ID，必須在這個模塊移交到產品之前進行修復。

艾德：!~@#$%^&*（髒話）。

雪莉：這些bug很可能是真的。一旦你被指派ORP572模塊，你就需要對已經存在的、違反新公司政策的錯誤進行修復。我不能提交。

2 小時後

艾德：OK，完成。我正要重新提交代碼審查。

朱莉（IT測試）：Homer 不能進行用戶驗收測試，因為Fred正在運行一個本月底財務要用的約束測試。使用 Marge 代替。

艾德：我沒有訪問 Marge 的許可權。

朱莉：聯繫IT安全部門的喬，他會給你開許可權的。

2 小時後

喬（IT安全）：沒有大衛的簽名，我不能給你開 Marge 許可權。他出差了，得等到周一。

艾德：我不這麼認為。菲利普希望馬上實施，讓他來授予許可權。

雪莉：你的新的參數記錄「MonthsOfDemand」需要起一個更好的名字。離岸程序員（位於其他國家的開發部門）不明白這意味著什麼。此外，它應該有一個變化核查軌跡。

艾德：命名有什麼規定？

雪莉：忘了寫在什麼地方了。離岸團隊是3月中下旬更新的wiki，能肯定的是，所有新的參數記錄必須滿足新的命名要求，並保持核查軌跡。

1 天后

艾德：我將參數記錄中的「MonthsOfDemand」重命名為「SelectedMonthsOfBacklogDemand」，並添加模塊PAR634以保持紀錄和核查軌跡。我已經提交到代碼審查。

托尼（IT測試）：我看到Marge中有#129281任務，但我沒有收到測試計劃。

艾德：按照老方式運行就行，注意WorkOrdersHours報告中總量的增加。

托尼：這就是你的測試計劃？這會影響到企業的其他方面，我必須有用戶選擇的測試用例、預期結果、測試運行記錄以及用戶簽收。

2 天后

菲利普：大衛，告訴托尼將艾德的程序立即提交到產品部門。

大衛：是的，先生。

本次任務總結：

總時間：6天

關鍵任務代碼更改行數：1行

關鍵任務代碼更改位元組數：1位元組

- 完 -

看完本文有收穫？請轉發分享給更多人

關注「程序員的那些事」，提升編程技能

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！