I’ve joined as a fresher (trainee) a software company developing for Windows Store. I don’t know much about C#. My company has started Windows Store development recently. They didn’t do .Net development before, that’s why my company got an Senior .Net employee to complete the project.
Whenever he completes the project he will leave the company. I will have to maintain the project after him. So I need to study the project flow and analyze the project to be able to maintain errors in future.
Can you suggest how to start to analyze the project and what to pay attention on?
5
Where to begin depends on if you are familiar to the technology you’re using. I don’t think that you need to have a deep knowledge of the technologies, but having a firm understanding of how things work is necessary.
Start from the documentation. First read the requirements to have a clear picture of what the project should do. Than try to analyze the architecture to get an overview of the structure of the project.
When you’re done, have a discussion of the architecture with the senior developer, try to understand why this or that decision was made.
And only after this dive into the codebase. Read, debug, execute, change/break the code to understand it. If anything isn’t clear, don’t spend to much time trying to figure out on your own. Ask questions. Take small tasks on the project and complete them.
You need to do as much as you can before the senior developer leaves. So pay special attention to the things that are most difficult to figure out on your own. Start from those things.
Load it up in Visual Studio. Pick some small part of it, some form or page, and set breakpoints in the load events, and then step through, line by line, section by section until you begin to see a pattern emerge.
If you don’t understand something, take a guess, look up syntax to see if you were right. Hovering your mouse over variable names will give you details of what’s inside.
After several run-throughs, you may begin to see what the senior developer was trying to achieve, and why.
When your coffee-cup is empty, take a break. 🙂
1
Sometimes, it takes a more skilled engineer to be able to maintain a less skilled engineer’s code.
If the project is simple, it could be worth the struggle to write it yourself, because it will also be a struggle to understand somebody’s code within such a short time and you are a fresher.
If the project is complex, your company should really wait to hire a long term and more experienced engineer.
To have a developer leave right after the first roll out is such a bad idea for all involved. Most programs have some critical bugs at first, and if success(relatively speaking) for the first roll out is important, you are likely heading for failure. If first roll success is not important and can wait, then again why not wait for a more experience employee to come along or let you take your time to build something new?