怎么完全掌握项目的business logic呢

想要完全掌握很难 一方面复杂系统的用例太多 一方面不断有新的功能在开发 再加上上下游的改动 所以很难

一般能够确定主干逻辑就够用了 关注功能模块的接口和具体实现 确保出入口的日志和异常处理 往往定位是很简单的 其实PRD最终反应到代码上 如果有不匹配 反而往往是PRD过时了

说读代码的估计是代码库太小，大的不是随便读读就能看出故事。说设断点看stacktrace估计没有玩分布式系统。我觉得这些方法都是好方法，但是不会帮助你“完全”掌握，完全掌握的唯一方法就是花大量时间去读代码、写代码、读文档、写文档、听会议、讲会议，多花时间、静下心来是唯一的捷径。
另外，完全掌握一个项目是一个很高级的目标，大多数工程师都是只见树木不见森林，活也能干得很好。再有就是多看看书，很多书会娓娓道来一个项目的从生到死，既有细节又有大局，这样的技术书籍很多，看几个领域相关的或有顿悟，再结合实际工作，学而思之，思而学之，可期突飞猛进，独步天下。

同意楼上说的，
读代码没用，因为代码量可能很大，
设breakpoint也没用，因为有多线程和分布式

读unit test/integration tests？这个只有test coverage做的好的大厂才行吧，当然如果有的话，这是正解
读documentation？不好意思，startup不爱写doc，如果有doc，这个是备用解

没test，没doc，那该咋办呢？
move fast，break things，bug修多了你就懂了...

自己有权限的话，就是把code pull下来，然后自己写一个小service call / test case去测试。我最近需要用一个别组的服务，可是他们onboarding做的太慢了，刚好我也有权限，就干脆自己试着做。把新东西offline加在他们service上，然后在beta上跑几次，跟着error logs把遇到的bug全解决了之后很快就知道各个module是干嘛的了。

找组里人聊天，1:1

多问多聊呗

跑unit test，设断点，画sequence diagram

读doc+问掌握high level，读源代码掌握细节。如果你是能直接读源代码的牛人，可以跳过doc+问