初級工程師如何在職場生存

若是你是剛走上工做崗位的畢業生，或者是工做一兩年可是不得其法的新人，是否是也有如下這些困惑：爲啥我寫的代碼TL一直不滿意？爲啥加班不少，也很辛苦，可是最終的產出仍是不夠？若是你有相似的疑問，那麼今天這篇文章就是爲你準備的。

今天這篇文章要講的主題是：做爲初入職場或剛剛轉行Java開發的同窗，如何進階成爲一名靠譜的工程師？不須要懂DDD、不須要懂TDD，也不須要懂分佈式架構設計，只須要達到最基本的要求——能理解需求、能作簡單的設計和產出系分文檔、能寫出BUG較少的代碼，能完成單元測試和功能測試，並最終交付功能。

1. 動手開發以前要作什麼？

新同窗拿到一個需求後，大概看了下，在心中打個腹稿，就準備動手了，例如：前幾天我讓跟着個人外包同窗作一個系分設計，過了一天，在我準備驗收系分文檔的時候，發現他代碼已經寫了不少了，可是，很差意思，需求沒理解清楚、整個業務的流程也沒有理清楚，可想而知，這種狀況下寫的代碼大半是不能用的。

工做久了你會發現，動手寫代碼（作事）實際上是最簡單的部分，難的是在動手以前，搞清楚如下事情：

• 需求的背景（why）
• 要解決什麼問題（Target）
• 要解決到什麼程度（質量）
• 有多少資源（時間和人力）
• 解決方案的流程是什麼樣的（總體思路）
• 有哪些難點和容易出錯的點（key point）
• 改動的點和老的系統是如何交互的（對老系統的理解）
• 如何保證功能的平穩上線（不能靠回滾發佈來應急）
• 如何驗證此次的改動和開發是符合預期的（測試用例，以終爲始）
• 要作哪些事情，每一個事情須要多久，這些事情之間的拓撲依賴是怎樣的（工做量和工時評估）

上面這些事情，就是你須要在需求評審、系分評審、測分評審等會議前要準備充足的內容，若是在動手以前，上面的問題沒法很好得回答上來，就是在埋雷，會在開發後期付出更大的時間成本和溝通成本。固然，若是在動手以前可以回答清楚上面的問題，那麼開發的過程對於你和你的TL來講，就會清晰和簡單不少。

2. 開發過程當中要注意什麼？

開發過程當中的要求，主要是對代碼質量的要求，最基本的有四點：可讀性、模塊化、健壯性、擴展性。圍繞上面這四個點，對於代碼的基本要求有：

• 變量的命名不能過於隨意
• 函數的命名不能過於隨意
• 函數不能太長
• 一個函數中要用空格將不一樣的邏輯區分出來
• 基於業務功能劃分模塊，優先於基於技術特性劃分模塊
• NPE、數組越界、異常捕獲等最基本的要搞定
• 儘可能使用apache的工具類，不要本身寫
• 基於接口（API）而不是實現開發
• 寫完一個方法，就把單測補上
• 寫完一個模塊就作下模塊測試
• 單測必須帶Assert，不能給一個假的（如何寫好單測我以前有文章寫過）
• 單測工具備Mockito、PowerMock、JUnit、TestNG等等
• 功能測試儘可能作成自動化的，實在作不到，也須要將測試的步驟記錄成文檔，下降執行的成本。

若是你能在開發過程當中遵循上面的這幾個要點，相信你交付的代碼質量也會有必定的保證。這裏我也不許備再去討論那些高大上的詞語，例如：TDD、BDD、DDD等，對於新同窗來講這些通通沒有用，儘快能交付可用的代碼、可維護的代碼比什麼都重要。

3. 有哪些雷區必須避免？

每一個人都是重新手成長起來的，因此做爲TL和師傅，其實特別理解新人的成長經歷，也能接受必定程度的錯誤，犯錯纔是積累經驗的最佳機會，所謂「吃一塹長一智」。不過有兩個點，是我做爲師傅時候的底線：

• 沒有測試的代碼不能提交，這個是做爲工程師最基本的底線，哪怕前面說的那些所有都作很差，這一點也是不能逾越的底線。你可能會說，我也沒有把握有沒有測試到位，不要緊，那就多測幾回，若是不知道本身測試得對不對，說明前面梳理測試用例的時候沒有想清楚。
• 避免犯一樣的錯誤，犯錯是必然會出現的現象，可是若是相同的錯誤不斷地犯，那真的是很難有所成長。這裏我跟個人徒弟有個小經驗，相似於上學時候的錯題集同樣，將本身在開發工做中犯的錯誤記錄下來，每一個項目和需求結束以後作下review。這個方式頗有幫助，我本身也是這麼成長起來的。
• • *

我的簡介

我目前在螞蟻集團作風控技術開發，跟黑灰產作鬥爭，保障螞蟻生態內的內容信息安全。咱們團隊還有大量hc，持續招人中，若是你有興趣和我一塊兒工做或交流，能夠直接加我我的微信。