作為一名程式設計師，在工作中大概率都會遇到接手老專案的情況。
老專案誰接誰知道，不是坑就是淚。
前人新做的專案，拿了績效+晉公升，完事了抹抹嘴，扔給你。
別人吃完肉了，到你這，你還能喝到湯嗎？
別說喝湯了，專案裡的坑你都不知道在**，搞不好哪天出個問題，責任全在你這。
兄弟，既然工作中避免不了接手老專案，那咱就得思考怎麼做老專案這項工作。
做老專案，乙個常見的思路是做效能優化。
先聚焦到乙個突破口，找到乙個效能差強人意的介面，提出改進措施。
別小看只是優化了乙個介面的耗時，這就是整個工作的突破口。
有了這個突破口，慢慢地捋順流程，就可以以點帶面，提出專案中某乙個環節的優化方案。
如果說優化了乙個介面看不出什麼工作亮點，但是要是能優化某個環節，這在leader那裡絕對可以說是你工作上的乙個亮點了。
這其實也是量變引起質變的思路，乙個介面優化不足掛齒，但是把若干個介面優化包裝成某個環節的優化，就能引起質變。
你可能聽到產品或其他下游業務抱怨，哪哪哪慢了什麼的，然後你就開始埋頭改**。
兄弟，等一等，工作不是這麼搞的。
任何工作開始前，都要思考兩個問題：該怎麼做？怎麼能證明我做了這個工作，並且做的很好？
你要優化乙個介面的效能，首先要做的就是加上效能監控，拿出資料來說明某某介面耗時太高。這就是你工作的背景和出發點。最後再拿出優化後的介面耗時，一對比，就體現出你工作的效果了。
大部分系統都是操作快取或db，效能優化的第一步就是做db sql的優化。
常見的sql優化措施：
explain後，給table加上index
取消join，改為記憶體組裝
慢/大sql拆解。比如 in查詢帶上了1000個元素，這個sql語句就變得很龐大，光在日誌裡打出來就好幾行，那可以把in分拆為多個in查詢。
常見的**優化措施：
for element in list
// 優化後
sql query in (list)
func buildtree(tree)
// 優化後
// 先一把查出所需的資料
alldata = sql query
// 記憶體遞迴在資料上構建
func buildtree(alldata)
剪枝，縮小計算範圍。把不符合要求的資料先清理掉。
能提前返回的就提前返回，沒必要再往下走。
空間換時間，使用map set等資料結構
一些幾乎不變的資料，可以直接放在記憶體cache裡，這樣訪問效率是最高的，比第三方cache如redis還要高。
如redis。
對於變動較多的資料，則記憶體cache就不可用了，因為記憶體cache都是在各個例項內部，而請求往往是loadbalance到某乙個例項，這就導致各個例項間記憶體cache資料不一致。
此時就得上第三方cache了。
如何接手乙個專案
首先將專案 大目標 分為三個小目標 業務 技術 團隊運作。業務 請同事講一下，這個業務是做什麼的，解決什麼樣的問題，具體的業務流程是什麼樣子的。在這期間，不需要弄懂所有的細節，只需要建立起初步的框架。技術 你先得知道整個系統用到的技術棧，這樣你對系統用到的框架和工具就有數了。對外 系統對外提供哪些介...
工作方法 快速接手乙個老專案
在公司裡面，最開始的並不是從零開始乙個專案，那是不可能的，而且作為乙個新手程式設計師，很多時候，給你的可能只是乙個小模組，或者是乙個老的專案維護，且以後者居多，結合最近接手別人的專案的情況，做一下乙個小的總結。原則 凡事多問，事無鉅細，做好驗證，不要怕麻煩別人 千萬不要怕自己問的問題比較弱智，沒關係...
如何接手乙個新專案
專案好與不好，它就在那裡 架構優雅或者醜陋，它就在那裡 注釋有或者沒有，它還在那裡 文件亂或者不亂，它始終都在那裡。不論它是什麼樣子的，線上就那樣跑著。一般來講，專案分為兩種 2 為技術服務的專案，比如開源中介軟體專案 dubbo spring cloud 各種資料庫中介軟體 各種快取方案等 首先說...