Any tips for coming up to speed on a new (to me) project?

[Chaotic42]

I'm not a Software Engineer, but I do some development and have inherited an existing project which is related to what I do. I generally write Python/C/SQL which is either used internally or informally shared with other groups - they aren't delivered products, they are used to automate various tasks to improve and/or produce delivered data.

Anyway, the person who was heading this up left before I came on board and I have been tasked with getting up to speed on it and taking ownership. Everyone knows it's not ideal, but it needs to be done and for various reasons it only really makes sense for me to take it up. Unfortunately I know very little about the software or the source code and need to come up to speed on it quickly.

I've been reading through it, having been given various tasks to perform and improvements to make. I'm trying to track down how the code works, writing up text showing which function calls what, trying to see how it's all pieced together.

Unfortunately it's not in a Visual Studio project or anything, so I'm using fairly mundane text editors to do all of this. I'm really missing the Visual Studio autocomplete and function definition tracking and whatnot. I know this is all very general, but does anyone have any tips for coming up to speed on an unfamiliar project? How do you like to read code? Do you build diagrams in Visio? Write up wiki pages? I'd appreciate any advice you all care to give.

 

[Cogman]

What language is the project written in? If it is a popular language at all, you might be able to use intellij with it ( https://www.jetbrains.com/idea/ ). That has all the auto complete stuff you crave (and usually works pretty good).

Has nobody dealt with the code before? Ideally, you would have SOMEONE walk you through what it does. If not, you need to at very least be communicating with management "Hey, I've never seen or touched this code before, it is going to be months before I can do major work on it".

Usually, for me, understanding code is just something I know will take time. Some things that help me personally.

• Have small tasks you want to complete. It can be really helpful just having a task to complete. Pick some bug cases if they exist and work on them. But I would try very hard to make sure it is a small issue (I know, hard to judge, but things like "this should say X instead of Y" are usually easy).
• If you can, walk through the code from start to finish. Find the entry point and an exit point, and just traverse through the method calls. This is much easier with an IDE, but still doable with just a plain ole text editor. Is this an interpreted language? (Python, ruby, javascript?) Then you might find spinning up a REPL against the code to be useful.
• I personally wouldn't waste my time writing out wiki pages. Though I know it helps some to learn writing SOMETHING. So I would just get a notepad out and start writing down what I'm learning. It doesn't have to be structured or even reviewed, just the act of writing can help you to grasp things.
• You might try asking and answering specific questions if small bug cases aren't available. For example "How is this widget made" or "Where does this hook up to the DB?". Then from there, look into the usages and track through the cobwebs of code to figure out exactly what this thing is doing.
• Is this using a framework (Ruby on rails?, Jetty? Jersey? nodejs?) If yes, and you aren't familiar with it, GET FAMILIAR WITH IT. Reading the docs/helps/tutorials/etc on whatever platform or framework you are working with will help you not only to understand what it is doing, but also to figure out if it is doing things "wrong" (not in a way that the framework wants you to do things). Too few devs read the docs on the tools they use.

Hope this helps, and good luck. Seriously, if this is a complex/large project then I wouldn't expect to be productive in a month or even 3. If your management expects that you will be then you really need to push back on them and let them know what's up.

 

[MagnusTheBrewer]

• I personally wouldn't waste my time writingout wiki pages. Though I know it helps some to learn writing SOMETHING. So I would just get a notepad out and start writing down what I'm learning. It doesn't have to be structured or even reviewed, just the act of writingcan help you to grasp things.

This is what I was going to say but, got beaten to it. Great advice.

 

[Chaotic42]

Unfortunately there isn't anyone really familiar with it. We've got a Software Engineer who is working on it while I get up to speed - he doesn't know very much about it, but he's more familiar with general Software Engineering principles and the standards of the group and the previous developer.

The code is C++ and Java. I'd say I'm solid with C++, having written a few programs including one with OpenGL. I'd feel better about C, I just need to get used to the parts of C++ they've been using that I haven't messed with. It's been a while since I used Java.

I want to document everything not just for myself, but if I get hit by a bus, I want whoever gets the hot potato to be able to start up quickly. The bosses understand what's being asked as does our customer, so at least I have that going for me.

Thanks for the quick responses.

 

[urvile]

With out knowing anything about the architecture......I generally will create UML sequence diagrams that I either create in Jira or Visio to get an understanding of the way the application fits together. By following the function/method calls. Sometimes I will start at the UI with use cases. Depending on how much I want to abstract it. Problem with that though is once you make changes. You then have to update the documentation. You will also need an easy way to navigate the code.

On some jobs we would hand the software over to the client and then it was up to them to maintain it. In those cases we would use an OOAD approach and hand the design over as a deliverable. Sequence diagrams are particularly useful.....

Other times you just have to dive in. When I have worked as a contractor the employer is expecting you to be immediately productive. You can but try......