Web
Article

How Do You Work With Other People’s Code?

By Matthew Setter

Dealing with code created by other people is a fundamental skill for a developer. Give it a year and other people’s code could even be your own.

Today I’m going to look at some of the best approaches for how to deal with other people’s code, read legacy code, effectively. It’s not an easy topic to cover.

To make the process easier, I’m framing my approach through the following areas:

  • Interact
  • Observe
  • Run Tests
  • Fix Bugs designed for Newcomers
  • Find Available Resources
  • Use a Good IDE
  • Read Books & Blogs
  • Contribute to Documentation
  • Be Considerate

Let’s get started.

Interact

Who are the lead developers? Where are they? Are they available directly in your office? If so, go have a talk with them or email them. These people should be the best sources of knowledge about a project.

Are you a remote worker or freelancer? What communication channels does the project or company have? Are developers on IRC, Slack, Twitter, email, Trello or something else?

Make sure you are where they are. A criticism often leveled at Zend Framework 2 is that there’s no active community. That’s not the case, as the IRC channel is active on a daily basis. So make sure you are where the developers and other team members are.

Observe

When you first start on a project, take it easy on yourself. Don’t expect to know everything right from the start. The estimates vary, but I’ve heard of three weeks to three months of daily work with codebases before a developer can truly be considered productive with that codebase.

Some people have the misguided perception that you can, somehow, just jump in and instantly be productive. Perhaps they’ve watched too many Hollywood movies like Swordfish.

Codebases take time to learn as they’re invested with the ideas, preconceptions, beliefs and approaches of all the developers who worked on the project. Given that you’re new, you won’t have any of the background knowledge.

Here are 5 good ways to get started:

  • Take time to step through everything
  • Ask questions
  • Setup a test installation
  • Attempt to use the test installation
  • Read through the code comments and related documentation

Don’t be hard on yourself, give yourself a chance to make a good start. After a while, you’ll start to have a better understanding of how the application has been put together.

At this point, start to move faster by asking questions of other developers and senior developers. You would have built a list of questions as you went through the codebase.

Take time out to ask the other developers for answers to your questions and queries. Don’t be shy, jump in and get the answers and input you need.

Run Tests

running-phpunit

Any good codebase should have tests. If it doesn’t, that’s not a good sign. It needn’t be insidious — it could just be a developer or development team who’d never implemented testing — but I’d be more than a little concerned if there were none.

If there are tests, run them. Do they pass? I’ve come across more than one source codebase which has a suite of tests which no one seemed able to actually run. Have they been kept up to date?

Now you’ve tried running them, have a good read through them. If they’re well written, they should describe how the application works, what it’s expected to do, and how different components hang together. Make sure you take the time to do this, as it can be quite insightful.

Fix Bugs Designed for Newcomers

Another easy way to start out is fixing the bugs targeted at newcomers, or more junior developers, on the project. Two good examples are Joind.In and ownCloud, the bug tracker for the latter you can see in the screenshot below.

owncloud

You can see these tickets have been clearly marked. Have a read-through and get involved. These bugs won’t be highly technical, but you’ll be able to ease in to the project, building your confidence and knowledge.

While glory and technical complexity can be great for the ego, when things don’t work or take too long, they don’t do any favors for your pride and enthusiasm. Start small and ease your way in.

Find Available Resources

One of the best things you can do when taking over a codebase, or when coming into an existing team, is to gather as many resources together as you can. Not sure of what to look for? Here’s some ideas to get you started:

  • Do you have access to the mailing list archives?
  • Is there a project or company wiki?
  • What project documentation has been compiled?
  • Have you read through the version control history?
  • Have the contributors written meaningful commit messages, consistently?

Use a Good IDE

phpstorm-syntax-highlighting

Good IDEs are worth their proverbial weight in gold. Whether you’re a Ruby, Python, Go, Java, PHP or other language developer, find a good IDE either specifically dedicated to or suitably customizable for your language of choice.

I appreciate some people are purists, preferring VIM or Emacs, and that’s OK. But I’m an IDE lover and my IDE of choice is PhpStorm. There are plenty of others, such as Eclipse, TextMate, SublimeText, and VisualStudio.

