這一年，我從學校畢業，走上工作崗位，成為了一名程序員。在w公司工作的半年時間里，參與過項目開發，經歷了崗位調動（由開發轉為維護）。經過這段時間的工作，逐漸地對w公司開發人員和維護人員的工作和生活狀況有了認識，相比剛走出校園的自己，心態也發生了一些變化。

開發：狂奔的蝸牛

進入w公司后，第一個參與的項目是U項目，U項目是融合通信相關的，基于已有的業務代碼作二次開發，功能包括即時消息、IM會議、寬窄帶電話等。

原有的業務代碼，結構混亂、冗余代碼多、模塊交互過程繁雜、歷史悠久。很多源碼文件代碼行數過萬，某個.c文件有4萬多行代碼，其中一個函數有將近3k代碼，代碼調用層次最深的達到10多層。在這份號稱過百萬行的代碼里，2007年產的那叫陳釀，2000年產的那叫國窖經典，甚至有人發現80年代的代碼，那叫一個“代碼恒久遠，一碼永流傳”。

一位老員工對我說：少年，你若能把這份代碼看懂，以后看其他代碼，那都是浮云！但他不知道，從看到這份代碼起很長一段時間，我見到老同學，都是這樣一副表情：

原有代碼的惡臭，加上通信流程的理解門檻，新員工很難在新項目開發中擔任主力。項目時間緊，業務需求不斷變動，更加大了開發的難度和老員工的負擔。盡管采用了“流行”的敏捷開發流程，但更多地是趕工期的敏捷、加班的敏捷。像過去一樣，依賴“人多力量大”，新老員工合力扛過了U項目這“一大波僵尸“，但這之后，從人員技能、代碼優化方面，是否應該考慮進行裝備升級呢？

個人工作

吐槽過后，來講講我在U項目中的工作。在U項目中我負責F模塊部分功能的開發：

消息跟蹤功能：顯示模塊中部分變量的值，展現程序的調用過程與返回結果

防止內存泄漏功能：檢測模塊調用者，在調用者失效時釋放其申請的內存塊

另外，參與了與F模塊相關的單元測試、性能測試。在編碼過程中，了解了代碼靜態檢查、圈復雜度檢查等概念以及相關工具的使用方法；在單元測試過程中，學習了gtest單元測試框架的使用方法。

維護：笨拙的偵探

U項目就要進入交付期的時候，我被告知要調到另一個項目組的維護組。

是的！當時聽到這個消息就震驚了！俺可是立志從事軟件開發的娃啊！維護是做神馬的？！人家一點思想準備都沒有啊！！！

說說維護

調換部門后，經過一個月的摸索，漸漸了解了維護工作內容。我所在的小組負責平臺的維護工作，這里的“平臺”涵蓋硬件（CPU、內存、磁盤、網卡等）、存儲設備、操作系統和中間件軟件，那工作內容又包括哪些呢？包括改進完善維護工具、實施保障與問題處理。問題處理是指在上層業務出現異常或中斷的時候，通過查看各種日志，排查故障原因（平臺相關的）并協助恢復業務，問題處理是維護工作任務中的主要一項。

困境

平臺支撐各種產品的業務，使用中的設備數量多，基數大，問題出現的概率就大。每個維護人員常常同時處理幾個問題，加上夜間保障與支持，維護人員更是感到身心疲憊。分析維護工作困難重重的原因，我認為有以下幾點：

1.人才缺失

最根本的原因還在于人。維護工作涉及計算機的各個方面：硬件、存儲設備、操作系統（Linux）、網絡、中間件軟件（雙機軟件、數據庫等），維護人員要求了解以上各個方面知識，但現狀是，對于以上每個方面，組內并沒有專研得深、研究得透的人。

正因為缺乏專業知識，在分析問題原因的時候，維護人員更多是根據經驗庫，與問題現象作匹配。也就是說，維護人員能處理的問題，大多是過去發生過的、已知原因的、相對淺顯的問題。面對需要從“深層次”尋找原因的問題（例如通過分析內核代碼，排查內核bug），我們往往無計可施。

2.跨部門合作的瓶頸

作為基礎平臺的維護人員，需要與業務人員、服務熱線人員和業務實施人員合作，共同處理、解決問題。各類人員分屬不同部門，問題的嚴重程度、是否處理得當，涉及到各個部門及個人的利益。當問題嚴重程度高、問題出現原因不明晰的時候，經常出現相關人員相互推諉、都不愿擔責的情況。

在開展工作的時候，各方人員很少能抱以精誠合作的態度，反而是將工作壓力層層轉嫁。業務實施人員向業務維護人員施壓，業務維護人員向平臺維護人員施壓。這造成w公司內維護人員工作壓力、勞動強度大，但工作成果反而不被認可的現象。

盡管維護工作面臨很多困難，但與U項目類開發工作相比較，個人更愿意選擇維護工作。原來項目開發的工作，更多地要求熟悉業務通信流程和原有的代碼，對個人編程技能提升鮮有幫助；相比之下，做平臺維護方面的工作，有機會深入學習操作系統、 Linux內核、存儲、網絡等方面的知識。經過一段時間的維護工作，我心態上也從抗拒，逐漸變成適應與接受。作為初入IT行業的工作者，多嘗試，多積累不同 產品的開發經驗、不同崗位的工作經歷，相信有助于自身的成長和發展。

出來混，始終是要還的

“出來混，始終是要還的”，工作后接觸的人、發生的事讓我深深體會到這一點。當前的工作和生活態度，決定了我們將來的生活狀態。只有拿出積極的態度，才可能獲得好的結果。

很多程序員工作任務重，加班是家常便飯，容易忽略技術的積累，技能不能提升，久而久之，就變成流水線上的工人。為了避免（或改變）這種情況，我們可以放眼未來，為自己設定一個中期目標（比如兩年后某某技術我要達到什么層次/兩年后我要跳到某某公司），再根據設定的目標，作相應的技術積累。

另一方面，一些剛參加工作的程序員同學，過于寄望未知的未來。當他們對公司或工作稍有不滿的時候，解決的方法直接了當：跳槽。沒錯，IT熱潮下再找一份工作并不難，但這并不是解決問題的根本途徑。在跳槽想法萌生的時候，請考慮這些問題：我是否勝任當前工作？與當前工作相關的知識我是否都理解？從當前工作中我是否已經學不到更多的東西了？我是否達到心儀工作的技能要求？如果以上問題的答案都是“否”，那請暫時放棄跳槽的打算，將當前工作相關的知識學好，把底子打扎實。

為避免成為以上兩種人，我經常問自己：

今天要學習哪些知識？昨天掌握了哪些知識？真正掌握了嗎？

兩年后我要在哪里？要做什么事情？現在的自己是在往這個方向前進嗎？

這是我激勵自己的方法，相信你也有你自己的方法。