こんにちは。
我是 PRUM 株式會社的 masa。
這次想介紹新進工程師最容易被分派到的「維護・營運」工作，分享現場真實的情況，以及只有在這裡才能培養出的成長機會。希望能讓那些認為「維護很單調、無法成長」的人，換個角度看待這份工作。
前言
剛進公司時，我一直以為「做出新功能」才是開發的正戲。實際上，最先交給我的工作卻幾乎都是既有系統的小型 bug 修正和告警處理，老實說，我當時真的覺得「很單調」。
當前輩問我「今天在做什麼？」時，我回答「在修 bug……」總覺得有點說不上來的空虛。
不過，持續做了一陣子之後，我對這份工作的印象也開始慢慢改變了。
為什麼會覺得「維護＝單調」？
在學習階段，很容易把「寫程式＝開發」畫上等號。從零開始做新功能、在一片空白的畫面上動手，讓某些東西誕生——很多人應該都是想像著這樣的場景，才會對這份工作產生憧憬吧。
另一方面，維護・營運的工作，則是修正和整理已經在運作的系統。它不太像「從零開始做出來」那樣有成就感，因此看起來單調也不難理解。我一開始也把它看成是「正式開發開始前的累積經驗期」。
但在真實現場裡，發布並不是終點，而是從那之後才真正開始。服務不是在上線的瞬間就完成，而是在被使用的過程中慢慢成長的，我也是在那時才真正理解這件事。
現場看到的「維護」真實樣貌
維護・營運工作之一，是監控正式環境。像是使用 Datadog、Sentry 這類工具，持續觀察伺服器負載與錯誤發生情況，萬一有狀況就會透過 Slack 收到通知。
有一次，警報響起時，我和前輩一起處理過。
那次修正的，只是一個不到 10 行的小小條件分支。完全沒有華麗之處。可是，在實際運作中的服務裡，真的修好了讓實際使用者困擾的問題，那種實感，和在教材上寫程式完全不同，分量也更重。
其實維護才是最能成長的地方
在維護・營運現場最先做的，通常是閱讀前輩寫的、正在運作中的程式碼。這反而成了最重要的學習機會。和教材裡的範例程式不同，實際在正式環境中使用的程式碼，充滿了「為什麼要這樣寫」的各種判斷與取捨。邊理解邊逐步修改的過程中，也會自然而然熟悉 Git 和 GitHub 的使用方式。
在我所在的現場，一開始是從既有程式的小型修正開始，等熟悉之後會被交辦在既有頁面上新增功能（像是增加按鈕或輸入欄位之類），再累積更多經驗後，就會參與新功能開發。不過，這個順序與所需時間會因團隊和專案狀況而有很大差異。人力充足的話，也可能很早就參與新開發；反之，也有維護比重一直都很高的團隊。若能先有「從維護開始，負責範圍會一點一點擴大」的感覺，應該會比較剛好。
重要的是，維護並不是「開發的累積期」，而是本身就是「閱讀、修正並實際運作正式程式碼」的實戰。維護不是累積期，而是能在正式環境中學習的現場。 因為有這段經歷，我在後來做新功能開發時，也更能思考與既有機制的一致性，以及發布之後可能會發生什麼事。
總結
維護・營運的工作，和華麗的新功能開發相比，確實看起來比較單調。但現在我反而認為，能在最接近實際運作的服務與使用者的地方動手的，正是維護・營運。只要把它重新理解成「不是單調的累積期，而是能在正式環境中學習的現場」，同樣的工作看起來就會完全不同。
如果你現在也把維護任務當成「想快點做完的工作」而草草帶過，下一次在修改程式之前，不妨先想想這段程式為什麼會被寫成這樣。光是這樣，從同一個修正工作中能得到的收穫就會不一樣。
也建議從 PRUM 株式會社經營的文章網站補充知識。
如果有興趣，也可以看看最近很受歡迎的文章👇
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
