I'm trying to solve a complex bug in our codebase , but the problem seems to be coming from a lot of places to the point that i dont know what to change first .
do you have any procedure or guidelines todo in such a situation ?
Don't start by making changes, start by reproducing the bug in unit tests. After that change the code so that the unit test passes instead of fails.
Sounds like you have multiple bugs, not just one, start at the lowest level, identify specific bugs, write failing unit tests and fix.
First, analyze the problem. Don't start making changes until you understand the codebase. Start by reading the design documentation (class, sequence, and communication diagrams would be a good start) and in code comments. Use logging (that's what TRACE and DEBUG level logging is for), a debugger to step through code and watch variables as they change. This is also a good time to make notes if the design documentation and/or in-code comments are wrong - fix them for future developers.
Second, once you understand the codebase, come up with test cases to identify the problem and confirm that you've fixed this. There might be unit tests, system tests, and acceptance tests associated with the problem that need to be created or revised. You're going to want to make sure that you have fixed the defect, that your fixes don't introduce other defects, and that this defect doesn't appear again as the result of a regression.
Finally, you can fix the defect. Run your tests to confirm, and if any documentation is affected, either update it or file a defect against the documentation so that any changes you made are reflected for the user or future developers.
the problem seems to be coming from a lot of places
Fortunately, this is probably false. Bugs can be caused by all sorts of different things, but when you see a bug cropping up all over the place, you can bet that the instances of that bug all lead back to one place. This place could be some corrupted data in a SQL table, a funky setting in a config file, or a piece of bad application logic that a lot of components touch. It could also be a million other things, but the key is always to figure out what the different instances of the bug have in common. Tools can be a huge help. Use a SQL profiler for data heavy stuff. I recently had to fix a proprietary system that had close to 15,000 stored procedures. One of them went haywire during an update that conflicted with some of the modifications I had made to the system. Without a SQL profiler, this fix would have been more or less impossible. If you rule out a data issue, your number one goal is to find that line of code where the bug is created. With a good trace log, a debugger, and some common sense, you can track down just about any bug.
To solve complex multiple bugs ("coming from a lot of places"):
This is the general tried and tested approach I take:
2) Debug mode ON
3) Try until you reproduce the bug
4) Inspect logs and debuggers
5) Change code accordingly
6) Try to reproduce the same bug again
7) Go back to step 3 unless the bug has been fixed.
From now on, you will include this particular bug test together with your other tests, as you want to be sure it won't show up again. Forget about "But that's not gonna happen again!".