如果你是剛走上工作崗位的畢業(yè)生，或者是工作一兩年但是不得其法的新人，是不是也有以下這些困惑：為啥我寫的代碼TL一直不滿意？為啥加班很多，也很辛苦，但是最終的產(chǎn)出還是不夠？如果你有類似的疑問，那么今天這篇文章就是為你準(zhǔn)備的。

今天這篇文章要講的主題是：作為初入職場或剛剛轉(zhuǎn)行Java開發(fā)的同學(xué)，如何進(jìn)階成為一名靠譜的工程師？不需要懂DDD、不需要懂TDD，也不需要懂分布式架構(gòu)設(shè)計(jì)，只需要達(dá)到最基本的要求——能理解需求、能做簡單的設(shè)計(jì)和產(chǎn)出系分文檔、能寫出BUG較少的代碼，能完成單元測試和功能測試，并最終交付功能。

1. 動(dòng)手開發(fā)之前要做什么？

新同學(xué)拿到一個(gè)需求后，大概看了下，在心中打個(gè)腹稿，就準(zhǔn)備動(dòng)手了，例如：前幾天我讓跟著我的外包同學(xué)做一個(gè)系分設(shè)計(jì)，過了一天，在我準(zhǔn)備驗(yàn)收系分文檔的時(shí)候，發(fā)現(xiàn)他代碼已經(jīng)寫了很多了，但是，不好意思，需求沒理解清楚、整個(gè)業(yè)務(wù)的流程也沒有理清楚，可想而知，這種情況下寫的代碼大半是不能用的。

工作久了你會(huì)發(fā)現(xiàn)，動(dòng)手寫代碼（做事）其實(shí)是最簡單的部分，難的是在動(dòng)手之前，搞清楚以下事情：

• 需求的背景（why）

• 要解決什么問題（Target）

• 要解決到什么程度（質(zhì)量）

• 有多少資源（時(shí)間和人力）

• 解決方案的流程是什么樣的（整體思路）

• 有哪些難點(diǎn)和容易出錯(cuò)的點(diǎn)（key point）

• 改動(dòng)的點(diǎn)和老的系統(tǒng)是如何交互的（對老系統(tǒng)的理解）

• 如何保證功能的平穩(wěn)上線（不能靠回滾發(fā)布來應(yīng)急）

• 如何驗(yàn)證這次的改動(dòng)和開發(fā)是符合預(yù)期的（測試用例，以終為始）

• 要做哪些事情，每個(gè)事情需要多久，這些事情之間的拓?fù)湟蕾囀窃鯓拥模üぷ髁亢凸r(shí)評估）

上面這些事情，就是你需要在需求評審、系分評審、測分評審等會(huì)議前要準(zhǔn)備充足的內(nèi)容，如果在動(dòng)手之前，上面的問題無法很好得回答上來，就是在埋雷，會(huì)在開發(fā)后期付出更大的時(shí)間成本和溝通成本。當(dāng)然，如果在動(dòng)手之前能夠回答清楚上面的問題，那么開發(fā)的過程對于你和你的TL來說，就會(huì)清晰和簡單很多。

2. 開發(fā)過程中要注意什么？

開發(fā)過程中的要求，主要是對代碼質(zhì)量的要求，最基本的有四點(diǎn)：可讀性、模塊化、健壯性、擴(kuò)展性。圍繞上面這四個(gè)點(diǎn)，對于代碼的基本要求有：

• 變量的命名不能過于隨意

• 函數(shù)的命名不能過于隨意

• 函數(shù)不能太長

• 一個(gè)函數(shù)中要用空格將不同的邏輯區(qū)分出來

• 基于業(yè)務(wù)功能劃分模塊，優(yōu)先于基于技術(shù)特性劃分模塊

• NPE、數(shù)組越界、異常捕獲等最基本的要搞定

• 盡量使用apache的工具類，不要自己寫

• 基于接口（API）而不是實(shí)現(xiàn)開發(fā)

• 寫完一個(gè)方法，就把單測補(bǔ)上

• 寫完一個(gè)模塊就做下模塊測試

• 單測必須帶Assert，不能給一個(gè)假的（如何寫好單測我之前有文章寫過）

• 單測工具有Mockito、PowerMock、JUnit、TestNG等等

• 功能測試盡量做成自動(dòng)化的，實(shí)在做不到，也需要將測試的步驟記錄成文檔，降低執(zhí)行的成本。

如果你能在開發(fā)過程中遵循上面的這幾個(gè)要點(diǎn)，相信你交付的代碼質(zhì)量也會(huì)有一定的保證。這里我也不準(zhǔn)備再去討論那些高大上的詞語，例如：TDD、BDD、DDD等，對于新同學(xué)來說這些統(tǒng)統(tǒng)沒有用，盡快能交付可用的代碼、可維護(hù)的代碼比什么都重要。

3. 有哪些雷區(qū)必須避免？

每個(gè)人都是從新手成長起來的，所以作為TL和師傅，其實(shí)特別理解新人的成長經(jīng)歷，也能接受一定程度的錯(cuò)誤，犯錯(cuò)才是積累經(jīng)驗(yàn)的最佳機(jī)會(huì)，所謂“吃一塹長一智”。不過有兩個(gè)點(diǎn)，是我作為師傅時(shí)候的底線：

• 沒有測試的代碼不能提交，這個(gè)是作為工程師最基本的底線，哪怕前面說的那些全部都做不好，這一點(diǎn)也是不能逾越的底線。你可能會(huì)說，我也沒有把握有沒有測試到位，沒關(guān)系，那就多測幾次，如果不知道自己測試得對不對，說明前面梳理測試用例的時(shí)候沒有想清楚。

• 避免犯同樣的錯(cuò)誤，犯錯(cuò)是必然會(huì)出現(xiàn)的現(xiàn)象，但是如果相同的錯(cuò)誤不斷地犯，那真的是很難有所成長。這里我跟我的徒弟有個(gè)小經(jīng)驗(yàn)，類似于上學(xué)時(shí)候的錯(cuò)題集一樣，將自己在開發(fā)工作中犯的錯(cuò)誤記錄下來，每個(gè)項(xiàng)目和需求結(jié)束之后做下review。這個(gè)方式很有幫助，我自己也是這么成長起來的。