引子
當我看到“concurrency is hard without garbage collection is difficult”這句話的時候，把我帶入了沉思，讓我有着寫這篇文章的想法。
談談工作經歷
畢業後一直從事遊戲開發，確切的說是服務端開發，產品也比較單一，一直是MMORPG，算是遊戲中比較大型和複雜的一種吧；後來在一家（社交+遊戲app）基礎服務組，主要做微服務拆分和核心功能支持。
做遊戲的時候，東西比較雜，什麼都要涉及一些（功能開發、策劃工具、運維部署、玩法設計），做遊戲就是這樣，技術方面不夠精，並且遊戲行業開發的代碼框架啊都已經成爲一種定式，都這麼寫，但是爲什麼呢？可能也是不明其意；
後來，面試基礎服務組時，對方說，你的遊戲經歷在我這兒就等於0；真的是這樣的嗎？
說下從事的區別，遊戲呢，特別是game server，真的是夠複雜，代碼量巨大（一個進程，純業務代碼大約26W行），管理內容超級多，涉及問題也很多，特別是涉及多線程；app呢，拆分很細都是微服務，注重分佈式開發，各種解決方案（包括開源方案啊，各種開源組件啊）；
談談都能學到什麼
從遊戲中（大型項目），其實你能找到很多學習的點，因爲都是積累起來的代碼，自然有其中的道理，但需要明白其中的含義纔是正確的方向吧；然而，現在大多數人都很浮躁，哪有時間想這些（唉），其實其中涉及的知識很多，只是沒有深入而已，比如說搜索（肯定有好友名字、工會名字搜索等，聯想到搜索引擎深入學習，還有如何結合分佈式支持好友系統，這時候又可以深入分佈式系統的學習），自己多體會，多思考纔是硬道理。
目前做的微服務拆分呢，編程功底可能不需要多紮實，代碼量小，對開源組件瞭解，會使用，特殊場景，特殊結構結合，配合上分佈式，基本就可以啦，然而這些又要調研，又要深入組件學習，同時還有對分佈式的深入學習；對於基礎服務呢編程功底還是要有滴。
總結以及規劃
書很重要，是指路明燈嘛哈，很多書，也許之前看過，並且看的也很快，爲什麼呢？因爲沉澱少，不能對應到自己的知識庫中（我指的是那種對實際項目有幫助的書籍），現在你在看的時候會發現很慢，有些知識點你會仔細琢磨，就是這樣，編程功底會越來越紮實。
知識體系觸類旁通，比如分佈式開發，那想想多核時代如何處理的呢？我的意思是說，知識也是慢慢演化而成的，學習呢，可以瞭解相關的具有相似性的，這對各方面都是有好處的。
最後呢引用下陳碩在知乎的一個回答
我認爲應該在《操作系統》和《計算機體系結構》這兩門課上下功夫，然後纔去讀編程方面的 APUE、UNP 等書。
下面簡單談談我對學習這兩門課的看法和建議，都是站在服務端程序員的角度，從實用主義（pragmatic）的立場出發而言的。
學習操作系統的目的，不是讓你去發明自己操作系統內核，打敗 Linux；也不是成爲內核開發人員；而是理解操作系統爲用戶態進程提供了怎樣的運行環境，作爲程序員應該如何才能充分利用好這個環境，哪些做法是有益的，哪些是做無用功，哪些則是幫倒忙。
學習計算機體系結構的目的，不是讓你去設計自己的 CPU（新的 ISA 或微架構），打敗 Intel 和 ARM；也不是參與到 CPU 設計團隊，改進現有的微架構；而是明白現代的處理器的能力與特性（例如流水線、多發射、分支預測、亂序執行等等指令級並行手段，內存局部性與 cache，多處理器的內存模型、能見度、重排序等等），在編程的時候通過適當組織代碼和數據來發揮 CPU 的效能，避免 pitfalls。Modern Microprocessors
這兩門課程該如何學？看哪些書？這裏我告訴你一個通用的辦法，去美國計算機系排名靠前的大學的課程主頁，找到這兩門課最近幾年的課程大綱、講義、參考書目、閱讀材料、隨堂練習、課後作業、編程實驗、期末項目等，然後你就心裏有數了。
學習任何一門課程都要善於抓住主要矛盾、分清主次、突出重點，關鍵是掌握知識框架，學會以後真正有用的知識和技能，而不要把精力平均分配在一些瑣事上。
2018逆境求生存啊，經歷了太多太多，越是逆境越會引發思考，最終也想好了到底應該怎麼做，做什麼，放棄什麼，還有不能做什麼，最後一句話量力而行。