進入新公司也有快三個月了，總結一下自己學到的東西和不足之處。

技術方面

1. 更慎密的邏輯：以前做功能總是各種趕著來，但是新公司採用的是敏捷開發，每個迭代都安排著合適的任務，所以有更多的時間思考程式碼的邏輯，而且有了review後經常自己覺得沒問題的點，在別人看來問題很多，感覺自己在很多方面思考得不夠細膩，這是有待提高的一個點。
2. 更強的程式碼健壯性：堅持不信任原則，無論是使用者輸入，還是二方三方介面的呼叫，都要進行非空等必要的檢查。雖然可能會比較影響程式碼的美觀，但是對於一個上線的系統，穩定性才是關鍵。
3. 將重構融入日常開發：編碼-重構-測試，先以完成任務為目的進行編碼，然後以提高程式碼質量為目的進行重構，寫完一個可以獨立測試
   的功能點為步長。
4. 分散式系統：知道分散式系統的概念已經有很長時間了，第一次接觸到線上商用的分散式系統。而且並不是用的spring cloud 全家桶，而是自己找各種元件整合起來的分散式系統，很佩服公司裡的大佬們。
5. devops：都體現在工具的使用上，不得不說實在是很好用~
6. 設計模式：之前很多設計模式只是處於紙上談兵，現在也寫了一些，看到了很多。

業務方面

1. 技術為業務讓步：再牛逼的技術不能給公司帶來價值也沒用。
2. 熟悉業務的方法：專案是由多人完成，可能你只熟悉自己做的這一塊內容，所以需要快速熟悉他人所做的業務內容。看日誌排查問題，code review都是不錯的辦法。
3. 摸清楚需求再動手
   ：之前習慣是拿到東西就埋頭苦做，有時候需求理解得不透徹，導致返工，所以拿到需求後應該多分析分析，找產品問清楚，然後最好是能畫些設計圖，這樣既捋清楚思路，而且又會有額外的產出（寫完程式碼基本上不會回去補文件和設計圖的有木有~），這是一個很好的方法，要貫徹執行！
4. 注意上下文：很多需求並不是全新的，而是要在他人的程式碼上進行修改，所以這就需要把上下文捋清楚，程式碼的源頭，呼叫的機制，使用了啥設計模式，為啥這麼做等等。不弄清楚容易寫出糟糕的程式碼，而且可能會出現返工（親身經歷。。。）
5. 記錄東西：作為聰明的程式設計師，肯定不能死記硬背這麼多東西啦，大腦需要儲存更重要的知識~所以平常多記筆記，做了啥，為啥這麼做，好處是啥等等，把想到的記下來，然後程式碼上線後就愉快的忘了它吧。

可能還有一些遺漏的，但是以上的點都是我的親身經歷，總結出來的經驗也需要貫徹執行。以前總以為會這會那很牛逼，但是現在看來自己還太年輕，學技術不難，難的是應用到實際中去，把對應的問題解決得漂漂亮亮。所以
1. 做好手上的每一件事，把用到的知識摸清楚，注意細節。這樣到實際使用的時候才能信手沾來。
2. 學習學習學習，非常重要，說不定哪一天就會用到了。
總結就是不僅腳踏實地還要高瞻遠矚