Make your software live, depend on these 7 rules-programming software-IT information

Life fades, but does a good software.

If you want to write a "immortal" software, the key is whether you can follow the following rules:

1, modular

Rule 1: modular. Find a bug in a module in general than in the entire code base is much simpler.

The human brain is an extremely complex creatures, can design can handle the complex issues of CPU, but the ego itself is not the problem. Want proof? So tell me, without the use of any Calculator, pure mental condition, can you work out how much 13*35 is. I bet you can't. At least, you can't do that in a short time.

However, we specialize in complex problem into easier to solve problems.

13*10 is how much? 130.

13*5 it? That's 130/2=65.

130*3? 390.

390+65 is how much? 455. The answer is it!

This is one example of how decomposition: a large and complex problem into a small, independent of simple questions to quickly arrive at a correct answer.

We can follow the same logic to software. Modular code is easy to read, and easier to debug. In most cases, the stack trace will only lead to a very small subset of codes, rather than all of a sudden out of 1000 lines of code files. Even when a particular module is updated, without dauteng the entire system--as long as the part that is being updated.

2, test

Rule 2: any code that is not tested is a hooligan.

Many people think that testing and writing software are two different things, even in school, teachers will teach you how to use c ++ templates, but I won't tell you how to test. In Brainfuck online tutorial to teach you how to make Web servers, but does not explain how to test. And this is where the problem lies.

It is said that we should be writing the actual application logic before writing tests first.

But, in my opinion, doesn't matter when writing tests, as long as the writing is OK. Do not attempt to sweeping, stop trying to first write the perfect test: from a simple start. Brute force test (such as print (Add (1,1) =2)), and then test the corresponding language framework.

Testing helps us to understand the complexity of software. You can learn how to apply software modularity can be tested independently.

3, continuous integration

Rule 3: use of continuous integration. As long as there is a problem code, you will be informed.

You write tests, you must make sure that you can apply to a variety of environments (for example, multiple versions of Python). And, if any changes need to be made, and test.

Of course you can also manually operated command line, but with a continuous integration platform is more convenient, faster, and cheaper.

4, automation

Rule 4: Automation. Automation reduces steps to save time.

I see a lot of people are stored commands txt files so that when needed, you can copy and paste. I suggest that you may wish to learn bash scripting (and/or Python).

Here are some bash scripts that you have automated tasks:

README.md converted to other formats (depending on the different requirements of distribution channels)

Automated testing (including creating a simulated server and/or the data, delete the temporary files, and so on).

Phase code to the development server.

Deploying to production.

Automated updates depend on (especially when the update has the potential to undermine the existing API, and particularly to be careful).

5, redundancy

Rule 5: redundant versioning: do not only depend on Git, you can use multiple simultaneous remote remote control, increased redundancy.

The old saying goes, the egg cannot be put in the same basket. If your code is hosted on Github, if Github fails, your workflow will be affected.

To give you a reference, my code is stored:

All code in Dropbox "Codebase" folder. Automatic synchronization of changes.

In almost all of the code on Github.

The most important code, you also put in two more secret places.

You see, unless the end of the world, how else would my code will not be lost.

6, submit

Rule 6: submit: make a little change, and frequently submitted, not problems with your code.

Many programmers would version control system as a backup method, rather than a means of maintaining history. You know, like the historical information is useless unless you want to do is to retrieve the file.

Changes to information you have submitted a week later, as I found that introduced a new bug, so you need to restore the original content. But now, because the information you submit has already covered its original information, then you can gradually develop a how.

Version control system, precisely in order to prevent such a situation from occurring.

If you find it difficult to write good submitted, you can follow the template below:

Each submission should have a purpose. Determines whether to fix the bug, and adds a new function, or delete existing features?

Changes every time.

Submit information including order number.

Submitted changes should be indicated in the description. Depending on the project guidelines, often including what caused the bug, how to fix it, and how to test your changes.

Submissions should be written in clear and easy to understand.

7, plan

Rule 7: planning: preparing for the worst. If an error does occur should you do? These steps are detailed in the document.

Even according to the above rule 6 meticulous implementation, written software can not be perfect. If you've ever thought about it that way, it would have been na?ve.

Not afraid of 10,000, just in case.

Can develop a plan to prepare for the worst. If the website is too much to do? There is an unknown bug, leading to system crashes, where grilled pulled back up? Server downtime, even, who can find?

Take these circumstances into consideration. But don't worry too much. And automate as much as possible the steps can be automated.

Detailed in the document.

End

Remember, your software is your legacy. It can live as long as all depends on you. So, software is the ephemeral is immortal, it depends on how you do it.