What do you do when you're suddenly thrown onto a large project? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

开发者_运维百科

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 3 years ago.

Improve this question

I recently started a career in software development after graduating a couple of years ago in CS. The current project I'm on is a large ongoing project that has it's origins in the 90s with a mix of C, C++, and Java. There are multiple platforms (UNIX, WIN, etc) being supported, older technologies in use like CVS, and some dated documentation in some areas.

The extent of my software development skills stem from going to university as I've had little real world experience. I felt like I had a decent foundation in CS but I cannot but help feel slightly overwhelmed by it all. I'm excited to be part of something so huge but at the same time I feel like it's a lot of information to absorb.

My coworkers have been great people and answer a lot of questions I. My employer hired me knowing that I am entry level.

I've tried poking around the source code and examining how everything gets built but it's on a scale I've never seen before.

How do more experienced people situate themselves when joining a large ongoing project? What are some common tasks you do when getting yourself up to speed?

---

Good question. I haven't had your exact experience, but in cases like this I like to think, "how do you eat a whale?" The answer is (predictably) "one bite at a time." Reasonable people won't expect you to grasp the whole thing immediately, but they will want to see progress. Perhaps there are some small areas of the larger project that are not too complex, without too many dependencies. Work toward understanding one of those and you're one 'bite' (and/or 'byte') closer to expertise on the whole project.

---

Being familiar with all existing documentation I would try to get the big picture. Literally.

• generate a TreeMap of the source code

I would use GrandPerspective on Mac or WinDirStat on Windows. It will give you some insights about the structure of the project's files (sometimes it gives some hints about the code structure). Having this, you can ask your colleagues for some of the clusters, what they do, how they relate to each other.

• learn how to build the project

This is important to have it compiling all the time if you are about to do any changes. Having tests executed at the build time is always a good thing, so ask for it also. Even better if there is some kind of continuous integration server in place. If there is, look at its configuration - figure out how the build is done. If there was no CI server, but you already got the knowledge how to build the project, create such a server on your local machine, and show it to your fellows - they should fell in love with it.

• browse the source code with Structure101 or similar tool

This is useful especially for Java projects. This tool does great job. That will give you more details about the code structure, and sometimes about the system architecture. This experience may be sometimes hard, you may learn from this tool that a code is basically a Big Ball of Mud ;)

• look for tests, and explore them

If you will be lucky there may be some JUnit, or CPPUnit tests. This is always good to try to understand what those tests are doing. It may be a good starting point to explore the code further.

---

My coworkers have been great people and answer a lot of questions I. My employer hired me knowing that I am entry level.

You have little to worry about, you're employer knows what you are capable of and your co-workers seem eager to help you out - to be honest most developers love explaining things to others...

From what I've seen, it take truly 6+ years to become fully knowledgeable in a language, so don't expect to become a guru within a year... and even these so called gurus end up learning something new about their language everyday.

Learning a new system (large) will always take time.... the systems were usually not built in 2 weeks but over many years, so don't expect to understand it fully yet. You'll eventually discover what each part does piece by piece.

I know how you feel, because I felt like that once...

---

"I took a speed reading course and read 'War and Peace' in twenty minutes. It involves Russia." (Woody Allen)

I agree on what the others said before me. You need some tools that give you an overview on the code. I personally used inFusion (http://www.intooitus.com/inFusion) because it gives also other interesting data beside structure.

---

The method that has worked best for me is to grab a copy from source control, with the intention of throwing this version away...

Then try and refactor the code. It is even better if you can refactor the code that you know you will be working on at a later stage.

The reason this is effective is because:

• refactoring gives you a goal for you to aim towards. Whereas "playing" an "breaking" the code is great - it is unfocused.
• To refactor code you really have to understand the code.
• Refactored code leaves code that has less concepts to retain in memory. If you don't understand a large codebase its not because you are a graduate - its because nobody can retain more than 7 (give or take a few) concepts at a time.
• If you follow correct refactoring guidelines it means you will be writing tests. Although, make sure that you will be working on the modules that you are testing as writing tests can be very time consumning (although very rewarding)

Do invest in buying this book at some point:

http://www.amazon.co.uk/Refactoring-Improving-Design-Existing-Technology/dp/0201485672

But these links should get you started:

Signs that your code needs refactoring and what refacoring to use (From Refactoring - Martin Fowler) http://industriallogic.com/papers/smellstorefactorings.pdf

A taxonomy of code smells: http://www.soberit.hut.fi/mmantyla/BadCodeSmellsTaxonomy.htm

Good luck!!!

---

I agree to the first comment but I also Think that you have to learn and see the big picture in some way. You have to trace the main flow from code at least.

---

I was in the exact same situation several years ago when I joined a software project with 50+ ClearCase version control vobs, 5 million lines of code, and some of it dating back to the 1980's.

The first thing I did was look through every source controlled directory and made a quick summary of my best guess about what the software in that folder did and what language the code was. You can make a pretty good guess by looking at filenames and any comments or documents in those folders.

I then looked at the build scripts to see if they were readable enough to get an idea of dependencies between different parts of the code.

Finally - and I believe this was the most valuable - throw an IDE like Eclipse or NetBeans on top of the code and start reading through pieces of it. Having the ability to jump to the definition of any functions or classes using the IDE allows you to move around a massive software baseline with relative ease.

Overall, have some confidence - it is unlikely that anyone else on the project knows all of the code, so you don't need to either. Use what other people said to get a good idea of the overall project and interfaces and requirements (if they exist) and poke through the code to get an idea of the most commonly used classes and methods.