平时多跟老员工聊天，多干半年自然就知道了

根据我个人的经验，多聊天，尤其是找 PM 聊，不懂的直接就问，一般他求你的时间比较多，所以你找他他不会拒绝的，任何问题不明白，大到需求的背景，小到术语的意思，都当场、直接打断的可以问，你是应届生有这个资格，别怕丢人记住不明白的就要问，不要自己瞎理解自己琢磨，别怕麻烦别人，他麻烦你的时候他就不内耗对吧，大不了下次你免费给他改需求就行了，互利的事情他很乐意的 但关键是，别同一个问题问好多遍，别人讲了很多遍别人也烦的，上点心记一下 另外这方面 i 人确实没办法，程序员闷的也比较多，你想了解就需要转变的，希望你不是 i 人

多加班（不是 PUA ）,多干项目，多看已有的代码（不跟你相关的也看），多思考。 谁不是从菜开始的。 如果既想到点就走，又想有成绩，那不是做梦吗。

如果是为了快速熟悉业务，查漏补缺，你的计划是可行的。但我更建议使用 markdown + 序列图，这好处是粒度可以很好的控制。 我之前为了快速上手，也是把业务主流程的方法都用序列图画了一遍，尽可能的细。 从事后来看，这样做好处还是蛮大的，不管是接新需求还是定位问题都能很快解决。 但也不是说你画我完就很懂了，你只是知道了这个流程，怎么做的，做了什么事，但还是会有不少地方不清楚，这是正常的。 如果简单的，你可以直接问同事，但太长太复杂的就自己把握个度，大家上班都有活要做，也不是所有人都有耐心跟你讲。 后面就随着接到新的需求，慢慢理解完善吧。还是需要靠时间和需求来喂的，有机会就主动问就是了。 业务表结构这些可以先扫一遍，在脑子大致推理一下数据的流转，再去看代码。 业务代码会很清楚的告诉你每张表和字段怎么用的，侧重点放代码上。 从表结构上是看不出细节的，有可能你脑子里想的，和实际业务流转是有出入的。

too young ，老油子都是一问三不知

多问为什么，一个项目或者任务来了，搞清楚来龙去脉，业务为何要做这个项目和功能，有没有其他更好的实现或者思路

不理解，只跟产品对接，无情的代码执行机器。

“我感觉我每次看到需求都已经尽力去想可能的场景并跟组长确认好了再写了” 这是对的了，多问多想！