Campbell Ritchie wrote:What do you know about the old code? Do you know how it works? Has it got a recognisable public interface you can use?
Junilu Lacar wrote:Even as an experienced developer, I would ask for someone who is more familiar with the code base to pair up with me and kind of show me around. I would first ask where the tests are. I would try to get a better understanding of the high level architecture and learn how the program code has been organized around it. Knowing that, I would then ask to be shown around the part or parts of the code that I will probably have to integrate with. This is all about building the context around the problem I'm trying to solve and how the feature I will be adding fits into that context.
If nobody is available or willing to pair with me to do that, I would go to whoever I have to be accountable to to delivery the feature and make sure that they understand that it may take me longer to get my bearings and actually start down the path to completing the work.
Liutauras Vilda wrote:Do you use any IDE?
If the project is big, one of the mostly used feature of mine is, "search in the path (project)" for text occurences.
In case of Eclipse, there is a plugin "STS Quick Search" (Cmd+Shift+L) In case of IntelliJ IDEA it is built in (Cmd+Shift+F [mac], windows similar) NetBeans must have something similar too
So you could research the area by the likely keywords. i.e. If you need to add functionality to delete person contacts, look for the places where the functionality for adding contacts exists, search: "addContact", "contact", "person", etc...
Once you find some occurences you need to be able to read the code and understand how it is implemented and how it works. Unit tests can be a good resource understanding the code usage, so definitely look up for these. And of course write yourself.
Where to put the code sometimes can be a hard call. Need to think well, where such functionality might belong to, whose responsibility it supposed to be. Starting to write unit tests can help find reasoning for yourself whether the code you are about to write makes sense to put in place X or no.
Prasad Saya wrote:- Know the people who work in that project.
- Know well the people or person who you will be working with.
- Verify that what you are understanding (about the new feature) is correct.
- Know what is expected and when.
- Know what the practices (or procedures, tools. etc.) are in that project.
- Find the project resources or repository or wiki (generally there is one).
In general, good and honest communication helps a lot (don't hesitate to ask relevant questions); its been my experience and I have spent my years working with existing projects and teams and its almost always worked to get one integrated.
Junilu Lacar wrote:starting out with tests is a great approach. However, start by reading existing tests related to the functionality that you're going to develop. If there are none, try to understand the part of the code that you'll be touching or interfacing with. Then write tests to verify your understanding. These are called characterization tests. When you have a sufficient degree of confidence that you understand what's going on in the current code, write a small unit test (singular, key word is "small") to hypothesize about what you think your new code should do. Then implement the small (again the key word) bit of production code to make your test pass. Then read and retread your code and refactor it to eliminate duplication and clarify intent. Repeat this process as many times as needed until there is no new small test you can think of to write to define new functionality.
Junilu Lacar wrote:I would tell your manager that pushing someone into the deep water to teach them to swim is not a good metaphor when it comes to developing software. I would say it's really more like everyone is already in the pool, then you push the guy who doesn't know how to swim in and he soils himself. Now everyone is swimming in dirty water and everyone is going to have to stop swimming, get out, and clean up the pool.
A better approach is to have a strong swimmer go with the new guy and teach him how to swim. As the new guy learns more, he can venture into deeper water. When the new guy is comfortable enough to go it alone, the strong swimmer can go back to doing his laps, while the new guy builds up his confidence and ability. It won't be long before the new guy will be swimming laps with the rest of the team, too.
Junilu Lacar wrote:There aren't many schools that teach the techniques I mentioned. Companies spend lots of money to bring in coaches to teach professional developers these techniques. That's my day job. This here is just fun because we get responses like yours. Some pros don't respond half as well.