如果你是剛走上工作崗位的畢業生，或者是工作一兩年但是不得其法的新人，是不是也有以下這些困惑：爲啥我寫的代碼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。這個方式很有幫助，我自己也是這麼成長起來的。
- END -
「技術分享」某種程度上，是讓作者和讀者，不那麼孤獨的東西。歡迎關注我的微信公衆號：「Kirito的技術分享」
本文分享自微信公衆號 - Kirito的技術分享（cnkirito）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。