3 ms·
I would think the default assumption for a large codebase is that the code changes regularly. And especially if you are looking for a bug that started after a r
by jjk166 2y ago
I would think the default assumption for a large codebase is that the code changes regularly. And especially if you are looking for a bug that started after a recent push, checking the revision history seems like the very first place you'd look.
- yuliyp 2y agoIn this case the code went from bad -> good. The bug had existed for a long time before it finally got triggered in a catastrophic way. Even a large codebase has parts that are relatively stable. `fbagent` in this situation was a service responsible for gathering metrics, which is something that doesn't need that many changes (relative to, say product code) to it once it works.
- jjk166 2y ago> In this case the code went from bad -> good. That doesn't matter, the code changed. It's not like you can know what effects changes had before checking whether changes occurred. > The bug had existed for a long time before it finally got triggered in a catastrophic way. The issue isn't missing that one bug, it's not realizing that the code you are looking at isn't the version of the code on the affected machine. > Even a large codebase has parts that are relatively stable. `fbagent` in this situation was a service responsible for gathering metrics, which is something that doesn't need that many changes (relative to, say product code) to it once it works. Clearly changes were nevertheless happening. I don't care if you're dealing with a COBOL program that hasn't been updated since the 80s - if you have a problem now, I just don't see any reason why you would ever not check the revision history.