應屆畢業生工做7個月小結

時間  2020-08-18
標籤 應屆畢業生 個月 小結 简体版
原文   原文鏈接

前言： 不知不覺已經工做了快 7 個月了，去年這個時候還躋身在考研的大軍中，不由有些感慨... 結合這 7 個月發生的一些事情，簡單作一下總結吧...

爲得到更好的閱讀體驗，請訪問原文地址：傳送門java

1、那時候剛入職

不一樣於其餘同窗忙於畢設的 4 月，提前安排趁寒假已經完成畢設的我，已經開始撲在了「找工做」這件事上，有了去年「秋招」打下的基礎，複習起來快了不少，沒過多久就開始投簡歷面試了，面試也整體比較順利，剛面沒幾家就迅速和一家本身看好的初創公司簽下了。react

公司使用的技術棧區別於本身熟悉的 Java/ MySQL 這一套，而是主要使用的 Rails/ MongoDB，因此剛入職的一段時間，基本上都是在本身熟悉技術棧，也趁着閒暇的時間，把本身入門時候的一些學習心得寫成了文章發表：git

對於職場小白來講，所謂「職場」仍是顯得有些陌生，剛來的時候，雖然跟周圍的同事都稀鬆日常地打了一圈兒招呼，坐下以後，隨着他們又埋頭噼裏啪啦敲打鍵盤工做的深刻，又頓覺周圍一片陌生，還挺奇妙的，在第一週完的週報裏面我寫道：github

剛來公司有些迷茫，只是看着CheckList對照着熟悉一些技術，也不瞭解本身應該要熟悉到哪一種程度，就但願本身能再主動些，無論是技術問題仍是其餘問題多請教，而後儘快跟其餘成員熟悉起來。

剛開始上手的時候也有好多問題不懂，我都習慣性的選擇本身研究一陣兒，由於本身有寫博客的一些經歷，被問過好多一搜索 or 本身一嘗試就能解決的問題，因此比較剋制，可是後來「入職 1v1」溝通的時候被說到有問題別本身死磕，半個小時沒解決儘可能就找一下旁邊的同事。摁？我一會兒就把個人「主動性」發揮了出來。面試

不過好記性也不如爛筆頭，找了一些工具記錄把這些「問題的答案」都記錄了下來，方便以後再查找，當時對於 Git 都不是很熟悉，也記錄了不少經常使用的命令在裏面，還有一些問題的反饋，甚至知道了月會要自我介紹，也打了一遍草稿記錄在了這裏：（那段時間真的問了好多問題，週報裏也手動感謝了坐我旁邊的兩位大佬..）spring

入職兩週的時候，雖然已經開始上手作一些簡單的埋點工做，但本身對於 Ruby 仍是不是特別瞭解和熟悉，趁着某一個雙休，抓着一本《Effetive-Ruby》啃了兩天，也把本身的學習輸出了一下：mongodb

2、逐漸可以上手

就這樣一邊熟悉，一邊開始接一些小需求，我記得我寫下的第一個 BUG，就報出了 6K 條記錄.. 慌慌張張在修復以後我不由感嘆：「不要太相信用戶的任何數據」。（包括 equal 反寫也是以後在錯誤之中學習到的..） docker

剛上手沒有一段時間，就接到了一個新項目的需求，跟着一位大佬開發一個新功能，大佬負責搭建基礎代碼和設計，我負責完成其他的功能代碼，沒敢一絲懈怠，下班回家以後也對照着別人寫的代碼敲敲敲，時間和完成度上卻是沒有一絲耽擱，只是如今回過頭一想，當時沒有什麼單元測試的概念和意識，就本身在本地 Post-Man 測試完就完，所幸比較簡單 + 本身測試得比較仔細，到如今也沒有出現過什麼問題。數據庫

工做對我這樣的小白另外一個好處就是：「見識和增長技術的廣度」。公司所使用技術棧不管是廣度仍是深度，都是本身在大學本科的學習中不可企及的程度，Jekins？Docker？K8S？跳板機？一會兒冒出來好多新鮮陌生的名詞，懷着好奇心也嘗試瞭解了一些：segmentfault

