7 rules of writing programs that will not die with you

Your programs are your legacy. Decide for yourself how long it will exist.

Life ends, but programs don't have to die.

After a series of my tweets on how to write programs, I was asked to reveal this topic. I warn you that rarely in which project can you clearly follow all seven rules. I myself often do not get it. But the more rules you follow, the more your programs will survive. Each symbol adds something to a common ecosystem, and our task, as engineers, is to keep the ecosystem clean and tidy.
')
What can I get by giving a good code? Doesn't the right to live a learning approach called “move faster, breaking everything in your path?” No. Learning to write code is a skill, it is accessible to everyone. Learning to write good code is an art. It takes effort, time and dedication.

Do you want to leave even more SEGFAULTs after the death of the world? Do you want to have a sysadmin repairing systems that are broken because of your crappy code? So that your project manager will remember you as an engineer who has infuriated users?

There is nothing wrong with fast forwarding, but at some point you need to realize that low-quality code will not take you far.

When you come to the doctor, he first asks you many questions in order to understand what happened to you. He does not prescribe medication before making a diagnosis. Likewise, it’s important to find out if something is wrong with your code.

1. Nakat updates takes a lot of time and effort?
2. Is the system crashing even from a small update?
3. Have you ever rolled out a broken code for production, and this became known only after user complaints?
4. Do you know what to do when the system crashes? How to get to backups and recover from them?
5. Do you spend more time changing environments, re-running the same commands, running some utilities - than writing programs?

If you answered "yes" - this article is for you. Read, but better read twice.

1. Divide into modules

The human brain is a complex device, more complex than any processor , and it does not cope with the solution of complex problems. Suppose it is difficult to immediately multiply 13 * 35. But if we divide these operations into simple ones: 35 * 10 + 30 * 3 + 5 * 3 = 455, then the calculation is simplified. Breaking down the problem into simple and independent, we come to the answer.

The same with programs. Split the program into several parts, files, directories. projects. Print all dependencies in one place, use the MVC principle or its variant. This code is easier to read and easier to debug. In most cases, debugging will lead you to several lines of code, and not to a file of a thousand lines. Rolling updates of one module, you will not break the rest of the system.

2. Test

Fu, tests. Brrrrrr!

Such a reaction is natural because we have been taught that tests are not part of the programming. You are taught patterns in C ++, but not how to test them. That is the problem. Some believe that the tests are over writing up to the program itself.

I don't care when you write tests, if you write them. No need to be a hero, start with a simple one (print (add (1, 1) == 2)), and then go to the test framework in your language.

Then you will begin to understand the complexity of your program, learn to divide it into modules, parts that can be tested separately. It turns out that using tests, you will already perform two of the seven rules.

3. Continuous integration

Tests should successfully work, and in different environments (for example, in different versions of Python). Also tests should be carried out after each change. Instead of doing it manually from the command line, it is more convenient and faster to create a platform for continuous integration.

Continuous Integration (NI) is a development practice in which code integrates into the repository several times a day. Each time it is checked automatically, allowing you to track problems at an early stage.

For my projects I use TravisCI and Drone.io . When I make a new addition to the code, the platform does the build and executes the tests.

4. Automate

Large projects always have a lot of small auxiliary tasks. Some people make tekstoviki with teams and copy them from there. But it's easier to learn bash (and / or Python) scripts . Here are some tasks that need to be automated with scripts:

- conversion of README.md to other formats
- automated testing (including creating test servers and data, deleting temporary files, etc.)
- upload code to the development server
- program placement on production
- automatic update dependencies

5. Redundancy

The first thing you see on git-scm.com:

Git is a free, open source distributed version control system designed to work with both small and very large projects with high speed and efficiency.

Distributed This is the key word. Pinch yourself if you are hosted only on a githaba. Because it is a single point of failure. If the githab crashes, or during a push operation you damaged files, your development process stops.

Login to Bitbucket and do the following in your repository:

# rename origin remote git remote rename origin github # add the gitlab remote (for the love of everything that's holy, use ssh) git remote add bitbucket <remote link for bitbucket> # push existing code to new remote git push -u bitbucket —all # let's magic git config -e # add this in the file [remote “origin”] url = git@github.com:username/reponame.git url = <remote link for bitbucket> 

Now, when you upload code, the changes go both to Github and Bitbucket. You never know when something breaks. And it is always useful to have backups. Here's how it works for me:

- all code lives in the Codebase directory in Dropbox. Automatic sync.
- almost all code lives on Github
- the most important code lives on two private mirrors - one at school, the other on my AWS

I will lose my code only if the end of the world comes.

6 commits

This should be familiar to you. Take a look at the story and you will see something like:

"Fixed a bug in the module"

SERIOUSLY?!?!

Corrected? What mistake? Which module?

Many people regard the version control system as a backup, and not as a way to keep history. The history of such messages is useless. Suppose a week after this commit you decided to bring something back, because it introduced a new bug to the project. But since there is no description of the action, you need to review all the changes. To prevent this, version control systems were created.

So as not to strain, just use the following key:

- each commit should have a point. Bug fix, add new feature, delete existing one?
- only one change per commit
- include the problem number in the commit message
- include a description of the changes. It depends on the rules of the current project, but usually you mention what caused the error, how you fixed it and how to test it.
- write a meaningful message:

Added a new form in the header to make it easier to collect links. shut down # 3

instead

deleted everything, for why not, heh

7. Plan

Even if you follow all the previous rules and feel like a programming god, anything can happen anyway. Have a plan for the worst case. What if traffic breaks records? Where do you get backups if the system crashes? Who to call at night, if the server does?

Think over, but do not overdo it. Automate everything that is possible. Then document everything in detail. So that whoever receives your code can also follow the plan. Having a plan does not only mean looking smarter, it really means being smarter.



These are the rules and determine a good program. If they are not convinced, answer me two questions:

1. Do you expect from a newcomer to join you that he will understand the existing code with ease?
2. Is code refactoring simple and quick?

If not, reread again. Save, share with the team.

These rules may seem obvious at first. And there is. Bad code is constantly being created, and in the end, it dies. Your programs are your legacy. Decide for yourself how long it will exist.

Happy programming.