如果你是刚走上工作岗位的毕业生,或者是工作一两年但是不得其法的新人,是不是也有以下这些困惑:为啥我写的代码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,持续招人中,如果你有兴趣和我一起工作或交流,可以直接加我个人微信。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。