也隨着公司的逐漸壯大，各模塊的耦合也愈加嚴重，各條業務線之間的協做溝通成本愈來愈大，逐漸開始提出「微服務」這樣的概念，具體怎麼樣理解就不做討論了，總之就是指望經過梳理/ 重構/ 拆服務的方式來解決「協做」問題，因此期間也開始瞭解學習一些這方面的東西：

甚至期間還作了一些「微服務」的調研，咱們選用什麼樣的姿式和技術棧更加合適，因此也輸出了一些關於「Spring Cloud」的東西，可是最終駁回的緣由是待咱們整個容器化以後 k8s 平臺自帶了這麼一套東西，業務同窗只須要關心業務代碼就好了，也就沒有繼續深刻了：

而後咱們在拆解的過程當中，也借鑑到一些「DDD」的思想，也嘗試進行了一波學習：

總之，這一段時間我一邊經過各類小需求，接觸和了解了公司的系統的大半，一邊學習和了解着各類不一樣的技術，增長了技術上的廣度。

3、開始負責一些項目

爲了加速服務化的推動工做和驗證「DDD」的一些東西，部門老大把一個邊界足夠清晰，也足夠小的一個模塊單獨交給我，指望我快速上線，不過最終交付已經逾期快大半個月了.. 雖然從最終的結果來看，順利交付完成了拆解任務並從 MongoDB 數據庫轉變成了 MySQL.. 但期間也踩過好些坑，固然也學習到一些東西..

例如我真實地意識到「完美」這個詞的理想化。就拿設計 API 來講吧.. 本身就基於 RESTful 風格設計了好幾版.. 左想右想都以爲差一些，有一些接口以爲怎麼設計都不優雅.. 後來糾結一陣子也就放棄了.. 再例如寫代碼這件事情吧，好的代碼整潔的代碼是一次一次迭代和重構中出來的，若是一開始就想着寫出「完美」的代碼，那麼最終的結果可能就是寫不出來代碼。

另一個小插曲是，在作數據遷移的時候，我差點把線上服務器搞掛了.. 我在測試環境驗證了一把以後，就直接在線上進行操做了，由於當時對於數據庫的操做管控尚未那麼嚴格，加上本身對於線上環境的複雜程度認識不足，我就起了 50 個線程，去分批量地讀取 MongoDB 的數據遷移到 MySQL，形成了線上庫的性能報警，就趕忙停了.. 緊接着就被一羣大佬抓進了一個會議室作事件的覆盤..

說實話，我緊張壞了，第一次經歷這樣的算是「事故」的狀況吧，差一點線上就被我搞掛啦，一時間不知所措... 讓人感到溫暖的是部門老大隨即丟來的消息：

那天還有一些相關的同事都陪我寫覆盤郵件到了晚上 10：30，如今想來都十分感謝他們。後來回到家我還打電話給我媽，我說我在工做中犯錯了，我作了xxxx這些動做，你以爲我作的怎麼樣呢，老媽的回覆也讓人安心，只是如今想來，一些後續的動做能夠作得更好的...

由於「埋點」這件事涉及到系統的方方面面，我也藉此瞭解了不少不一樣的模塊，也是拜這一點所賜吧，後來我被派到各類各樣的支援任務中，一樣也由於對不一樣模塊都還不算陌生，都還算完成得不錯吧...

時間一晃，在公司就四個月過去了，也在這個過程當中從各個大佬那兒都學到了一些東西，在 8 月底發的週報裏面我寫下了如下的總結：

以後也跟着大佬碰了一些公司的核心模塊，期間也沒有中止在工做中不斷地作學習輸出：

4、回顧作的很差的部分

  • 對代碼尚未保持足夠的敬畏之心。

特別是一開始上手的時候，有時候甚至是在線上環境搞測試，後來愈來愈注重 codereview 和單元測試好了不少。

  • 溝通還不夠深刻/ 到位

有一次是臨時接到一個需求，由於「通用語言」沒有達成一致，致使最終交付的結果不符合產品的指望，最終咱們全部相關人員在一塊兒開了一個會，統一了「通用語言」，形成了額外的工做和負擔，拿到需求就應該確認好相關事宜的，越底層越細節越好，這方面的能力我仍然欠缺，但我已經持續在注意當中。

