步入2020年，正好是三十周歲琅捏。之前想的五年規(guī)劃柄延，成為一名架構師或技術專家缀程，我看還是有一段路要走市俊，有些不足的地方需要提升。雖然兩年半前入職這邊是資深后臺開發(fā)工程師撩满，希望能在成長的時候多成長些绅你。
下半年參與新項目的機會不是很多，主要是老項目在運營伪嫁，而其他幾個版本的需求調(diào)整偶垮，以及線上的問題似舵，各種偶現(xiàn)難查bug分析解決，都要跟進龙助。老項目的一些活動需要進行跨服化频祝，之前是只在本服進行脆淹，后面要改造一些代碼，這樣帶來的工作量是多一些漓糙，這其中要考慮的較多烘嘱，不可能為了加跨服功能而又要把原來已經(jīng)測試過線上沒問題的功能再測試一遍。以及一些適合本業(yè)務上的方案思考醉鳖。新項目中寫了個基礎系統(tǒng)后來因需求調(diào)整被廢棄了哮内，這可能在游戲中經(jīng)常這樣；對一些移植老項目的代碼進行了優(yōu)化和重構纹因，比如其中的定時器瞭恰，整體性能提升15%~22%。
再說說自己的成長惊畏，相比去年陕截，通過之前的博客記錄，在非工作領域社搅，通過開源乳规，學到一些新的知識和更深入的思考。工作上笙以，拋開業(yè)務部分冻辩，分析和解決問題的能力有一定的提升；框架設計會考慮更多倘感；更有責任心咙咽，更想把一件事情或項目做好钧敞。
對于工作上，還是之前的話镜廉，通過一個完整的項目是成長很多愚战，包括一些設計方案威根，復雜性和性能等權衡洛搀。因為業(yè)務邏輯不是很難佑淀，需求理解清楚，別總是出bug和不穩(wěn)定谎砾，但是怎么選擇合理的設計卻是需要經(jīng)驗積攢捧颅。當項目越來越大碉哑，代碼越來越多，怎么重構扣典，耦合性等需要考慮到贮尖。另外，如果僅僅把自己局限于工作范圍內(nèi)薪前，不去看下其他優(yōu)秀的開源項目和設計方法关斜，可能提升不那么大或者本來有不錯的實現(xiàn)蚤吹，自己搞一個很復雜且難維護的實現(xiàn)随抠，雖然功能性上也滿足需求，但是后面的性能和擴展性呢二驰？線上出現(xiàn)的問題秉沼，不管是需求還是框架，怎么去定位和復現(xiàn)矗积，然后修復和回歸測試，帶著問題再次review早期代碼辜腺，這兒是否是合理設計乍恐，會不會出現(xiàn)什么問題等茵烈，而不是寫完功能就好了，這樣的成長其實也不多加匈，換個人也可以寫宙彪。
雖然多個版本的游戲已運營一年多释漆，但還是有些基礎功能設計不合理的，比如之前線上經(jīng)常出bug的郵件系統(tǒng)示姿，比如之前碰到過的有造成系統(tǒng)OOM掛掉逊笆；凌晨的時候大批玩家郵件領不了栈戳；只領取了一半獎勵；有些超時的郵件本應該刪除而卻發(fā)給玩家难裆，導致玩家刪除不了等子檀。后來再次review郵件系統(tǒng)的實現(xiàn)，比如根據(jù)郵件唯一id和角色id獲取對應的某一個郵件乃戈，實現(xiàn)中是先從數(shù)據(jù)庫中獲取這個人的所有郵件褂痰，然后再返回對應id的郵件，這樣會帶來什么問題症虑？一方面郵件功能并未作相關數(shù)據(jù)緩存缩歪，再者框架是協(xié)程，一個異步請求一個阻塞掛起谍憔，若一次性發(fā)十個這樣的命令主籍，那么所有請求都透傳到數(shù)據(jù)庫那邊。一般個人郵件數(shù)量最大上限有幾千逛球，這樣一次性從DB中獲取非常多的數(shù)據(jù)千元，肯定是有問題的，之前因為OOM就是這樣的情況颤绕。根據(jù)郵件id刪除對應的郵件诅炉，也是使用對應的接口。所有跟郵件接口功能相關的屋厘，都是使用有問題的實現(xiàn)涕烧，都會造成問題。另外也包括在DB中的郵件內(nèi)容汗洒，有些字節(jié)是不必要存的造成一定的冗余议纯。
這僅是服務器這邊的實現(xiàn)，有些好的設計溢谤，關于客戶端與服務器之間的交互瞻凤，如何減少流量及CPU等，都是需要考慮的世杀。比如加上緩存阀参，需要考慮緩存的失效時間，緩存與DB數(shù)據(jù)的一致性瞻坝，緩存的容量蛛壳，緩存中的數(shù)據(jù)同一時間大量失效造成的問題等。哪些郵件要存DB所刀，哪些不存衙荐。如何防止重復領取一封郵件獎勵等。一個小小的郵件系統(tǒng)浮创，會包含很多的設計忧吟，實現(xiàn)一個無bug的穩(wěn)定及可維護性的郵件系統(tǒng)不是那么簡單的，需要踩坑斩披，測試及線上驗證溜族。還有其他的基礎系統(tǒng)，可能早期只是趕進度垦沉，只是實現(xiàn)需求即可煌抒，線上測試機會不多等因素，后期都可能為重構帶來“機會”乡话。
不過后面在新的項目中由其他同事重新寫了郵件系統(tǒng)摧玫，不知道又出現(xiàn)哪些問題耳奕，大概看了下绑青。雖然之前的郵件系統(tǒng)一堆已知問題诬像，只要一個個修復并重新優(yōu)化實現(xiàn)，也是都可以解決的闸婴，雖然目前的郵件系統(tǒng)已有bug也就三個四且都不復雜好修復坏挠。有些系統(tǒng)功能和代碼為什么這么設計，總是出于當時一定的業(yè)務需求及考慮邪乍，且經(jīng)過線上長時間的驗證降狠，而不是全盤否定，重新來再庇楞，自己寫成怎么樣又很難說榜配，不停的測試再回歸。那樣可能后面再次踩各種各樣的坑吕晌〉叭欤或許根本問題并不在這些地方，但又不知道哪兒出問題睛驳，所以感覺這里復雜隱藏問題烙心，先推倒這里，說不定是這么個情況乏沸。很多時候淫茵，解決問題，需要先確定哪兒有問題蹬跃，抓住問題的本質(zhì)匙瘪，然后再做各方面的取舍和平衡。
最后想再說說項目管理這塊蝶缀。因為一個需求涉及到策劃辆苔，客戶端和服務端程序，以及測試四方面同學扼劈，如何準確理解需求是需要四方都合在一起開會討論需求驻啤，哪些能實現(xiàn)，哪些不能實現(xiàn)荐吵，以及可能有的問題骑冗，短期目標是什么，考慮后續(xù)需求的調(diào)整還需要落實到文檔可跟蹤目標先煎，不然工作交到其他同學手里贼涩，文檔好久沒更新也不知道什么樣了后期隨便提個新需求，可能改動就很大薯蝎，怕只有先熟悉這塊實現(xiàn)的才能作些改動和重復的測試多次遥倦。而且一個版本也還好，若同時有五六個版本，每個版本的有些地方需求不一樣袒哥，而又只在同一份代碼使用if/else寫不同版本的功能缩筛，不知道是出于簡單考慮或者管理方便還是其他情況。因為之前做了好多這方面的需求調(diào)整堡称，雖然改動有時大有時小瞎抛，但改了某個版本的代碼處，又要擔心是否會影響其他版本的却紧，需要同時測試幾個版本桐臊，雖然沒出過事情。代碼和配置分版本的好處是相互隔離不影響晓殊，改了這個版本的不影響其他版本断凶，后期如果這份代碼其他版本需要，同步下即可巫俺，現(xiàn)在的方式是比較尷尬懒浮，而且某個配置中某項被莫明其妙的刪除，導致線上出問題再次熱更识藤，幸虧能熱更但似乎更依賴于熱更砚著，而不是寫更有健壯性的代碼和少做的刪除配置文件，有些存在即合理痴昧。
由之前博客記錄的一些工作總結稽穆，拋開配置引起的問題，這一年大概發(fā)現(xiàn)和解決偶現(xiàn)bug問題30+個赶撰，大部分跟服務端的基礎框架代碼相關舌镶，并對存在的隱患調(diào)整相關的設計實現(xiàn)。通過這些分析思考問題豪娜，差不多再次把整個項目業(yè)務代碼和基礎代碼翻一遍餐胀，上一次還是在2018年1月份，優(yōu)化一大部分基礎代碼瘤载。自己把相關的工作負責好否灾，也去看些其他的基礎功能，雖然這些不是很難實現(xiàn)鸣奔，可以學習下和發(fā)現(xiàn)潛在的問題墨技。主要是想多成長些。
今年主要的事情是挎狸，分析brpc相關部分不錯的設計源碼及框架扣汪；再次閱讀《深度探索C++對象模型》和《Effective C++》，以及《STL源碼剖析》的前五章锨匆，csapp某些章節(jié)崭别，這些主要是利用前三季度的早晨和晚上的兩小時左右，冬季就很少早起看書～。dpdk相關的部分茅主；游戲中的A星尋路以及視野相關的實現(xiàn)及優(yōu)化舞痰；還有些C++11智能指針的源碼相關；bfs相關的實現(xiàn)(后來沒再分析)暗膜，多線程相關的優(yōu)化；和之前的libco和phxrpc鞭衩，skynet相關源碼細節(jié)再次翻閱了下...
回過頭來学搜，這些事情并不多，關鍵是沒有集中的時間去做论衍，可能周末斷斷續(xù)續(xù)的進行效果不是很好瑞佩。平時工作也挺忙，九點下班到家十點坯台，洗洗差不多十一點就可以睡覺了炬丸。關鍵還是長期的堅持下，早期可能很難蜒蕾，對有些復雜的開源項目很難把控稠炬，但是合理的分解，一個模塊一個去攻克和調(diào)試咪啡，最后回過頭來首启，發(fā)現(xiàn)在慢慢的收獲和掌握。另外撤摸，對于開源的這些項目毅桃，并沒有參與到實際業(yè)務中，可能并不能夠深入層次領悟設計者為何這么設計准夷，是否有其他方案來達到或比它更好钥飞？各方案間的權衡是如何考慮的等？比如同樣的定時器實現(xiàn)衫嵌，為何這種實現(xiàn)會在該業(yè)務需求背景下就有不錯的性能读宙？在分析的時候多思考些。有時在工作中楔绞，遇到相似的業(yè)務場景论悴，可能會從之前學到過的設計思想，分析和評估下能否使用到當前項目中來墓律。
今年暫定計劃膀估，在有空閑時間時，繼續(xù)brpc剩余重要的模塊耻讽，另外可能準備braft察纯，雖然早些時候分析過raft的floyd實現(xiàn)，但后者實現(xiàn)是有些方面沒有考慮到，可能并不適合于實際項目饼记，前者有更多的可以學習下香伴，需要深入源碼以及設計思想。若有更多的精力具则，可能再回頭關注下redis/jemalloc/leveldb即纲。redis和leveldb在四五年前分析過一些實現(xiàn)后來因為工作太忙給中斷掉，后來也偶爾看看并未作任何記錄博肋，希望以后保持下低斋。感覺總體的計劃不會太多，我認為不一定要給自己列很多匪凡，把這些都好好弄清和一些實現(xiàn)原理能理解下膊畴，對于工業(yè)級的代碼，到時候在項目中能使用到類似的可以直接查看下病游，應該是可以的唇跨。
回顧這幾年的工作經(jīng)歷，總結大概如下：從事游戲后臺開發(fā)四年多衬衬，大半年抗DDoS防火墻開發(fā)买猖，一年大數(shù)據(jù)開發(fā)，其中負責后臺框架滋尉，性能優(yōu)化政勃，重構及業(yè)務需求的實現(xiàn)，線上問題的解決兼砖；平時使用到的語言是C/C++奸远，lua，開發(fā)環(huán)境linux讽挟，扎實的計算機基礎知識懒叛，對技術比較熱愛；能獨立負責一塊業(yè)務耽梅，能站在產(chǎn)品或項目需求的角度去理解技術薛窥，良好的系統(tǒng)設計和代碼質(zhì)量，以及分析和解決問題的能力等眼姐。個人這塊擅長的地方是性能優(yōu)化诅迷，框架設計，解決一些技術難題等众旗。不擅長的還是寫ppt罢杉，講ppt。
再說說自己的顧慮贡歧，因為這兩年半多的時間工作中主要開發(fā)語言是lua滩租，少量C/C++赋秀，那么帶來的一個問題是，有些之前熟悉掌握的知識和工具可能會慢慢生疏律想。我明白猎莲，工作中需要什么去學，都說語言工具技即，對于工作多年的來說著洼，關鍵在于學習能力和快速解決問題的能力，用的時候去查一下即可而叼。只要基礎不太差身笤，愿意花時間和保持個較好的心態(tài)去接觸不熟悉的一面也是有很大可能解決的。至于以后可能的換工作和面試什么的澈歉，技術是一方面展鸡，還有運氣和緣分吧屿衅。畢竟面試充滿不確定性埃难，并不是所有問題都會，而且面試官和候選人對一個問題的理解層次也有不同涤久，以及過往的經(jīng)驗積累和知識掌握程度涡尘。糾結誰對誰錯已經(jīng)沒有意義。
若以后換工作响迂，我希望的面試官考抄，如果懂某一方面，可以一起聊聊蔗彤，可以往深入提問川梅，這樣至少有些反饋我回答的理解的對不對？而不是你不懂然遏，然后給我可能贫途，好像，有點這樣的不確定性待侵，你至少要確保自己清楚這個方面丢早，或者你聽完不說話也行，可以查一下資料再判斷是否正確和合理（如果愿意的話）秧倾。面試本來是相互的過程怨酝，是需要（可能）一起共事的，而不是隨便面面那先，可能你會的我不會农猬，也可能你會的或許理解的有點偏差。有些業(yè)務場景售淡，目前的方案是合適的盛险，有出于一些因素考慮瞄摊，可能有更好的方案而需要經(jīng)過leader評估和驗證，而不是為什么不是B的情況苦掘？設計之初其他方案也考慮到但沒有選擇换帜，這本是作為一個工程師該做的，站在全局鹤啡，而不是按照個人意愿或者之前的技術經(jīng)驗來套用現(xiàn)在的項目惯驼。有的面試官根本不大會面試或者技術有待提高，可能是運氣不大好递瑰，可能浪費彼此時間（尷尬）祟牲。
當然我是喜歡看到面試后的評價，這里并不是去判斷面試過程是否有出入抖部，因為能站在面試官角度去看候選人哪里不足说贝。如果面試過程能有足夠的相互交流是挺好的，不過貌似只遇到一問一答慎颗，問題接著問的那種情況乡恕，聽不到面試官對這個問題的理解，有時候選人的回答跟面試官理解的不一樣俯萎，并不是錯的傲宜。比如面試官的知識可能停留在某個標準中，而新標準中已經(jīng)可以這么實現(xiàn)夫啊。因為經(jīng)歷過的項目架構可能不適合別的項目函卒，也沒有機會考查下候選人如何應對一個未接觸過的需求場景，和怎么選擇出合理的方案撇眯，提出類似“如果讓你來設計一個系統(tǒng)报嵌，會怎么做，需要考慮到哪些方面熊榛，是否存在可以優(yōu)化的地方锚国，以及穩(wěn)定性，容災單點等大的方面”来候，所以這個過程挺尷尬的跷叉。像阿里面試就會全方面的考查候選人，而不是僅僅因為他當前做了什么营搅。面試本來是個不斷匹配的過程云挟，不光看候選人當前會的，還應該看潛力是否有能力解決問題和承擔更大的責任转质。
這里摘一下知乎[如何進行一場高質(zhì)量的游戲技術面試（原則篇）]中的一段比較贊同的話园欣，當然這里不是僅指游戲行業(yè)：
“其次是要善于發(fā)現(xiàn)面試者的優(yōu)點。技術是多維度的休蟹，在一方面有短板沸枯，可能在另一方面卻是專家日矫，需要綜合評價。有的面試官不知從哪里來的優(yōu)越感绑榴，一副居高臨下的態(tài)度哪轿，以問倒對方為樂，這樣是不可取的翔怎。正確的心態(tài)應該是兩人合作探討問題窃诉，就如同工作中的同事。如果面試者思考一個難題卡殼了赤套，面試官應該給予提示飘痛，引導思路；反過來容握，面試者也可以順著面試官的話題展開宣脉，主動展現(xiàn)自己的優(yōu)點。在英文中interview不僅有面試的意思剔氏，也有面談塑猖、采訪之意，所以一個好的面試官要能讓面試者打開話匣子介蛉，全面展現(xiàn)自己萌庆；面試者也不要唯唯諾諾溶褪，必要時刻也可以主動出擊币旧。”
要總結的大概如上猿妈，其實還有很多事想寫吹菱，但有些事情大概是看破不說破的情況，盡最大能力和責任去把每一件事情好彭则。還是這一句：做個靠譜的合作伙伴鳍刷，凡事有交代，件件有著落俯抖，事事有回音输瓜。以后的路還很長，做個懂感恩的人芬萍。
希望2020~2022年能再提升一下尤揣，可能自己在這幾年完成兩件人生大事。另外柬祠，希望大家都健健康康的北戏。
