新工作角色是一个Java工程师，参与费用报销审批和付费系统开发，纯后端。上班4周之后，发现自己走了一段弯路，在此分享一下，如果被喷也知道自己是有多二，免得自己以后再走弯路。
入职当天，经历一些列流程了解考勤制度、认识自己的Team、听老大讲目前Team开发的业务、了解系统的历史背景。接下来就是分配各种账号，各种权限。最终，我看到了项目的需求，拿到了系统的代码并在IDE里面run了起来。
第1周：我要做什么（我能做什么）。 由于我是新来的，所以还是先找个和业务关联性较差的需求入手。接下来，理解需求，确定技术路线，找小伙伴们确认，然后码代码，单元测试，集成测试，产生价值的时候来了---合代码。Git仓库，多分支开发，测试环境，开发环境，线上环境代码，最终总算搞清楚如何把我的代码提交到仓库。
第2周：我想做什么。当时没想太多，觉得先从代码结构角度去了解业务吧。微服务架构，偶尔可见Dubbo身影，搭配工作流Activity，依赖用户中心，支付服务等。但是跳出代码，我还是无法了解到业务的"葡萄藤"，只能看到外面的一个个"葡萄"。中间也接了一些与业务无关，纯粹是技术重构的工作。神奇的是，我居然在不了解业务的情况下，纯粹通过技术视角完成了重构，并且在单元测试的时候发现了一些潜在BUG。
第3周：我该做什么。前面的任务完成，我依然感觉眼前的这个系统是个黑盒，不太理解业务是什么样的，以至于每当老大问一些问题的时候，总觉得词汇有些生涩，有些不太明白，和他的视角不一致。听完他的讲话，下来理解时发现，当时的对话简直是对牛弹琴，因为我当时对基础名词理解有着离谱的偏差。带着这种感觉，我从已知的业务中理出了一条主线，沿着这条主线深入到具体的代码中，似乎了解得更多了一些。
第4周：哪里不对。我现在做的事情似乎在主业务线的边缘，所以，我仍然没有切入业务。回首这条切入路线，纯技术角度，和业务的关系不大。于是重定位目标，了解业务，然后再结合技术架构，知道哪块业务代码大概在哪个位置，核心的业务是什么，未来又会是什么样的。我犯了一个非常基础的错误：技术服务于业务。无论什么技术都是业务驱动的，所以业务是灵魂。纵然是一个技术人员，也得清楚对公司而言，业务是有意义的，对个人而言，技术是有意义的。所以，首先理解业务。要测试账号，登陆系统，每个功能都点点，用用，这样就知道系统是做什么的，有哪些业务场景，结合目前的一线反馈，知道哪里是系统的软肋，老大开会时为什么老是强调那些个问题，老大的期望又是什么。似乎我有十万个为什么，但是好像很快都将迎刃而解。
总结一下，搞清楚自己的主线，不能被胆怯，他人的影响给带偏了。觉得不对，及时反思，虽然1个月，但我刚刚从蒙圈的状态想过来，悄悄对自己说，还好不是2个月。