Once you’ve found the IDE for you, start making use of the features it offers. I’ll make reference to PhpStorm specifically here, but apply these principles to your IDE of choice.

Start stepping through the code and see if it complies with a standard. This needn’t be a formal standard, such as the PHP PSRs. But have the developers followed a consistent style, or is it all over the place. Use tools such as a mess detector and cyclomatic complexity tester to start to gauge the quality of the code.

Is there any code documentation? If so, your IDE should be able to make use of it as you inspect the code. Next, use a step-through debugger, such as xhprof, Xdebug or Zend Debugger, and run the application, seeing how it works.

What does it do? What data structures does it create and make use of? Does it repeat code blocks unnecessarily? There’s far more than I can cover here, but use the features your IDE provides as you go through the code to make your life easier.

Read and Learn

This one’s a stand-out for me personally. The more we learn, the more we can grow and — as a result — do. We’re not the first to have tread the path we’re on. Many, many, others have come before us and made plenty of the same mistakes we’re likely to make.

Save yourself a bit of time and do some justice to their hard learned experiences by learning from them. So many of the better developers are also authors and bloggers.

One of my personal favorites is Martin Fowler, who also happens to have published a great book on the topic of refactoring. There are also other excellent books, such as Design Patterns, and websites such as SourceMaking.com.

Do yourself a favor and continue to invest in resources such as these. It’s not always easy, but it can be tremendously rewarding.

Contribute to Documentation

This is one which I don’t do enough of. It’s easy to be an armchair critic, sitting on the sidelines and criticizing a codebase, framework or other kind of software project. Instead of doing that, get in and get involved.

Documentation isn’t for failed programmers, designers or non-technical people. Some of the largest projects actively suggest that the best place to start is documentation.

One of the most prominent projects which does this is the Linux Kernel. What better way to learn something than to document it? After all, if you truly know it, only then can you document it.

So if it’s an open source project, get in, find out about it, read through the code, make notes as you go along, then contribute to the documentation. If it’s an internal application, be the first to start documenting; even if for no one else but yourself.

Perhaps there’s no documentation to speak of; a truly horrid place to be. But every project has to start somewhere. As you work through the source code, write down what you know.

Some of the best developers I know, for example the lovely Lorna Jane, started blogging this way. She blogged to keep a record of what she was learning, which later turned in to one of the most popular PHP blogs around.

Be Considerate

The last point: Be considerate to the developers whose work you’re reviewing and building on. You don’t know where they were in their career and education, or what restrictions they had on them, when they wrote the code you’re now coming up to speed on.

What’s more, at what skill level are you at? It can be easy for us, when we’re younger, newer, and less experienced, to be judgmental of others.

We think we know it all and that our expectations, concepts and approaches are the true and correct ways to go. But is that really the case? I like to believe that, as we mature, and grow a bit older, we also grow wiser and become more accepting of the wide array of approaches to software development which exist.

We may not need to agree with them, but they’re not necessarily wrong. They may have a lot to teach us, which can help us grow. So always try and be considerate of other people and the position they were in. Don’t be the obnoxious newcomer, pointing fingers and laying blame. After all, that helps no one, especially you.

Wrapping Up

There’s loads more that you can do to make working with other people’s code a more manageable process. What methods, tips, tricks and tools do you use?

Free Guide:

7 Habits of Successful CTOs

