寫在工做一年

火絨正在保護您的電腦,已保護365天

去年的11月1號進入這家公司,到如今已經整整一年了,也從一個處處闖禍的實習生成長到能夠獨立負責一些任務的新手了,若是要對過去一年作個評價的話, not bad 沒有什麼比困難更能考驗一我的,過去的一年裏,作過的比較困難的任務,有三個

第二個月,第一次獨立負責

如今回想起來,也是噩夢般的經歷,我大概作了這些

• elastic search,以前只是據說過這個框架可是徹底不知道是作什麼用的,項目結束以後已經靈活使用了(以後又研究了一些高級特性,好比function score)
• redis 也是第一次使用,當時沒有引入基於redis的分佈式鎖框架,就用setnx來作加鎖,項目完成後特意找了點資料研究了一下,對它內部的實現也有了點了解(redis的實現真的是就算只是一個bit都要想辦法去優化)
• protobuf 一樣第一次使用,剛開始很懼怕,寫了一個以後才明白並不複雜(至少使用的時候不復雜)
• 多線程設計 當時要作的東西相似於在線ktv,有一個待唱列表,每一個人都能操做,主持人有更高級的權限.對於當時的我來講,挑戰很大,多虧大佬們的講解.本身也是一點一點領悟修改,寫出了一版不完美可是能跑.想一下當時本身傻傻的埋頭苦寫不知道去問,還讓大佬們主動來指點我,真是羞愧萬分
• 接口設計 接口須要哪些參數? 有些數據是否是後端本身就能獲取? 前端傳遞的數據是否可信? 若是要返回的數據,有一部分是邏輯相關的,是否是要把他們封裝到一塊兒? 對敏感數據用get仍是post? 這些是我那段時間學到的,這塊是前端大佬們一點一點把我教會了,十分感激.

最後在兩週延期後有驚無險的上線了,此次作的並很差,以後一次還坑了大佬一次,唉,羞愧. 以後也想太重構,忙了七八天,大佬給的評價是"你這是重寫,不是重構", 爲此特意找了幾本重構相關的書,最後意識到我那確實是重寫了,哈哈

第六-七個月,負責獨立的模塊

此次是作兩個模塊,好友聊天和隨機匹配,匹配以前老項目裏有相似的,自我感受難度不是很大

• 容許抄,可是要根據自身場景作變化,不能死搬硬套 當時我就是死搬硬套,也沒去思考下兩邊有沒有什麼區別,被leader狠狠的批了一頓,此次是真的活該哈哈哈,下去以後仔細研究了一下修改以後確實看着更天然也更好作了

• 技術是爲業務服務的,寫的再好效率再高,不能知足業務也是白搭 寫匹配的時候,考慮過多個方案,有幾個能夠說是爲了效率不顧一切吧哈哈,每次都被斃掉,最後leader說了一些話,大體意思就是上面這些,也就是從那時候開始本身才真正有這個意識,作設計的時候也會仔細思考一下這塊

• 代碼中要考慮到極端狀況 "若是redis掛掉一段時間你這塊會怎麼處理?","那就掛掉嘍".嗯,不出意外又被diss了.第一次據說要考慮基礎服務掛掉代碼如何繼續運行時,個人第一反應是基礎服務都掛掉了,那就都掛了唄,後面本身仔細想一想才體會到它的真正含義,基礎服務掛掉並無想象的那麼罕見,若是是核心邏輯,確實要考慮到這些狀況.

• 不要過早優化 當時剛剛看了幾本代碼優化方面的書籍,火燒眉毛的試試手(這些書上是提了不要過早優化的),寫完以後才意識到有些優化確實作得太早了,徒勞無功. 在總體邏輯還沒有成型時所作的優化,通常來講時負優化.前期總體結構還不固定,業務隨時可能變更,現有的邏輯也不必定正確,在這種基礎上作的優化每每是徒勞無功.後面改起來反而更麻煩.可是並非說不作優化,通用邏輯封裝這些仍是能夠作的

• 要嘗試理解用戶,從用戶的角度去作業務 作到好友聊天這塊時,有這個場景,用戶選擇掛斷,這裏可能有併發問題,可能另一個用戶提早點擊告終束,那麼請問這個操做能報錯嗎? 固然不能,從用戶的角度看,我不想聊了,想結束都結束不了? 這是不能接受的. 最後附上leader當時說的幾句話,我的認爲頗有意義,若是業務出現了異常狀況,按照解決方式從好到壞排列分爲 1. 後端能解決 2. 用戶能解決 3. 卡死

