寫這篇文章中心中也是思緒萬千，最近做的事情很多，成長也蠻大。所以自己一直想把自己最近做的事都寫出來，可是真正開始寫的時候，又不知從何寫起。
最近一年負責的專案運營的還不錯，現在大概每天能有億級流量。當時是為了快速開發，就用php做了乙個最小可用版本。上線之後運營那邊資料很好，每天都能有10萬+的新增，使用者粘合性也比較高，所以就開始迭代。因為自己是第一次用0-1把控整個專案，再加上是為了搶占使用者紅利快速開發，很多事情提前都沒有架構好。所以可想而知，迭代幾個版本後維護成本急劇增加。每次改版或者發布新功能都要小心翼翼，生怕影響到哪兒導致出致命bug。好在及時感知到了問題所在，在不影響新功能開發的情況下，我加班加點重新梳理規劃了專案。規劃後感覺一切都明朗了起來，維護起來也不是那麼困難了，開發效率也提高了很多。
引用這個標題其實是在耗子叔的coolshell上看到的一篇文章 程式設計師的謊謬之言還是至理名言？ 還有這篇傳世之文也推薦閱讀一下 what every computer science major should know 很多網上關於職業發展的文章上都有談「到帶著問題去學習，會學的更快。」 但是我發現很多人誤解成了「遇到問題了再去學習，會學的很快。」確實，遇到問題了你不得不學，可能會比你自主學習快。但事實是誰給你時間讓與遇到問題了去學習？公司會嗎？顯然公司不會。公司肯定從無論是從公司的利益考慮還是其他方面考慮肯定都是讓你解決問題，而不是遇到問題了去學習怎麼解決問題然後再去解決。你可以耽擱的起事件，但是往往公司可能會因為這個問題造成巨大的損失，公司是耽擱不起的。 如果是你自己遇到問題了，你自己可能會給你事件讓你帶著問題去學習。拿我舉例，我之前就是帶著問題一遍學著一邊做。遇到問題其實不可怕，因為問題伴隨著的往往是機會。可是如果你解決不了是人沒有機會給你的，我這面呢一是我態度比較好，自學能力和抗壓能力都比較強，二是公司這塊也缺人，如果公司不缺人我覺得也沒有我的什麼事了。因為我目前的能力負責這塊確實不能應付自如。所以不可能每個人都有機會等用到時再去學，一般都是行你就上，不行就下來。所以很多時候我們應該要提前準備好，職業危機感也要有的，而不是等到自己遇到問題了才想著去翻書本，被辭退了才想著學補演算法。
說一下今年的個人學習計畫吧，期待明年來打臉；
1.是學習基礎知識，新技術往往執行在底層知識之上的，是變化很快的，唯一不變的可能就是一些底層知識，所以學好底層知識才能在這個快速變化的行業中跟的上腳步。
2.學習好行業知識，不要等到用的時候才發現這個不會
3.加入了耗子叔組織的學習小組，跟著大家一起學習 針對上面點細化一下
1.學習計算機作業系統，複習c語言用c語言寫乙個小型的os系統
2.學習計算機網路程式設計
3.使用golang為目前負責的專案重構一版
4.每週分享一篇有觀點和思考的技術文章 5.每週至少做乙個 leetcode 的演算法題
6.每週閱讀並點評至少一篇英文技術文章
7.每週學習至少乙個技術技巧
學習參考：
作業系統原理
深入理解計算機作業系統
作業系統（自主模式）
tcp/ip詳解
unix環境高階程式設計
unix網路程式設計
最近的總結
一 想問題的時候盡量把邏輯屢清楚 二 有前台傳遞的值，一定需要校驗，非空的問題，容易跑出nullpointerexception 三 service處理大量的邏輯，使用高效查詢，避免頻繁的訪問資料庫，極大的增加了查詢時間，盡量將方法的可用率提高，這樣可以降低查詢的時間，也能減少重複的方法 四 重複 ...
最近的的總結
其實本身今天已經要睡了，但不知道從哪來的雅緻，使我爬起來起下這篇博文 剛入職4個月，給我的感覺就是忙，但這個忙卻是因為事多，而不是活多。常常會有那碰個需求，這改個東西，那邊線上出問題，這邊開個小會，一天整體下來寫的 是很少的，乃至於我認為我之前1天的工作量就是現在的3天，且還有富餘。現 在的工作我認...
最近這半年多蛋疼的探索
從去年10月離職到現在，一直是處於奔波的狀態，離開上個公司的理由很多，多的最後連我自己都忘記下乙份工作的理想模樣。直到最近兩周，才有慢慢回憶起來。工作太忙，工作內容太狹窄，以及對安於現狀的恐懼都促使我要盡快改變，然而真從原來習慣的圈子裡面跳出來卻又迷惑的不得了。等兩個月下來，轉來轉去，好像我離職的原...