Jimmy Song: How to become a Bitcoin core developer

This will make you not only a better developer, but also the backbone of the Bitcoin community.

This article is about 4,000 words, and it takes about 10 minutes to read the full text.

If you are a developer and hold Bitcoin, contributing to Bitcoin Core may be one of the best things you can do to help your investment. In this article, I will briefly describe how to contribute to core development.

• April Fool's Day Warning | Shocked! Bitcointalk to do KYC?
• Market Analysis | Bitcoin breaks through 4K USD, or is related to the Dow Jones index plunging
• BATJ giant blockchain layout new trends: the currency “bear market”, the chain “bull market”?

So you want to be a core developer…

Before we dive into the actual details of contributing to the core, please understand some of the considerations.

First, the Bitcoin core is an elite-managed group. As a rookie, you are unlikely to incorporate a frantic proof-of-work pull request into the core. Like any elite management, you start with zero reputation and speak at work.

The good news is that no one cares about your background. Whether you are a 14-year-old Indian or a 45-year-old CTO of a Fortune 500 company, the only thing that matters is the quality of your work.

The bad news is that you have to be willing to take up your own arrogance. No one cares how many years of experience you have, or if you have any good ideas to fix Bitcoin. The quality of your code, reviews, documentation, and tests is counted.

Second, you should set your expectations accordingly. Well-known core developers such as Pieter Wuille, Cory Fields and Gregory Maxwell have earned their respect through years of sweat and tears. Adding a pull request to correct a misspelling does not earn the respect of the Pieter Wuille level. Good work will earn you recognition and respect, but only after you have produced it for a while.

Third, this is not an easy path. Being a top developer at X doesn't necessarily make you a good core developer. There are many reasons for this, but in general, your work must meet some very high standards of testing, documentation, and code review, even in very reliable technology companies.

All in all, if you are humble, self-motivated, and committed to excellence, then contributing to the core will make you a better developer, code reviewer, documentary, and tester.

Prerequisite knowledge

You need some knowledge and skills to get started.

The Bitcoin core is mainly written in two languages, C++ and Python. If you want to contribute, you should have to learn at least one of them.

Source code control is managed through Git. At the very least, you should know how to get from the starting point, how to create a topic branch, and how to reset the base. If you are testing other people's code, you should also know how to add multiple repositories to your local development environment so that you can get and test your code.

All changes to the core are merged on Github based on pull requests, so you need a GitHub account.

Finally, you need to know how to install and remove packages on the platform. These instructions are very detailed, but they can be useful, for example, to help you add and remove ZMQ as needed.

Start

The first thing you should do at the beginning is to read the documentation. Readme files and contribution guides are a great place to start.

Then, go to the doc directory and read the README there. All documents in the doc directory are described in the README, so if you get lost or confused at any time, you can refer to it.

Please note that you do not have to know everything in each of the documents I recommend. If you come across something you don't understand, there are a lot of great people on IRC, StackExchange and Slack who can help you.

Build from the source

Now that you've read the basics of how development should work, you first need to build bitcoin from source. First, clone the Bitcoin Git repository:

Git clone [email protected]: bitcoin/bitcoin

The next step will be to set up your development environment. It depends a lot on the platform you're using, but compiling is something you need to do often, so it's worth it to put this part down.

In addition, you will need to run all integration tests, so be sure to open the GUI and ZMQ when you perform the instructions below.

· *nix instructions are here (https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md).

