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反饋,不要自己悶頭苦幹,最後導致專案延遲或者導致重大事件的出現,領導最不喜歡這樣的下屬。
「其他文章」