How Do You Work With Other People's Code?

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.

Key Takeaways

• Understanding other people’s code is a fundamental skill for developers. To facilitate this process, developers should interact with lead developers and other team members, observe and familiarize themselves with the codebase, run tests, and fix bugs designed for newcomers.
• Developers should make use of available resources, including mailing list archives, project documentation, and version control history. A good IDE can also be beneficial in understanding and working with other people’s code.
• Learning from others through books, blogs, and other resources can help developers avoid common mistakes and enhance their skills. Contributing to documentation can also be a valuable learning experience.
• It’s essential to be considerate when working with other people’s code. Understanding that different developers may have different approaches and skill levels can foster a more respectful and productive working environment.

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

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.

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

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?

Frequently Asked Questions (FAQs) about Working with Other People’s Code

What are some strategies for understanding someone else’s code?

Understanding someone else’s code can be a daunting task, especially if the code is complex or poorly documented. However, there are several strategies you can use to make the process easier. First, try to get a high-level understanding of the code by reading any available documentation or comments. Next, break the code down into smaller, manageable sections and try to understand each section individually. Using a debugger can also be helpful, as it allows you to step through the code and see how it behaves. Finally, don’t hesitate to ask the original author or other team members for help if you’re stuck.

What is pair programming and how can it help in understanding code?

Pair programming is a technique where two programmers work together at one workstation. One, the driver, writes the code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently. This approach promotes better understanding of the code, as both programmers can discuss and clarify any doubts or issues in real time. It also helps in catching errors early, as the observer can spot mistakes that the driver might have missed.

How can I organize code to make it easier for others to understand?

Organizing code in a clear and logical manner can greatly help others in understanding it. Some strategies for organizing code include grouping related functions together, using meaningful names for variables and functions, and providing comments to explain complex sections of code. It’s also important to follow established coding conventions and standards, as they provide a consistent structure that makes the code easier to read and understand.

What is the role of a code reviewer in a programming team?

A code reviewer is responsible for reviewing the code written by other team members to ensure it meets the team’s quality standards. This includes checking for errors, ensuring the code follows established coding conventions, and verifying that it achieves its intended functionality. The code reviewer also provides feedback to the original author, which can help them improve their coding skills.

How can I improve my skills in working with other people’s code?

Working with other people’s code is a skill that can be improved with practice. Start by reading and understanding code written by others, and try to identify the techniques and strategies they used. Participate in code reviews and pair programming sessions, as these provide opportunities to learn from others and gain different perspectives. Additionally, studying coding standards and best practices can also help improve your skills.

What tools can assist me in understanding and working with other people’s code?

There are several tools that can assist you in understanding and working with other people’s code. Integrated Development Environments (IDEs) often have features that can help you navigate through code and understand its structure. Debuggers allow you to step through code and see how it behaves. Code review tools can help you identify issues and provide feedback. Additionally, documentation tools can help you understand the purpose and functionality of the code.

How can I handle poorly documented code?

Dealing with poorly documented code can be challenging, but there are strategies you can use. Start by trying to understand the code’s overall structure and functionality. Use a debugger to step through the code and see how it behaves. If possible, ask the original author or other team members for clarification. As you gain understanding, consider adding your own comments or documentation to help future developers.

How can I contribute to a codebase without disrupting the existing code?

When contributing to a codebase, it’s important to respect the existing code and coding conventions. Start by understanding the codebase and its structure. Make sure your changes align with the existing code and don’t disrupt its functionality. Test your changes thoroughly to ensure they don’t introduce new bugs. Finally, communicate with your team and participate in code reviews to ensure your changes are understood and accepted.

What is the importance of coding standards in a team?

Coding standards are important in a team as they ensure consistency and readability across the codebase. They define how code should be written and organized, which makes it easier for team members to understand and work with each other’s code. Coding standards also help in maintaining the quality of the code, as they often include guidelines for error handling, security, and performance.

How can I effectively communicate with my team about code?

Effective communication is key when working with a team on a codebase. Be clear and concise when discussing code, and use appropriate technical terminology. Participate in code reviews and provide constructive feedback. If you’re having trouble understanding a piece of code, don’t hesitate to ask for clarification. Also, be open to receiving feedback and use it to improve your coding skills.

The above is the detailed content of How Do You Work With Other People's Code?. For more information, please follow other related articles on the PHP Chinese website!