Is it wealth or a trap? How to handle someone else's code

Disclaimer: The majority of this article is translated from the How does work with the other people ' s codematthew Setter. The translation process may be slightly different from the original text, please specify the source of the reprint.

We often encounter similar problems in our work. into a project team, take over other people's projects, start full of energy, but the others do something to see, momentary dumbfounded, do not know where to start, and finally began to complain about the project before the style and their own current differences, and how to resolve this kind of embarrassment, is the topic of this article content.

Dealing with someone else's code is a basic skill for a developer. In just a year, someone else's code will work for you.

Now, I'm looking for some of the most effective ways to deal with other people's code, and how to read the remaining code effectively. It's not an easy thing to know.

In order to make the narrative process easier, I will divide my experience into the following ways:

• Interaction
• Observation
• Test
• Error correction system designed for newcomers
• Finding viable resources
• Using the Good IDE
• Reading and Blogging
• Writing documents
• Empathy

Interaction

Who is the boss of your developer? Where are they? Can you find them directly in your office? If OK, be bold to communicate with them or email them. Be aware that they are the best source of project-related knowledge.

Are you telecommuting or freelance? What do the developers of this project or company use to communicate with, IRC, slack,twitter,email, or other tools they use?

Make sure you are consistent with the project. A frequent criticism of the Zend Framework 2 project is that there is no active community. This is not the case if you are able to use IRC channel more daily. So make sure you're consistent with the developers and other team members.

Observation

When you start a project, don't be too nervous. Don't expect to know all the right things from the start. General project time estimates will vary, but I have heard that it takes 3 weeks to 3 months before the code can actually be produced to understand the code base.

Some people will feel misled and think that whatever you do, you will be able to sustain the output as long as you are involved in it. People who have this idea may have seen too many Hollywood movies, such as "Swordfish."

A code base is a crystallization of thought, a collection of ideas, beliefs, and ways of doing the developers who create it. It takes time to understand and learn, for the code base, you are still a newcomer, need to have a background knowledge of precipitation.

Here are 5 great ways to get started:

• Take the time to step through all the code.
• Good at asking questions
• Configuring the test mechanism
• Try to use the test mechanism
• Read through code comments and documents

Don't embarrass yourself, good beginning is half the success, do the preparatory work of the beginning. After that, you'll start to get a better idea of how those apps will be combined.

With this in mind, you can move faster by consulting other developers and advanced developers. Before you do this, you need to make a list of issues by using a general understanding of the codebase.

Spend time with other developers to figure out your problem. Don't be shy, ask questions and get the answers you need.

Test

Any good code base is tested. If not, that's not a good sign. There is no need to hide it, it may just be that the developer or the development team has never implemented a test. And my concern is if it's really not tested.

If there are tests, don't say more, run them. Can you pass? I've encountered this situation more than once, the database has a complete set of tests but no one can really run it. So there's one more question, are they always kept up to date?

Now you have tried to run it and have a good understanding of it. If this is a good test, you should already know how those applications work, what results they want to achieve, and how different components hang together. It makes sense to make sure that you take the time to do these things.

Error correction system designed for newcomers

Another easy way to get started is to fix bugs as a novice or beginner developer of the project. There are two typical examples of joind.in and owncloud, which you can see in the following two bug trackers.

You can see the labels clearly. Read them and participate, although these bugs are not particularly high tech, but you can easily apply to the project, set up your self-confidence and knowledge system.

While complex techniques and honors can satisfy your ego, these will only be a stumbling block to your pride and enthusiasm when they are not used or when you have done only a small thing. So don't above his business, do things in the simplest way,

Finding viable resources
When you take over a code base or join an old team, the best thing you can do is to collect as many resources as possible and not know how to find them. Here are some ideas to consider:
Do you have access to the mailing list file?
Does the project or company have its own wiki?
What are the project documents that have been compiled?
Have you read through version control history?
Do those contributors continue to update meaningful operational information?

Using the Good IDE

The gold content of a good IDE is well known. No, No. You are a developer of Ruby, Python, Go, java,php, or other languages, and you need to find a good IDE that fits your language features.

