90%做維護，10%做開發，這正常嗎？

譯注：這篇譯文來自 Stack Exchange 上的一個提問，在許多開發者中都產生了共鳴。很多時候，作為程序員的我們，在日常工作中并沒有很多時間用在編寫代碼上，而是不斷的在維護某個年代久遠的系 統，不斷的 bug fix，維護的項目會越來越多。如果我們希望能改進已有的代碼，對系統做下重構，有時候并不能得到公司的支持。提問者聲稱自己的報酬非常低，但卻在做整個 開發團隊級別的工作，這到底正常嗎？難道所有的開發者都是這樣的？以下兩個回復獲得了大多數開發者的認同，想學習下如何同公司高層溝通的技巧嗎？

        TiredProgrammer 6 月 12 日：

        我在一家中等規模的公司里做 Web 開發。剛開始的時候，我的任務是對一個已有的應用做擴展（這個項目的代碼很糟糕，是由多個程序員花了好幾年時間開發的，他們用不同的方法處理相同的任務，而且基本上沒什么結構可言）。

        當我成功的按照需求完成了對應用的擴展后，公司讓我全職負責對這個應用的維護工作。這當然沒問題，或許只有我是這么想的。但是公司卻禁止我去改進已有的代碼，只讓我集中精力解決 bug——如果有 bug 報告的話。

        從那時起，我又陸續接手了 3 個類似這樣的項目，現在我都得一起維護。之后，我又被委任了 4 個項目——這次可以從頭開始創建整個應用，當然了，這些新開發的項目我也得去維護。

        現在，我快被每日不斷的用戶郵件給搞瘋了，我所負責維護的每一個應用都是這樣。公司希望我能直接處理這些郵件中提到的問題，同時又丟給我 2 個新項目（這之后已經有 5 個項目在排隊等著了）。杯具的是，對于我自己編寫的代碼，我還沒有收到任何 bug 報告，只是偶爾會有那么一些腦殘要求希望徹底顛覆原來的需求。

        無論如何，這正常嗎？在我看來，我一個人做的工作頂得上一整個開發團隊了。我最初預想的可不是這樣的啊，我是白癡嗎？我猜這個帖子可能會引起網上的大論戰，但請告訴我，并不是每一個開發者都遇到了我這種情況。P.S. 我的薪水幾乎和超市的收銀員一樣多，如果不比他們低的話。（亮點…）

        acattle 最后編輯于 6 月 13 日：

        我在實習的時候也發現有很多時間都花在解 bug 上了。你必須意識到作為初級程序員，你沒法獲得更有挑戰性的工作，你得從沒人愿意干的臟活累活干起。這當然是不幸的，但這條規律適用于所有的工作。

        另外，你得認識到一點，對于公司來說，能正常工作的代碼遠比清晰的代碼更重要。從你所在的公司的角度來看，修改已有的代碼庫是在浪費金錢，你不 過是在重做已有的東西，而且還可能會帶來更多潛在的錯誤。通常這種類型的公司都不是計算機/軟件公司，因此高層都缺乏足夠的技術背景來理解你要做的這種大 改動的意義。也就是說，如果你所在的公司是技術型公司，由懂技術的人來管理，他們能夠理解好的代碼所帶來的價值的話，你可能還會有更多的余地，盡管有時候 你還是需要選擇一下戰場（畢竟，生意的主要目的還是為了賺錢）。

        那就是說，丟下你現在的工作而期望得到更有意義的工作是不合理的。同樣令人遺憾的是，你不得不同時處理由各個不同的項目經理針對各個項目提出的要求。

        作為一名程序員，事實就是比起你自己從頭寫起代碼的時間，你要花費更多的時間在維護和修改其他人的代碼上。如果這對你來說難以接受，也許你應該 只把開發當成一項愛好，然后選擇別的行業謀生。如果你對維護代碼沒有什么異議，但感覺工作并沒有使自己發揮出全部的功效，或者覺得自己快被工作榨干了，那 么你需要同你的經理好好探討一下你的工作模式。如果你面臨的問題比這個更嚴重，或者如果你感覺經理并不知道如何有效的根據你的技能來管理你的工作，那么考 慮換個新公司應該是個好主意。根據你提到的低工資，跳槽可能是你現在最好的選擇。

        Péter Török最后編輯于 6 月 13 日：

        看起來似乎是管理層在任務優先級的選擇和工作量的管理上出了問題。你應該同你的經理談談，讓他們知道你的工作已經過載了，如果每個人都跑過來煩 你，讓你完成他們馬上想達成的要求，這樣你就無法繼續有效的工作了。那樣會讓你從一個任務跳到另一個任務，浪費了大量的時間在切換思維上。對于高效率的軟 件開發工作來說，你應該只全身心投入到一項任務中去。有越多的中斷和干擾，你就要花越多的時間在環境切換上。有研究顯示，大約 15 分鐘的時間能讓你進入專注的狀態，此時你的思維是最有效率的。如果你每 15 分鐘被中斷一次，你永遠也無法專注下去，這對你和公司都是很大的浪費。

        因此你應該試著和你的經理溝通，達成一個更加合理的工作模式。這應該包括對任務進行優先級劃分，并在某種程度上提前進行規劃。所有的用戶需求都應該按照優先級的順序記錄在列表上。并且，優先級不應該由需求的發起者來指定（自 然地，大家都會認為自己的需求是世界上最重要的），也不能由你自己來定，而應該由某個擁有足夠多的商業知識以及對你維護的一系列產品有著全局認識的人來指 定（產品經理）。理想情況下，所有的需求請求都應該被錄入到問題追蹤系統如 Jira 或者 Mantis 上，或者至少給產品經理發送郵件，而不是直接發給你。應該由他/她去負責處理 “為什么我的需求還沒有完成？”這樣的用戶抱怨，而讓你集中精力在開發工作上。如果這種情況難以實現的話，當你在處理新的需求時，你至少要和經理溝通協商 出一段時間，這段時間內你不能被打擾，只負責開發工作。

        如果上面的做法可行，下一步就應該是提前做好規劃。比如，估計一下完成最高優先級的任務需要多少時間，然后將你的時間劃分為各個“沖刺階段”， 每個階段可能是 1 周或好幾周時間，為你的下一個沖刺階段安排滿足夠多的任務。你可能還希望保留一段時間以應對緊急的需求，但其余的都可以提前規劃好。你也可能更希望將不同 項目的工作劃分到不同的時間點上，比如，項目A就安排在周 1 解決，周 2 到周 3 是項目B，周 4 上午可以做項目C，下午就可以做項目D等等，以此進一步的減少任務間的切換。按照這種方式，你對于未來 1 周或幾周的工作任務就有了大致粗略的了解。此外，這也為你的客戶提供了一個路線圖：他們可以了解到他們的請求何時可以得到解決。這里你可能不會想對你的經 理提到“敏捷”這個詞——這基本上就是敏捷開發，但有些人并不清楚敏捷開發到底是什么，他們就是一味地反對。

        盡管你現在的職位看起來報酬很低，可是你維護的項目越多，你就越有資本來溝通協商。對于公司來說，招一個新 人進來給他培訓，再讓他維護所有這些項目需要花費相當長的時間（時間就是金錢）。你可以正當的指出你的代碼比原有的部分要好的多，所以從公司的方面來說， 他們沒法輕易的以同樣的價錢雇到一個合適的候選者來完成同樣的工作。更不用說如果他們不改善工作條件的話，他們雇到的下一個家伙很快也會像你一樣受夠了就 退出不干了。試著讓公司懂得讓你快樂的留在公司對公司是最有益的。這會給你一些資本來和公司協商以上的情況，并要求加薪。

        你究竟有多少談判的資本——這是個大問題。管理層可能會也可能不會對你的請求有足夠的尊重。但如果你把握的夠好的話，你就有機會。如果他們拒 絕，你總是可以再去尋找更好的工作。這種情況對于每個職場菜鳥來說并不相同，雖然（很悲催的）你的經歷是相當典型的。但是確實總是有更好的工作地點在那等 著。工作場所的好壞同地理位置的關系聯系并不大，但給我的感覺是，在歐洲北部你可以獲得的機會比平均水平要高一些。因此，在你完全受夠之前，如果你無法顯著改善現在的工作條件，你應該馬上開始尋找新的工作機會。騎驢找馬總是很好的，所以你不要因為需要用錢就立即接受第一份 offer。最終你總會找到一個更好的去處的。

        英文原文：StackExchange  編譯：伯樂在線— 陳舸