在DJ的日子
時光荏苒，轉眼到DJ已快三個年頭，自認為這是我收穫最多的一家公司，特此記之。
工作氛圍
DJ整體工作節奏還是比較輕鬆的，基本上不加班，小團隊，組織結構簡單，沒有多少辦公室政治。
從產品定位上，由於早年定位於社交招聘導致使用DJ的大部分是學生應屆生，這一定位導致DJ社招相對薄弱，最終讓僱主對DJ的社招可能缺乏一些認同，再加上一些垂直招聘網站lg，boss等後起之秀，DJ的處境確實不是那麼樂觀。
在技術架構上，除早期遺留專案，Web主框架已經全面遷移到SpringMvc。服務層採用的是基於Dubbo的微服務架構，訊息元件為RocketMq，配合Worker和定時任務進行非同步任務的處理。儲存這一塊主要是主從Mysql叢集配合Redis叢集作快取，Orm為業界流行的輕量級框架ibatis，去年已經升級為Mybatis。早年基於配置檔案對專案進行管理，升級維護異常麻煩，後來由基於ZK的配置管理中心接管，持續整合為Jenkins和Maven包。這就是DJ後端的技術棧，希望能給有志於來DJ的人一些參考。
完成工作
回顧這三年，印象比較深刻的工作如下：
- lp網驗證碼破解
- 邀約服務id更換
- 基礎服務拆分
- 延時佇列
- Maven包依賴查詢工具
- 應對XSS攻擊，新增CSP頭
- 搭建現金支付、訂單管理架構
剩下的大部分時間都是業務開發。
心得體會
第一是要遵循一定的規則。這一條相信大家都聽膩了，各種規範、最佳實踐等等都是在教大家遵循一定的規則，這裡我就不再贅述了。我想強調的是第二點。
第二是有時候要勇於打破規則。或許是遵循規則強調的太多了，有時候都忘了打破規則。一味地遵循規則可能會給自己或他人帶來大麻煩，而打破規則往往能另闢新徑。舉個例子，我在基礎服務拆分的時候就遇到了這個問題。我們的SOA架構基於Dubbo，一個完整的服務包括api、client和service三個包，api裡主要是一些model類、列舉和服務介面，client裡只有一個非常輕量的consumer配置檔案，service是dubbo服務的真正的提供者，這樣一個工程如果依賴服務，只需要引入api和client包即可。為了降低服務之間的耦合性，以及Maven包迴圈依賴的可能性，api和client裡不允許引用其他服務的api和client，因為B的service裡有可能依賴A的client，如果A的client裡可以引入B的client，B的service就引入了自身的client，這樣就會報錯。一個平常非常好的規則在服務拆分的時候就造成了大麻煩，比如服務A和B分別拆出來一部分服務到C，C是一個新的服務，那麼如果一個工程依賴原來的A中的服務，現在挪到C中了，那麼工程就需要將C的api和client包引進來，如果拆出來服務很多，這勢必會給原來服務的使用者造成很大的麻煩，因為他需要pom檔案加入很多新的api和client依賴，這個時候就要變通一下，打破這種規則，這樣對原來服務的使用者就完全透明瞭。在工程上這通常稱為“白名單”。
第三是要有主人翁心態。現在經常可以在職位要求中有那麼一些詞：“良好的溝通技能”、“自驅動”、“責任心”等等，其實本質上是一種主人翁心態的養成，上面那些詞都是這種心態的外在表現。一個簡單的道理，你給別人幹活不願意幹，給自己幹有不願意乾的嗎？給自己幹你會不自驅動嗎，會沒有責任心嗎？說了那麼多，那如何養成呢？首先從個人要拋棄“我給公司打工，幹好幹差反正都不是我的，差不多得了”這種心態，這可不是給你灌雞湯啊，有人可能會說憑什麼呀，憑長遠來看這對你自己是一種提升，比如你幹一個活你自認為達到了70分，如果要達到80甚至90分，你可能就要開動腦筋費一些精力，這個過程中你可能會學到一些以前沒有接觸的東西，很明顯你的能力提升了。但是如果你堅持上面的那種心態得過且過，雖然暫時輕鬆了，但錯過了提升自己的機會；另一方面公司要從文化上進行引導，還要建立合理的獎懲機制，畢竟“名利”總得有一樣吧，大家都是現實的人。
第四是無論自己幹活還是安排別人幹活一定要有明確的時間節點。這話什麼意思呢？比如在生活中我們經常和朋友說這話的話：“找個時間大家聚一下啊”，這種多半聚不成，因為沒有明確的時間地點。在生活中這麼說還有情可原，在工作中這麼說就會造成大家不知道往哪裡使勁。有時候不形成書面的時間點，光是在心裡那麼一想有時候都大有改觀。比如當初學習Coursera上的機器學習課程，也沒啥計劃，剛開始挺好一週學完一節，最後虎頭蛇尾不了了之。上年又準備拿起來，當時正好快放假了，定的目標是放假前學完，最終只用了18天（2018.12.30-2019.1.17）。
第五是勿以“量變”而不做。有時候對於一個問題暫時沒有從本質上解決它的辦法，這個時候難道什麼也不做了嗎？不是，其實你可以做一些工作從量上對它進行改變。比如支付這一塊當時技術調研，如果引入分散式事務對現有架構衝擊較大，而且無論是兩階段提交還是Try-Commit-Cancel這種模式都無法100%保證事務一致性，最終做了妥協，採用訊息、定時任務以及人工來保證支付資料的最終一致性。從執行到現在的結果來看，資料不一致的情況非常少，有的話大部分情況下訊息和定時任務可以自動處理，只有極少數才需要人工參與。這就是一個只在“量”上解決問題的例子。
第六是當你覺得比較舒適甚至懶散的時候就該到新的環境中去了。記得以前換工作面試官經常問的一個問題是為啥要離職，當時都會說想學習一些新的東西。後來轉念一想，你想學習新東西老的公司也可以啊。實際上，無論在哪裡，如果你想學，新東西總會有。真正想到一個新環境中去是因為老的環境已經挺熟悉了，什麼都見怪不怪，什麼都習慣了，到達了一個比較舒服的狀態，也就是俗話中的有點“皮”了。有人說我不會，無論在一個環境中待多久我都是一種處子的心態，好我敬你是條漢子，你牛！還有一個更重要的原因是新環境會拓寬你的視野增長你的見識。舉個簡單的例子，我上家公司是一個做政府專案的公司，他們的架構是公司內部打war包，分發到各地部署，你可能覺得很low，但這確實是適合他們的架構，因為政府的一些系統不允許連線外網，沒法進行遠端部署。假如不來DJ，我不會見識到網際網路公司的一種技術架構，反過來更全面的看原來公司的架構方式。舉個不恰當的例子，當你沒聽過原子彈的時候，你可能抱著炮彈沾沾自喜，當你聽過原子彈，僅僅是知道有原子彈這回事，都足以讓你做出很多改變，比如你自然而然的會想別人用原子彈我改怎麼應對，我要不要造，我能不能造，如何造……等等。
最後，感謝DJ給我這樣成長的機會，感謝hy、dd、wx、mg等的幫助。