寫在工作一年之際
火絨正在保護您的電腦,已保護365天
去年的11月1號進入這家公司,到現在已經整整一年了,也從一個到處闖禍的實習生成長到可以獨立負責一些任務的新手了,如果要對過去一年做個評價的話, not bad
沒有什麼比困難更能考驗一個人,過去的一年裡,做過的比較困難的任務,有三個
第二個月,第一次獨立負責
image.png
現在回想起來,也是噩夢般的經歷,我大概做了這些
elastic search redis protobuf 多執行緒設計 介面設計
最後在兩週延期後有驚無險的上線了,這次做的並不好,之後一次還坑了大佬一次,唉,羞愧.
之後也想過重構,忙了七八天,大佬給的評價是"你這是重寫,不是重構", 為此特地找了幾本重構相關的書,最後意識到我那確實是重寫了,哈哈
第六-七個月,負責獨立的模組
這次是做兩個模組,好友聊天和隨機匹配,匹配之前老專案裡有類似的,自我感覺難度不是很大
-
允許抄,但是要根據自身場景做變化,不能死搬硬套
當時我就是死搬硬套,也沒去思考下兩邊有沒有什麼區別,被leader狠狠的批了一頓,這次是真的活該哈哈哈,下去之後仔細研究了一下修改之後確實看著更自然也更好做了 -
技術是為業務服務的,寫的再好效率再高,不能滿足業務也是白搭
寫匹配的時候,考慮過多個方案,有幾個可以說是為了效率不顧一切吧哈哈,每次都被斃掉,最後leader說了一些話,大致意思就是上面這些,也就是從那時候開始自己才真正有這個意識,做設計的時候也會仔細思考一下這塊 -
程式碼中要考慮到極端情況
"如果redis掛掉一段時間你這塊會怎麼處理?","那就掛掉嘍".嗯,不出意外又被diss了.第一次聽說要考慮基礎服務掛掉程式碼如何繼續執行時,我的第一反應是基礎服務都掛掉了,那就都掛了唄,後面自己仔細想想才體會到它的真正含義,基礎服務掛掉並沒有想象的那麼罕見,如果是核心邏輯,確實要考慮到這些情況. -
不要過早優化
當時剛剛看了幾本程式碼優化方面的書籍,迫不及待的試試手(這些書上是提了不要過早優化的),寫完之後才意識到有些優化確實做得太早了,徒勞無功.
在整體邏輯尚未成型時所做的優化,一般來說時負優化.前期整體結構還不固定,業務隨時可能變動,現有的邏輯也不一定正確,在這種基礎上做的優化往往是徒勞無功.後面改起來反而更麻煩.但是
並不是說不做優化,通用邏輯封裝這些還是可以做的 -
要嘗試理解使用者,從使用者的角度去做業務
做到好友聊天這塊時,有這個場景,使用者選擇結束通話,這裡可能有併發問題,可能另外一個使用者提前點選了結束,那麼請問這個操作能報錯嗎?
當然不能,從使用者的角度看,我不想聊了,想結束都結束不了? 這是不能接受的.最後附上leader當時說的幾句話,個人認為很有意義,
如果業務出現了異常情況,按照解決方式從好到壞排列分為 1. 後端能解決 2. 使用者能解決 3. 卡死
一年,開發核心邏輯
135da41db13cfbf6.png
要做一個遊戲,開發時間一週.時間很緊,遊戲的主流程是我做來做的,很累.萬幸的是按時完成了.
-
不要固執己見,要聽取別人的意見
因為之前不瞭解遊戲角色的當前血量設計,加上時間緊(只能說是當時的託詞),沒有聽取前端同事的意見,做到後面果不其然出了問題,最終還是改成了他提的那種設計,這次教訓很慘重,大概浪費了半天時間,如果當時能夠仔細的詢問一下,思考一下,可能節省出更多時間,做一些其他地方的優化.(這裡大概也有些溝通方面的問題吧,與君共勉) -
不能容忍重複程式碼,要懂得抽離通用邏輯,分離變化與不變
這點是這次自己做的比較好的,還是上面的血量設計,一共改了兩次設計,得益於前期封裝的很好,每次更改設計改動的程式碼不超過100行.想一下如果當時偷懶沒做封裝,業務邏輯又這麼複雜,肯定不能按時上線了 -
寫程式碼糾結是好事
有這個場景,要把map中所有的值自增,為了這個糾結了半個小時寫了一個性能和可讀性都還行的設計,時間是很緊,但這不是理由,作為一個程式員,如果沒有對優雅程式碼的追求,那和鹹魚有什麼兩樣 -
對於核心流程要考慮要任何可能的情況
參見上面的程式碼中要考慮到極端情況,有一個場景,玩家死亡時會可能會掉落一些物品,如果氪金了就不會掉了,因為前端要顯示,所以在死亡時就要計算好會掉什麼,如果玩家確認重生了才會扣除(氪金當然就不扣了),可能掉落的物品肯定用redis來存了,當時就考慮到如果使用者死亡後,確認放棄前.發生了一些異常情況導致扣除失敗,這種情況是不能報錯的,如果報錯使用者就無法繼續遊戲了,這個情況是不能接受的,所以對這塊做了處理,不管能不能扣除成功都確保使用者可以重生.之後檢視線上日誌發現確實派上用場了,這點算是這次比較得意的設計了,嘻嘻.
這一年我學到了什麼
1. 一定一定一定要跟產品確認所有不確定的細節
這裡不是黑產品,產品想做的和程式設計師想出來的很可能有很大偏差,如果不做確認和可能出現以下兩種情況
- 本來很簡單的東西程式理解的太複雜,導致做了很多無用功
- 本來很複雜的東西程式理解的太簡單,導致程式碼不可能,最壞的情況就是重寫
另外程式主動跟產品確認需求還有一個最大的優點, 對於這個需求,程式已經有自己的理解,並很可能有初步的實現方案了,而產品可能還不確定自己想做什麼,這樣就很有可能將一個很複雜的需求簡化
2. 學習一項新技術時,沒有什麼是比官方文件更可靠地
花的時間去鑽研官方文件,比漫無目的的看部落格好很多.
3. 要懂得請教別人,個人的思維是有侷限的,別人往往能發現自己的邏輯漏洞
舉個例子,對於一個需求,自己想了一下有了大概的設計,覺得是可行的, 這個時候請教一下同事,將自己的設計複述一下,如果對方能理解並且沒有發現問題,那這個設計就不會有大的紕漏.可以說是起到及時止損的作用.(PS.請教時一定要有禮貌和足夠的尊重,大家都很忙,沒人有義務去幫你的)
4. 做業務時可以'拿來主義',但是事後要去研究一下
如果一直都是拿來主義,不去自己死磕研究一下,技術不會有任何進步,就真的變成了日常搬磚了
5. 終身學習真的不只是說說,要抽出時間來學習新知識
工作時間越長越能感覺到自己的不足,各個方面的知識都欠缺的很多,要每天抽出些時間去讀,去學,去使用.業務是做不完的,如何抽時間就見仁見智了.
6. 運動! 運動! 運動!
每天運動一下,保證三天至少跑步一次. 運動很重要,並不只是因為健康,運動可以極大的緩解壓力,補充意志力.每天不用動的話,心態真的會爆炸的.
7. 要明白自己真正想要什麼要對未來保持憧憬
搞技術是枯燥的,就算對技術再痴迷,也是會有睏倦的時候,這時候你需要明白自己真正想要什麼,它一定是和技術無關,而是和人生相關的.如果不是想到她,我可能真的無法堅持下來.
結語
終於把這篇總結寫完了,也算是給自己一個交代,與諸君共勉.