"What makes a great CTO?" Engineering skills? Business savvy? An innate tendency to channel a mythical creature (ahem, unicorn)? All of the above? Discover the top traits of the most successful CTOs in this free guide.

  • Jani Hartikainen

    Great stuff. Something I think is good is being “a good citizen”.

    Everyone knows that devs can be very picky about things like tabs vs spaces, line-endings, stylistic issues like how many spaces to put before braces in if-clauses and things like that..

    So you would want to try to emulate the existing styles for things like that as much as possible.

    It may seem trivial, but this goes to show that you’re paying attention to details, and that you are willing to put a little bit of effort to your work. Others who have to review your code will appreciate the efforts, and it means they don’t have to tell you to fix these things – afterall, nobody really likes nitpicking on minor things.

    • mike

      Tl; dr: follow the coding convention.

    • http://www.matthewsetter.com/ Matthew Setter

      Definitely agree. Speaking as an often picky dev myself, the little things really do make the difference a lot of the time. And respecting those that you both currently work with and those who will come later is a great piece of advice. Thanks for sharing Jani.

  • http://cneude-createur-web.com Matthieu

    To be considerate is really important if you want to work in a good atmosphere. Try to understand development choices event they seem stupid for you. It’s like that I learn and think outside the box. If you don’t try that, you can’t even explain why, for you, it’s bad ideas…

    Staying humble and a good interlocutor is one of a key to learn from other developers.

    • http://www.matthewsetter.com/ Matthew Setter

      I especially like your last point about staying humble. Any time I became hubristic, where I thought I “knew better” always lead me in to trouble. When I tried to understand and appreciate what the original developers were thinking, were going through or constraints that they had upon them, usually, always ended up with a better end result.

  • http://www.technostall.com/ Chankey Pathak

    Nicely put, did the similar in my first job, was able to pick up the codebase in 1-2 months for a 10 years’ old project. Glad that you put the reading part, companies often tend to miss that part in “Induction plan”.

    • http://www.matthewsetter.com/ Matthew Setter

      I find a lot of companies seem to expect you to be some kind of savant or genius. It takes time to pick up existing work, as you mentioned, 1 – 2 months. But this investment is worth it over the course of time as the code is maintained and extended.

  • kwasiboab

    This can be applied to any king of third party code you are new to.Try to see the wider picture of the code and how the various parts are interconnected. From the beginning one should not be interested in how the various methods and algorithm work you might get scared. Get to know how the application flow before zooming in on various components.

    Asking questions is the key. That peace of code you’ve been trying to understand for the past weeks could have taken the other developer 5 minute to explain to you.

    • http://www.matthewsetter.com/ Matthew Setter

      Well said on asking questions. Sitting for hours beating your head against a wall, getting nowhere, doesn’t help anyone, least of all yourself. Great advice.

  • Garison Piatt

    “Three weeks to three months”? I’m generally productive by the end of the first week. Most of the maintenance work I’ve done has been after the original coders are long gone. There is no one to talk to, no one to ask for advice, and often no documentation. Being alone on most projects has taught me to figure out what’s going on quickly.

    The main thing I keep in mind is that no matter how good or bad my predecessors were, all similar projects are written in a similar manner. If a program needs database access, there is most likely a database module. That module has methods to create and edit database records. Once I find it, I’m up to speed on it. If there is a menu, then there is code to display that menu and react to it. Each button has code to display the button, and respond to clicks. Every input has code to read it; every output has code to send it.

    Everything that the product reads, modifies, updates, or displays has some kind of code behind it. If I know how to implement that code on my own (which I do, in most cases), then I know how the previous coder did it. Whether that code is better or worse than my own is subjective, and not really germane to anything. What’s important is that, when I know how the feature operates, I also know how the code works. My task at that point is simply to find it and fix or improve it.

    • http://www.matthewsetter.com/ Matthew Setter

      Garison, thanks for sharing. Depending on the size and complexity of the codebase 3 weeks to 3 months I feel is fair. What I’m meaning is solid proficiency, a really thorough working knowledge.

      My experience mirrors yours. People seem to generally follow standard conventions, and implement the same approaches to common problems.

      The trouble I run into is not the underlying concepts, but the specifics of how the developers implemented their solutions.

      If someone is logical and methodical in their approach, consistent in their variable naming, consistent in applying a coding standard, even if the standard is rubbish, it’s much simpler to work with than developers who are all over the place.

      Thanks for sharing your experience.

  • Gena Turkot

    Thank you Matthew for great work.
    I think, a man who does tackle a codebase need try
    to understand the developer’s character, style, culture,
    even developer’s personality.. :)

Recommended
Sponsors
Because We Like You
Free Ebooks!

Grab SitePoint's top 10 web dev and design ebooks, completely free!

Get the latest in Front-end, once a week, for free.