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

楼主是后端工程师，现在还是**一只。
感觉组里面的每一段代码都严格体现了business log，不知道为啥每次自己做ticket的时候，自己都不能准确的掌握business logic，总需要不停地问同事。而且，我发现虽然组里的PRD（product requirement document）已经把大概的方案都写清楚了，可是我自己很缺乏敏感性，即便读了好几遍PRD，对于一些细节似乎并没有完全吃透，可是自己又发现不了自己没有完全搞懂。
请问，我该怎么去改进呢？怎么完全掌握项目的business logic呢？

认真回复必加米！ 谢谢！

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

光看代码，或者只看unit test基本没什么用。

我觉得代码必须要能运行起来，能设断点。哪怕是在unit test里面设断点，能跑起来也行。
只要代码能跑起来，能在断点上debug，在ide里面能看到各个变量的内容。基本上可以说，不管什么任务，你已经成功了99%。
剩下的1%，就是写一些垃圾代码，在屎山上修bug或者实现新的business logic。

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

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

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

不懂你这里说的business logic 是指什么？
个人有个学习新代码库的技巧是
1. 读unit tests 跟 integration tests
2. refactoring. break it and learn it.

匿名者 发表于 2022-6-20 10:33
不懂你这里说的business logic 是指什么？
个人有个学习新代码库的技巧是
1. 读unit tests 跟 integration  ...

请问第二点是什么意思，可以详细解释一下吗？回复再加米，谢谢！
2. refactoring. break it and learn it.

看代码，读代码是最快的方法，任何的wiki都可能过时，code是最up to date的

kate8528577 发表于 2022-6-20 13:30
看代码，读代码是最快的方法，任何的wiki都可能过时，code是最up to date的

本人感觉读代码还挺费脑子的，是不是需要继续锻炼一下读码能力啊？
谢谢

读代码确实是最准确的方式，也要当心读到deprecated 的代码。确实很花时间，几十个小时要能搞懂一个service，已经效率很高了。不过反过来，大部分人都不会去看，都是去找那些team里的人问，所以你要愿意花时间去搞懂，自己受益，也可以advise其他人，增加impact。

匿名者 发表于 2022-6-20 15:10
读代码确实是最准确的方式，也要当心读到deprecated 的代码。确实很花时间，几十个小时要能搞懂一个service ...

. 1point3acres感谢建议！

匿名用户 发表于 2022-06-20 14:34:56
本人感觉读代码还挺费脑子的，是不是需要继续锻炼一下读码能力啊？
谢谢

Short answer: Yes.
If you know how to read, you can write

匿名用户 发表于 2022-06-20 13:57:58
请问第二点是什么意思，可以详细解释一下吗？回复再加米，谢谢！
2. refactoring. break it and learn it.

Refactoring就是不改变现有功能的情况下，让代码变得更好。你可以看Martin flower的书。

你在refactoring的过程中会break 很多test cases. 在这个过程中可以更深入地了解代码