Gitlab上手指南（一）｜作為新手第一天入職，你該幹什麼？
前言
歷經千辛萬苦終於入職了一家心儀的公司，作為新手第一天入職，你該幹什麼？本文以這個內容開頭，是為了告訴新手玩家，當你入職一家網際網路公司的時候，你應該注意什麼？才能在公司好好的混下去。
PS:謹記第一條，在公司先活下去
入職培訓
首先，人事小姐姐會帶你去辦理入職手續，填寫和上交入職材料，然後就是入職培訓，會介紹一些關於公司背景，考勤，福利待遇等方面的內容。
熟悉環境
入職培訓完畢，你的直屬Leader或者你的小組長會帶你去熟悉公司的環境，帶你認識你們部門的大領導和後面經常打交道的同事---前端（FE）、後端（RD）、產品（PM）、測試（QA）、設計（UI）,這些人就是你接下來頻繁溝通的同事。
開發環境安裝配置
一般前端程式設計師在公司常用的有Node、Vscode、Git、Google這幾個就可以辦公了，其他的軟體根據個人需求再安裝。
環境安裝好了，就可以clone程式碼了，你組長會讓你先熟悉你負責的相關業務和程式碼，就可以慢慢看了。
檢視公司規範
對於才入職的同學來說，想要快速融入集體，首先就的瞭解公司的相關規範，例如程式碼書寫規範，UED規範等等
每個公司前端基本上都有自己的規範，主要包含以下幾大類：
- HTML規範
- CSS規範
- js程式碼規範
- Eslint規範
- commit規範
這些規範基本都有文件可查，如果沒有你，那就可能你的KPI（績效）就來了。
熟悉公司開發流程
開發流程
- 需求評審-產品拉會講述本期需求的功能點
- 技術評審-技術調研，技術難點，開發排期等
- 需求開發-正式進入開發週期
- 需求提測-開發完成，提交測試
- 修改bug-測試提交bug
- 需求showcase-測試驗證完畢，給產品演示功能
- 上線-上線分為預發和線上，一般會測試發預發，整體迴歸一遍功能
開發流程圖
產品需求評審注意事項
在需求評審之前最好好好看看需求文件，知道要做什麼功能
對需求有疑問，多提問，多溝通協商，最好達成統一意見
專案開始
- prd，隻字不差的閱讀。
- 評審提問題
- 在wiki列列排期（細分任務）
- 寫虛擬碼，做設計
- 思考難點，提出來，提前調研
- 有問題，主動協商
- 需要什麼樣的介面，梳理出來
- 檢查有沒有方案不妥的地方，找出解決方案，去和產品協商
- 提煉難點，寫demo跑通，保證主流程能通
- 讓配合人明確提供相關需求的時間點
- 提測時：把master分支的程式碼合併到自己的分支上面
- 測試完畢準備上線時：再次把master分支的程式碼合併到自己的分支上面
- 上線完畢：迴歸完成後，把分支merge到master
專案開發
- 專案中sentry要區分，測試，開發，線上環境
- 解決完sentry後要點，已經解決
- 異常，或業務場景需要主動上報到sentry（方便定位問題）
- 數字不允許寫在業務程式碼中
- 超過三層巢狀思考一下，是否有其它方案
- commit資訊，儘量描述清晰，讓閱讀者，能直觀閱讀到做的事情。
- 提測前，要經過leader稽核。
- 抽離可配置的引數到配置檔案中
- 命名要有意義
- 邏輯性需要重點說明，務必加上註釋
- 在開發過程中，儘量減少報錯。
- 業餘時間，多看看自己組的專案，有問題及時提出。
- 任何按鈕要考慮，函式節流，防抖 （呼叫api）
- 不要把沒用的註釋程式碼提交
- 不要提交 無用的console.log 程式碼
- 修復bug 使用 fix分支
- 增加新特性的時候，使用feature
- 不要想當然，反覆確認最終結果是不是自己想要的。
- 有效及時溝通
- 培養owner主動意識
- review code 培養起來
- 反思一下自己的交付質量
- 約束一個時間
最後
希望你能在公司順利的轉正，在工作中不懂的問題及時跟同事溝通，遇到解決不了的事情及時跟你的Leader反饋，不要自己悶頭苦幹，最後導致專案延遲或者導致重大事件的出現，領導最不喜歡這樣的下屬。
「其他文章」