In order to do that, you have to understand the problem the software solves. In order to understand unknown code, you have to understand what the software does – or is supposed to do.
This one seems to be overlooked fairly often. Still, if what they left behind is an unintelligible mess of code with no documentation and other clues, it’s their fault and they have the obligation (moral, professional, sometimes even legal), to make good for it. It may be hard to get a hold on them, and they may not have time to help you much. In some cases, there is only one person who knows about the code you are going to work on, and that person may even have left the company. Do some pair programming or discuss with them how you approach typical tasks. If they’re still on the team, it’s usually a good idea to work closely with them for some time. That does not mean that asking them should always be your last resort. They may or may not be still in the team or organization, but it’s always good to know someone to ask if everything else fails. No matter how clear the code and how good the documentation, it is always beneficial to have someone who has worked on the same code base. Where should we begin to look, what parts of the code base are the most important? Find someone to answer your questions For large code bases, this may be quite a big task. Instead, we are presented with an existing code base and now need to find our way through it.
We rarely do green field development and start from scratch. It’s a common situation we face when we join a new project. I recently got an email, asking me how I approach an unknown code base. 1 Find someone to answer your questions.
0 kommentar(er)