· osx instructions are here (https://github.com/bitcoin/bitcoin/blob/master/doc/build-osx.md).

· Windows instructions are here (https://github.com/bitcoin/bitcoin/blob/master/doc/build-windows.md).

· The openBSD description is here (https://github.com/bitcoin/bitcoin/blob/master/doc/build-openbsd.md).

When you set up your environment, if something doesn't work, please Google before submitting the document pull request. As mentioned earlier, IRC, StackExchange, and Slack are great resources, but please don't ask extremely simple questions and exhaust everyone's time.

test

Now that you have compiled everything, the next step is to test the software. Fortunately, the Bitcoin core has various unit tests and integration tests to check if the software you just compiled is working properly.

First, run the unit test located here. Unit tests are compiled with everything else, so all you need to do is run the generated binaries. Check that all tests pass. If they fail, they may have missed some instructions.

If all unit tests pass, run the integration test here. You are going to run the extension test. In particular, the pruning test takes a long time to run, so you want to exclude it when you run the integration test in the future.

Again, check if all tests pass. You will see a lot of points before the summary is finally displayed. If some areas don't pass, you may have missed some instructions, although sometimes some integration tests may become a bit variable due to RAM and CPU.

Contribution category

Now that you have set up the system, you can start contributing!

You might think that contributing means adding a bunch of code, sending pull requests and getting glory. In fact, a lot of work revolves around reviewing and testing code submitted by others. It helps to understand how to incorporate the steps involved in pulling a request.

1. Someone creates a change and submits the code via a pull request.

2. One or more people review the code.

3. One or more people test the code.

4. When there are enough people to review and test the code, the maintainer will merge the code – only a few people can do so.

Most people think that contributions to open source projects are only contributions, but in fact, testing and review are more important to the success of the project. As we saw in the recent Ethereum Parity failure, the lack of review and testing is often the cause of security breaches in many projects.

Review and testing are also critical, as it is often difficult to have a confrontational thinking model that covers all cases. There are many pairs of eyes to view and test the code to help discover possible ways in which the code can be utilized.

Finally, reviewing and testing are not only good for the project, they are also good for you! Reviewing and testing will force you to learn more about the code base and even better understand it than writing code.

Start

In order to adapt to the contribution process, you should not first add a large number of pull requests. On the contrary, as a new developer with no reputation, the best way is to start reviewing and testing the work of others. Reviewing and testing are often bottlenecks, so you can contribute and earn some reputation in the community.

It's worth mentioning that part of the reason Greg Maxwell enjoys such a good reputation among developers is that he is a very good reviewer and tester. When looking for possible ways to crack something, he has world-class talent, and he reviews and tests more code than he writes. I promise that you will be more grateful to you after your own code has been reviewed and tested.

Also, the code is usually written only once, but it has been read many times. Therefore, review is a very important step because it reveals the "readableness" of the code. The general rule of thumb is that for each pull request you submit, you should review about 3 pull requests. In the beginning you may want this review/submission request to be higher.

How to review

Often, you won't be able to properly review pull requests until you understand what the code is doing. As they say, writing in coding is much easier than reading, so take some time to really understand the code.

Often, in order to grasp what is happening in a pull request, you must look up the functions and methods being used and carefully examine the context of the code. If you are confused and the person you are reviewing is on the IRC, you may need to ask questions directly. Most of the time, the author of the pull request will be very grateful to the reviewer and will be happy to help you.

Just like reviewing an article or a book, you should pay attention to many things, namely:

· Is the code doing what it should do?

· Is the code fully tested?

· Are all comments around the code useful and accurate?

· Is the code clear and easy to modify in the future?

As a general rule, if you disagree with the implementation of something, it's best to assume that you don't understand the situation, not start the lesson. Empathy and wit will make you go a long way here. Remember, you review someone's baby in many ways. Question gently, at least at the beginning. Often, these programmers don't understand you or your intentions. Clearly distinguish between small problems in format and major issues that may damage something. It sounds like a student trying to master the improvement, not a janitor.

Once you've determined what the code is trying to achieve, then you can comment on whether this feature is worth doing. Before you build some reputation, stay away from any comments that might be considered negative.

After reviewing the code, please comment on the pull request using the appropriate peer review comments. If you want to negatively answer, please start over and assume that you don't understand what's going on, talk to the author and ask questions until you are sure this is a bad pull request. Even so, talk to more experienced people to make sure.

How to test

In order to test correctly, you must download the code from the pull request, compile and run the test again. It would be nice if you could think of a way to manually test this feature in some way, but it is not required.

In most cases, the pull request will include one or more tests. If the person writing the code does not provide test coverage, try to understand why – for obvious reasons, refactoring is usually not available. If you think you should test it, you can write "This requires testing" in the pull request. Even better, write your own test and let the author know where it can be picked from the pull request! This is a great way to build some goodwill with the author of the code you are reviewing.

Your job as a tester is to ensure that the test passes and that the test fully covers the functionality introduced. A good comment in the review may be "If a test like this can cover such a situation, that would be great."

After the test, be sure to indicate in the pull request that you have tested it.

Better pull request

In the end, you will be able to create your own pull request. The pull request can be anything from adding a document to a consensus key feature. No matter what happens, the key to making a good pull request is to make it easy to understand and not painful to review.

For this reason, please do not submit a 3000-line change pull request at one time to torture your reviewer. Divide these changes into easy-to-review submissions, with fewer than 300 lines (or possibly less than 100 lines!) and group them appropriately. For example, you should put a format change into one commit, change the actual encoding to another commit, and move the large movement of the code block into another commit.

In each submission, try to explain what you are doing and why you are doing it. How can this part be overemphasized? Every effort is made to make everything in the pull request easy to understand! If you don't do this, no one will review your code.

When a reviewer comments on something or suggests a change, try to understand why. If you don't understand, please ask until you know what they want you to do. If you agree, please make the appropriate changes and let your reviewers know, but if not, make sure you have a mature, witty conversation with them to find out how to get their confirmation.

Pull request concept at the beginning

Here are some pull request ideas that you can provide immediately (remember, please review 3 times of the pull request you submitted!)

· Make documents (especially about set documents) clear

· Write unit tests or integration tests for things that have not been tested

· Write comments in undocumented code for others to find

in conclusion

Software development practices used by the Bitcoin core are often not followed in other environments. Most people entering core development will find this process too restrictive and restrictive. I guarantee that every step has a reason.

Remember to be polite, gentle and euphemistic. Coming in a humble attitude and eager to learn, this will make you not only a better developer, but also the backbone of the Bitcoin community.

– END-

Jimmy Song

This article is compiled by the original letter of the coin, the original link:

Https://bitcointechtalk.com/a-gentle-introduction-to-bitcoin-core-development-fdc95eaee6b8

The copyright of this article belongs to the original author, only represents the author's own point of view, does not represent the viewpoint or position of the letter.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!