一年,開發核心邏輯

要作一個遊戲,開發時間一週.時間很緊,遊戲的主流程是我作來作的,很累.萬幸的是按時完成了.

• 不要執拗己見,要聽取別人的意見 由於以前不瞭解遊戲角色的當前血量設計,加上時間緊(只能說是當時的託詞),沒有聽取前端同事的意見,作到後面果不其然出了問題,最終仍是改爲了他提的那種設計,此次教訓很慘重,大概浪費了半天時間,若是當時可以仔細的詢問一下,思考一下,可能節省出更多時間,作一些其餘地方的優化.(這裏大概也有些溝通方面的問題吧,與君共勉)
• 不能容忍重複代碼,要懂得抽離通用邏輯,分離變化與不變 這點是此次本身作的比較好的,仍是上面的血量設計,一共改了兩次設計,得益於前期封裝的很好,每次更改設計改動的代碼不超過100行.想一下若是當時偷懶沒作封裝,業務邏輯又這麼複雜,確定不能按時上線了
• 寫代碼糾結是好事 有這個場景,要把map中全部的值自增,爲了這個糾結了半個小時寫了一個性能和可讀性都還行的設計,時間是很緊,但這不是理由,做爲一個程序員,若是沒有對優雅代碼的追求,那和鹹魚有什麼兩樣
• 對於核心流程要考慮要任何可能的狀況 參見上面的代碼中要考慮到極端狀況,有一個場景,玩家死亡時會可能會掉落一些物品,若是氪金了就不會掉了,由於前端要顯示,因此在死亡時就要計算好會掉什麼,若是玩家確認重生了纔會扣除(氪金固然就不扣了),可能掉落的物品確定用redis來存了,當時就考慮到若是用戶死亡後,確認放棄前.發生了一些異常狀況致使扣除失敗,這種狀況是不能報錯的,若是報錯用戶就沒法繼續遊戲了,這個狀況是不能接受的,因此對這塊作了處理,無論能不能扣除成功都確保用戶能夠重生.以後查看線上日誌發現確實派上用場了,這點算是此次比較得意的設計了,嘻嘻.

這一年我學到了什麼

1. 必定必定必定要跟產品確認全部不肯定的細節 這裏不是黑產品,產品想作的和程序員想出來的極可能有很大誤差,若是不作確認和可能出現如下兩種狀況

1. 原本很簡單的東西程序理解的太複雜,致使作了不少無用功
2. 原本很複雜的東西程序理解的太簡單,致使代碼不可能,最壞的狀況就是重寫

另外程序主動跟產品確認需求還有一個最大的優勢,對於這個需求,程序已經有本身的理解,並極可能有初步的實現方案了,而產品可能還不肯定本身想作什麼,這樣就頗有可能將一個很複雜的需求簡化

2. 學習一項新技術時,沒有什麼是比官方文檔更可靠地 花的時間去鑽研官方文檔,比漫無目的的看博客好不少.

3. 要懂得請教別人,我的的思惟是有侷限的,別人每每能發現本身的邏輯漏洞 舉個例子,對於一個需求,本身想了一下有了大概的設計,以爲是可行的, 這個時候請教一下同事,將本身的設計複述一下,若是對方能理解而且沒有發現問題,那這個設計就不會有大的紕漏.能夠說是起到及時止損的做用.(PS.請教時必定要有禮貌和足夠的尊重,你們都很忙,沒人有義務去幫你的)

4. 作業務時能夠'拿來主義',可是過後要去研究一下 若是一直都是拿來主義,不去本身死磕研究一下,技術不會有任何進步,就真的變成了平常搬磚了

5. 終身學習真的不僅是說說,要抽出時間來學習新知識 工做時間越長越能感受到本身的不足,各個方面的知識都欠缺的不少,要天天抽出些時間去讀,去學,去使用.業務是作不完的,如何抽時間就見仁見智了.

6. 運動! 運動! 運動! 天天運動一下,保證三天至少跑步一次. 運動很重要,並不僅是由於健康,運動能夠極大的緩解壓力,補充意志力.天天不用動的話,心態真的會爆炸的.

7. 要明白本身真正想要什麼要對將來保持憧憬 搞技術是枯燥的,就算對技術再癡迷,也是會有睏倦的時候,這時候你須要明白本身真正想要什麼,它必定是和技術無關,而是和人生相關的.若是不是想到她,我可能真的沒法堅持下來.

結語

終於把這篇總結寫完了,也算是給本身一個交代,與諸君共勉.