如果你是刚走上工作岗位的毕业生，或者是工作一两年但是不得其法的新人，是不是也有以下这些困惑：为啥我写的代码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。这个方式很有帮助，我自己也是这么成长起来的。