I appreciate that some people are purists, preferring vim or Emacs, which is excellent. But I am a fan of the IDE, my choice is phpstorm. There are, of course, many other Ides, such as Eclipse, TextMate, Sublimetext, and VisualStudio.

Once you have chosen your IDE, you need to start to understand and use the features it provides. I will take my preference phpstorm as an example, but you can apply these principles to the IDE of your choice.

Start typing the code to see if it meets the criteria. It doesn't need to be a formal standard like PHP PSRs. But you need to know whether developers follow a consistent style, not their own. Learn to use mess detector and cyclomatic complexity testers to measure the quality of your code.

Are there any code documents? If so, the IDE should be able to use it when you check your code. Next, use a single-paced program, such as the Xhprof,xdebug or Zend debugger, to run the application and see how it works.

What did it do? What is the data structure it creates and uses? Does it have unnecessary duplicate code modules? The real understanding is much more than what I'm listing here, but using the functionality provided by the IDE to complete the code will make your programmer's life easier.

Reading and Learning

That's just my personal idea. The more we learn, the more we grow. We are not the first to eat crabs, before we have a lot of people have committed a lot of the same mistakes.

Give yourself some time to judge some of the former people's experiences and learn from them and draw lessons from them. Be aware that many good developers are also part-time editors and bloggers.

What I admire most is Martin Fowler, who writes a great book about refactoring. There are other excellent books, such as Design Patterns and related website sourcemaking.com.

Do yourself a favor and then continue investing with these resources. It's not an easy thing to do, but it's really good.

Writing documents

And that's where I'm not doing enough. It's easy to be a critic, sit on the sidelines and judge a code base or framework for good or bad, or other types of software projects. Don't be a critic, you need to get involved.

Documentation is not prepared for a failed programmer, designer, or non-technician. Some super-large projects will actively suggest that the document is the best start for the project.

One of the biggest projects starting with a document is the Linux Kernel. What better way to learn than to record documents? After all, only you can record it, you can really know it.

So, if it's an open source project, get involved, read through the code, take notes, and then edit the document. If this is an internal application, the first thing to do is to record the document, even for you alone.

Perhaps the scariest thing is that there is absolutely no documentation to use, but every project has to start somewhere. When you work with the source code, write down what you know.

As far as I know, some of the best developers, such as the lovely Lorna Jane, are starting to use blogs. He recorded what she had learned in his blog, and then her blog became one of the most famous PHP blogs.

Empathy

The last point: be considerate of the work of the developers you are reviewing and building. You don't know about their careers and education, or the limitations that they face when they write code that you're working faster.

What's more, what skill level do you have in people? That may be easy for us, and when we are young and inexperienced, we will be judged by someone who does not have much experience.

We believe that our friends are omniscient and that our expectations, concepts and methods are correct. But is that really the case? I would rather believe that when we become mature, we will be wiser and become more receptive to the existence of a broad approach to software development.

We may not need to agree with them, but they are not necessarily wrong. They can also teach us a lot and help us grow. So try to be considerate of others and stand in their shoes to think about it. Don't be an annoying newcomer, just blame and blame. After all, it doesn't have any eggs.

Personal experience:

I was in a game company to do data analysis, although and the code is not too big on the side, but also deep experience in this area of distress.
Because I want to do data analysis, it is unavoidable to call the data from the database, often need to compare the recent today's data with the previous data to do comparative analysis. That's when the problem arises, and when I start to do it, I often can't find the data, and I ask if the colleague of this group has not recorded the data or deleted it before, but he says it is recorded and does not erase important data. Then I looked at a sheet of data to find that the class name of the previous data table is completely different from the present one, and even some of the same data has 3 distinct class names. There are also no rules for the naming of active data tables, which adds a lot of weight to my work.
So sometimes your methods and nomenclature are more scientific, but as far as possible with the previous work to be consistent, not only convenient for yourself will also bring great convenience to Yimeimei. If you really stick to your style, leave the documentation at least, and be responsible not only for your own work, but for others as well.

There are a lot of open source projects and code, there is a better development environment, but slowly you will find that the use of other people's open source projects or code is not just a shortcut, more a learning and self-improvement process.
My current company is such a company, I believe many successful companies are the same, standing on the shoulders of giants to respect it.

Is it wealth or a trap? How to handle someone else's code