2014-06-13 17:31:10 +08:00
|
|
|
# libcontainer Principles
|
2014-06-12 22:29:02 +08:00
|
|
|
|
|
|
|
|
In the design and development of libcontainer we try to follow these principles:
|
|
|
|
|
|
|
|
|
|
(Work in progress)
|
|
|
|
|
|
|
|
|
|
* Don't try to replace every tool. Instead, be an ingredient to improve them.
|
|
|
|
|
* Less code is better.
|
2014-06-13 17:31:10 +08:00
|
|
|
* Fewer components are better. Do you really need to add one more class?
|
2014-06-12 22:29:02 +08:00
|
|
|
* 50 lines of straightforward, readable code is better than 10 lines of magic that nobody can understand.
|
2015-02-04 09:44:58 +08:00
|
|
|
* Don't do later what you can do now. "//TODO: refactor" is not acceptable in new code.
|
2014-06-13 17:31:10 +08:00
|
|
|
* When hesitating between two options, choose the one that is easier to reverse.
|
|
|
|
|
* "No" is temporary; "Yes" is forever. If you're not sure about a new feature, say no. You can change your mind later.
|
2014-06-12 22:29:02 +08:00
|
|
|
* Containers must be portable to the greatest possible number of machines. Be suspicious of any change which makes machines less interchangeable.
|
2014-06-13 17:31:10 +08:00
|
|
|
* The fewer moving parts in a container, the better.
|
2014-06-12 22:29:02 +08:00
|
|
|
* Don't merge it unless you document it.
|
|
|
|
|
* Don't document it unless you can keep it up-to-date.
|
|
|
|
|
* Don't merge it unless you test it!
|
|
|
|
|
* Everyone's problem is slightly different. Focus on the part that is the same for everyone, and solve that.
|
