Seeing code or working with other people’s code is a fundamental developer skill. Take the time to learn about that code and make it your own
Today we will look at some best practices for working with other people’s code, legacy code reader (legacy) effectively. This is not a subject easy to write complete
To make the process more receptive, focus should be on the following key items:
● Interaction
● Observability
● Run Test
● Fix Bugs Designed For Newbies
● Search for available resources
● Use a good IDE
● Read Related Books & Blogs
● Supplement and contribute materials
● Be careful
Interaction
Who are the lead developers? Where are they? Are they physically present in your office? If so, talk to them or email them. These guys definitely have the best knowledge of the project.
Are you a remote worker or freelancer? Does the company or project have communication channels? Developers using IRC, Slack, Twitter, email, Trello or something else?
Make sure you are in the same place as them. One criticism often directed at Zend Framework 2 is the lack of an active community. Not really, because their IRC channel is active every day. Make sure you are co-located with the developers and other team members.
Observability
When you first start a project, don’t be too hard on yourself. Don’t expect to know everything from the start. I’ve heard of how it takes three weeks to three months of daily work with the codebase (the underlying code is already there) before a developer can really work with that codebase.
Some people have the misconception that you can, somehow, just jump in and be instantly productive. Perhaps that is not true.
Codebases take time to learn because they are built from the ideas, prejudices, beliefs, and approaches of all the developers working on the project. Since you are new, you will not have any background knowledge.
Here are five great ways to get started:
Take the time to skim through everything
Make a question
Test install
Try using the one you just installed
Read through the comments in the code and related documents
Don’t be hard on yourself, give yourself a chance to get off to a good start. After a while, you’ll start to get a better understanding of how apps are built.
At this stage, move faster by asking other developers and senior developers. You’ve got a list of questions as you go through the codebase. See also the route to becoming a senior developer.
Take the time to ask other developers for explanations for your problems. Don’t be shy, take action and get the answers you need.
RunTest
Any good codebase has tests. If not, that’s not really cool. It’s actually possible that these developer teams have never done testing, but I would be a bit concerned if they didn’t.
If there is a test, run it. Is there a pass? I have come across many codebases that have a set of tests that no one can run through. Have they been updated?
After you’ve tried running them, read on. If they are well written, they describe how the application works, what it does, and how the components stick together. It will take time to dive into these.
Fix Bugs designed for newbies
An easy way to get started is to find out why bugs appear and fix bugs for newbies or junior developers in the project. Two good examples are Joind.In and ownCloud, pictured below is ownCloud’s bug tracker:
You can see clearly marked tickets. Please read through and participate in fixing them. These bugs are not very technical, but you will be able to easily immerse yourself in the project, building confidence and knowledge.
Complex achievements and techniques are great, but if they’re not immediately available or will take a long time, they won’t help your confidence and enthusiasm. Let’s start with the easy and the small.
Find available resources
One of the best things you can do when taking over a codebase, or when joining an existing team, is to gather as many resources as you can. Don’t know what to look for? Here are some ideas to get you started:
Do you have access to the mail archive?
Does the project or company have a wiki?
Have you read the version control history?
Have you read the version control history?
Do contributors write meaningful and consistent commit messages?
Use a good IDE
A good IDE is as precious as gold. Whether you are a Ruby, Python, Go, Java, PHP or another developer, find a good IDE specifically or customized for the language of your choice.
I appreciate purists, prefer VIM or Emacs, that’s OK. But I am an IDE lover and my IDE of choice is PhpStorm. There are many other options, such as Eclipse, TextMate, SublimeText, and VisualStudio.
Once you’ve found your IDE, start using the features it offers. Here I give an example for PhpStorm, you can apply these principles to the IDE of your choice.
Start going through the code and see if it conforms to a standard. Not necessarily an official standard like PHP PSRs. See if the developer follows a consistent or messy style. Use tools like mess detector and cyclomatic complexity tester to assess code quality.
Is there any documentation available? If so, your IDE should be able to use them when you test the code. Next, use a debugger, such as xhprof, Xdebug or Zend Debugger, and run the application to see how it works.
What does it do? What data structures does it create and use? Does it repeat blocks of code unnecessarily? There’s a lot more to consider, but using the features the IDE provides will make it much easier to breathe.
Read books and learn
This is true for me personally. The more we learn, the more we grow and do things. We are not the first on the path we are on. Many, many others have gone before us and have made the same mistakes as us.
Save yourself a moment thinking about the difficult learning process of your predecessors and learn from them. Many good developers are also book authors and bloggers.
One of my favorite authors is Martin Fowler, who has published a great book on the subject of refactoring. There are also other books that are great, such as Design Patterns, and sites like SourceMaking.com.
Do your own research and keep learning from such resources. It’s not easy, but the rewards are well worth it.
Additional and Contribution Document
This is one of those things that I don’t do enough of. It’s easy to sit out and criticize a codebase, framework, or software project. Instead of doing that, start contributing.
The material is not for failed programmers, graphic designers, or non-technical people. The biggest software projects always suggest that the best place to start is the documentation.
One of the most prominent projects that do this is the Linux Kernel. What better way to learn something than to document? After all, if you really know something then you can document it..
So if it’s an open source project, jump in, learn about it, read through the code, document it, and then contribute documentation. If it’s an internal application, be the first to start documenting; even if there is no one else but you.
There may be no documentation; but that’s really terrible. Every project has to start somewhere. As you work with code, write down what you know.
The best developers I know, like Lorna Jane, for example, started blogging this way. She blogged to preserve what she learned, which later became one of the most popular PHP blogs.
Be careful
One last point: Think carefully of the developers you’re viewing and working on on their legacy. You don’t know about their careers and education, and how these things limit them, when they write the lines of code you’re reading.
Furthermore, what is your current skill level? It is arbitrary that we are younger, younger, and less experienced to judge others.
We think we know it all and that our expectations, concepts and approaches are the right and correct ways. But is that really the case? I believe that, as we mature and get a little older, we also become wiser and accept the multitude of software development approaches that once existed.
We may not have to agree with them, but they’re not necessarily wrong. They can have a lot to teach us that can help us grow. So always try and be considerate of others and their place. Don’t be an obnoxious newbie, pointing fingers and blaming. Behaving like this won’t help anyone, especially yourself.
Summary
There’s a lot of work to be done to make working with other people’s code easier. And you, what methods, tricks and tools did you use?