另外一次也是由於這一點，我須要幫助 A 系統擁有某一項功能，以前 A 系統已經介入了 B 系統完成了部分功能，我由於沒有進一步地確認 B 系統的現狀，就去接入了有完整功能的 C 系統，但其實 B 系統已經在上一週和開發 C 系統和 A 系統的同窗對接好了，並完成了相關功能的接入，少了這一部分的溝通，就形成了很多額外的工做量.. 因此「溝通」仍是很是重要的，也只能說持續進步吧...

  • 缺乏一些主動性

當我頭上掛着一些事情的時候，仍是可以保持着效率的，只是當我作完了，就時常缺少一些主動地思考了，一般都是被動地去詢問同小組的同事有什麼事情是須要幫忙的.. 雖然也積極地參與到本身感興趣的那些技術評審之類的事情之中，但彷佛效果都不佳.. 也沒有什麼實際好的輸出..

  • 接了一些私活兒黑活兒（沒有充分考慮團隊之間的配合）

由於「埋點」會接觸各個平臺的童鞋，而且時常變化和有一些新的需求，有時候直接繞過了一些環節，直接找上我了，我心想直接本身弄弄改改就能夠了，也就沒多想... 可是如今想來，這樣跨團隊的事情，不能越過「頂頭上司」私自進行，一方面常常個人 BOSS 不知道我接了活兒，另外一方面這樣的私自對接就會形成一些信息的流失，對於團隊以內仍是團隊之間都會形成影響...

5、回顧作得好的部分

  • 養成了閱讀的習慣

公司買書是免費的，也有本身的圖書館，同事也不乏喜歡閱讀學習的，因此跟着跟着就養成了閱讀的習慣，期間也學習到了一些方法論的東西，貼一下入職以來讀過的那些書吧：（技術類的就沒有囊括了）

其實天天閱讀的時間也不長，想我大學總共捧起的那麼些課外書，不由有些唏噓...

  • 早睡早起 + 晨間日記

早睡早起，從步入職場以來，就發現這樣的習慣會帶來一些額外的價值，例如一些閱讀我會放在早上，後來還加入了「晨間日記」，用來「回顧前一天的事情」和提早部署「今天的任務」，這不由讓我多了一份清醒，也讓如今不怎麼鍛鍊的我每一天精力更加好一些：（目前正在從印象筆記往 Notion 逐步遷移的過程當中）

  • 學習撰寫 Commit Message && 遵照一些 Git 規範

起初使用 Git 十分不規範，後來向大佬那兒學習到了如何標準地提交 Commit，包括 Commit Message 應該怎麼寫，我以爲這是一個很好的習慣，每個 Commit 都有上下文，而且還帶上了 JIRA 號，任務也很好跟蹤，雖然公司並無大範圍地盛行起來，但我以爲這樣好習慣應該堅持下來：

  • 任務進度及時反饋給相關人員

本身比較注意這一點，由於不這樣作會讓別人感覺不怎麼好.. 光是本身內心清楚是不行的.. 要保持信息的通暢才行，及時反饋是很重要的一步..

  • 本身先 review 一遍代碼

犯過一些白癡錯誤以後，就有些擔憂，逐步養成了本身先 review 一遍代碼的習慣..

6、小結 && 展望

總的來講，看着本身這樣一步一步成長過來，沒有很懈怠，本身就算比較滿意了，在工做中學習了不少東西，無論是技術上的硬技能，仍是溝通中的軟技能，也認識到了不少厲害的大佬和有趣的小夥伴們..

感恩在路上相遇，有幸共同行走過一段已然算是幸運，忽然翻看起本身的朋友圈有一句話說得好：「成長曆來都不是告別過去，成長是更加堅決的看向將來！」

期待一路同行的你們，都可以 Be Better！

按照慣例黏一個尾巴：

歡迎轉載，轉載請註明出處！
獨立域名博客：wmyskxz.com
簡書ID： @我沒有三顆心臟
github： wmyskxz
歡迎關注公衆微信號：wmyskxz
分享本身的學習 & 學習資料 & 生活
想要交流的朋友也能夠加qq羣：3382693
錢
本文由博客一文多發平臺 OpenWrite 發佈！
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程