[[197325]]

【51CTO.com原創(chuàng)稿件】被無數(shù)爛尾項目折磨的哈韓浪子，一直從事 JavaEE 開發(fā)，踩過的坑無數(shù)，承接別人的項目也有幾個。

新人或者剛?cè)肼毜某绦蛟?，都會面臨一個問題，如何快速接手熟悉項目?本期挨踢故事匯哈韓浪子教你做個快樂的接盤俠高手。

[[197326]]

哈韓浪子 JavaEE 開發(fā)

半路接手項目被吐槽

作為一個程序員，喜歡瀏覽知乎這樣的知識分享平臺來拓寬視野。發(fā)現(xiàn)經(jīng)常有人在提這樣類似的問題，例如如何快速接手熟悉一個項目(從代碼角度)?新手如何快速上手項目?

透過題目，哈韓浪子能感受到提問者那渴望求知的眼神，他看了問題底下的評論，大家都沒有給出方法，而是變成了吐槽。

吐槽選登

A：要么忍要么滾+10086，心理一萬個草泥馬還得面帶微笑。

B：剛畢業(yè)就進了這樣一個項目，現(xiàn)在盤算著吃飽經(jīng)驗滾球了。

C：太多了。。。專業(yè)擦屁股戶 ，再熬到年底，準備跑路了。愛誰擦誰擦吧。

D：我以前也可慫，領(lǐng)導給我安排工作，我好多次都默默接受了。昨天真的是爆發(fā)了，憑什么我好說話所以次次都是欺負我?

真的是兔子急了還咬人的感覺，沖到領(lǐng)導辦公室辯論，平時領(lǐng)導覺得我不怎么爭論，昨天真是辯論賽水平，有理有據(jù)。

領(lǐng)導：考慮到你的能力，我們特意給你了一個標桿項目讓你去做維護，你一點都不知道感恩。

程序猿：項目交接文檔缺失，項目業(yè)務代碼混亂，項目一直沒有確定邊界，導致現(xiàn)在需求膨脹。這個項目也是標桿?

領(lǐng)導：這些都不是問題，你看你要是把這些問題都處理好，不就正好體現(xiàn)出你的能力了啊，你看這是一個多好的鍛煉機會啊。

程序猿：你瞎說，據(jù)我所知你在例會上可不是這么說的(一般都是項目組領(lǐng)導參加，程序員沒資格參加)。你說的是處理好這個項目是應該的，處理不好就是能力差。

領(lǐng)導正色道：我就是給你一坨屎，你也要開心的吃下去，不然你可以走啊，會寫代碼的滿大街都是。

看到大家這樣的吐槽，哈韓浪子感到很難過。因為他也曾經(jīng)經(jīng)歷過這樣一段時期，那時候他還是個愣頭青，領(lǐng)導說啥就是啥。

但是后來發(fā)現(xiàn)柿子還得捏軟的，況且就算他退讓了領(lǐng)導也不喜歡，一直都是干的多拿的少，就算最后離職還把他的年終獎坑了。

如何接手遺留項目

人生就是在經(jīng)歷中成長，所以哈韓浪子要分享一下接手項目的經(jīng)驗，做一個快樂的接盤俠。那么我們應該如何接手遺留項目呢?

接手前的準備

接手前，先要了解一下這個項目目前的狀況，可以咨詢主管這個項目的領(lǐng)導，當然如果這個領(lǐng)導忽悠你，跟你說這個項目是標桿，或者說這個項目怎么怎么的好，那么你就要多思考一下是不是一個坑了。

這個時候你就需要領(lǐng)導提供項目的 bug 修改單或者是需求變更單，這樣大致能客觀的展現(xiàn)出項目存在的問題。

如果 bug 單里修改的東西很多，或者需求變更頻繁，那么就不建議再接手這個項目了，不然最后難受的是自己，你把爛尾項目處理好了，是應該的，處理不好就是你能力差，其他同事也是站著說話不腰疼的去擠兌你。

如果項目的 bug 單和需求變更單不是很頻繁，這個項目還是可以接手的。

接手后的第一件事情

立即著手使用項目，把項目的流程先跑通，然后了解項目的設(shè)計目的，因為這些內(nèi)容就好比是一個燈塔，能在大方向上給你指明道路，并幫你將代碼片段串聯(lián)起來，把一個功能點的代碼從數(shù)據(jù)層，service 層，到 controller 層理出來。

做到能快速定位相關(guān)位置，還有每一層之間與項目相關(guān)的配置文件的熟悉，例如有定時任務配置文件，加解密配置文件等，從而形成一個整體。

我們要記住越是復雜的項目，其目的和設(shè)計占的比重越是重要。

把項目拆解，編寫自己的項目文檔

項目難，往往是因為不了解，看著一大堆東西，心理上首先就有壓力。一定要頂著壓力往前走，把項目分模塊的去了解，通過代碼去理解業(yè)務。

一個系統(tǒng)一定有使用頻繁的模塊和非使用非頻繁模塊，這個可以通過給客戶的使用手冊來了解。

如果項目缺失具體的設(shè)計說明書，那么就需要看相關(guān)功能代碼是怎么寫的，通過了解代碼和使用項目來了解業(yè)務流程。

同時要學會編寫文檔，主要是讓自己好理解這個項目。因為你接手了這個項目，就意味著項目再出什么情況都由你自己承擔。

哪怕出現(xiàn)的問題是由于項目設(shè)計，或者開發(fā)期產(chǎn)生的，也得由你承擔。因為編寫文字不像說話，耗費的時間會多一些，在打字的過程中，我們會花費心思去組織語言和思考，這會讓我們發(fā)現(xiàn)更多項目上的問題。

進入維護狀態(tài)

當我們了解了項目的業(yè)務和相關(guān)的代碼，就算正式接手了項目，可以開始處理項目中的實際問題。

同時我們要養(yǎng)成每天下班把生產(chǎn)日志拿來看一下，看看項目中是否存在潛在的問題，比如內(nèi)存開銷過大，死鎖等問題。

看日志主要看 error 日志，確定所呈現(xiàn)的 bug 是緊急還是非緊急的。緊急的，立即就要著手去修復。同時要寫郵件抄送給相關(guān)領(lǐng)導。(不然你把問題處理好了，領(lǐng)導也認為你沒有工作量)

查看服務器的 CPU，內(nèi)存等開銷。這個不必天天進行。

寫一些 SQL 腳本，來檢測數(shù)據(jù)庫表里是否出現(xiàn)了數(shù)據(jù)重復，垃圾數(shù)據(jù)。主要防范出現(xiàn) SQL 注入等問題。

寫在最后

唯有經(jīng)歷過以上所有步驟，我們才能成為一個專業(yè)的項目接盤俠，然后開心快樂的成長，對于之前負責項目里給你留的坑也好，bug 也罷，我們當然選擇原諒他!

如果你也愿意分享你的故事，請加 51CTO 開發(fā)者 QQ 交流群 312724475 聯(lián)系群主小官，期待你精彩的故事!

【51CTO原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】