自学java入行工作的第十四个月
自学java入行工作的第十四个月
目前我做的工作一是维护项目，主要是修改bug、功能缺陷、新功能；二是新项目开发，主要负责一个单表接口开发和后管页面。不论新老项目，总的来说就是一件事，写业务代码，主要问题一是需求描述不清；二是第三方接口的对接很恶心；三是原来开发的功能不完善；四是奇怪的bug
bug：
- 反应过来有问题，我一查就没问题。。。
- 用户明明做了某一部操作，然后说什么都没干就这样子，怪功能不行，直接找日志打他脸
- 项目经理不懂流程说成是bug
- 找日志困难，没有日志追踪，找bug困难
需求：
- 需求很抽象——就几个很抽象的页面，然后说就这样子就行了很简单，我也说了不能这么做会出问题（可用性、稳定性差），上线之后就各种问题，永远要把用户当成白痴
- 需求沟通困难——因为是自己维护的项目，所以也比较熟悉，一看需求我就知道怎么做了，但是跟产品沟通实际实现的时候往往要解释很久，因为产品虽然也是技术出生但是功能实际实现代码不知道。还有就是需要跟售前掰扯，因为售前不懂技术。
- 需求情景不明确——售前提需求的时候不说明这个功能是什么情况能触发，导致我开发完之后还要改，因为我刚接手对于一些业务不了解
- 需求无法实现——无法实现的原因，一般都是第三方不支持导致我这边没法做，其次就是需求提的很无语，异想天开。
- 需求甩锅——对接方刷锅说他们数据、接口没问题；需求做完了然后需求经理说这个需求不是这么做的。。。
- 改需求——都确认了没问题，都改了好了，结果说要重新改一下。。。
- 自研与外包的区别在于前端，我也做一些前端，很无语——随便弄弄不就完事了，字体颜色什么的还要搞
三方：
- 很抽象的接口——调用充值接口始中返回成功，三方说防止我们调用失败。。。调用对账接口始中返回成功，三方说这个接口是把你的记录和我们库里记录对比，对缺少的接口进行充值。。。
- 很抽象的设计——门锁的密码删除修改都是拿到他们的库里的记录id修改，然而这个id始中会变，假如有一个id为3的记录，当你把id为2的记录删掉后，id为3的会变成2，也就意味着，删除修改等操作要调接口去获取。token失效了也不会返回token失效的错误code，导致根本不知道token是不是失效了
- 很抽象的三方后管——你在你以为的菜单标题中获取不到想要的数据，比如你想要查交易记录，然后进入了交易记录这个菜单，但是他查出来的是用户信息。。。
- 很吊的三方——把请求参数返回内容完完整整的截图给他，他只会改参数文档错了都不知道，调不通就说我们都能用的，你自己研究吧。。。
功能开发：
- 功能完善度——没有删改接口，原来并不是所有程序员都会把功能场景思考充分，考虑用户体验，现在就是我在背锅
- 项目结构复杂度——虽然是二开，但是我发现实际并没有用到开源框架主要的功能，唯一用到的是用户管理模块。但是却完整继承了开源项目的各种modle，wrapper、viewer啥的层
总结:
- 需求开发全程都要有记录，不要以自己的想法去开发功能
- 开发前确认需求，充分考虑场景，描述开发复杂度和预计开发时间
- 开发中有问题及时反馈，关键处一定要打印日志
- 开发后准确描述功能和具体使用场景，后期可能会产生的问题，以及对应的解决方案
- 上生产前确认测试完毕，功能正常且符合需求
- 上生产后及时测试，及时反馈，做好回退的准备等等
