Boring Techniques
This document is intended to help you write safe, dull, simple, boring, pedestrian code. These qualities are valuable because programming is hard, and debugging is harder, and debugging distributed systems is harder still; but by writing all our code with a determinedly po-faced and dyspeptic cynicism, and by tightly proscribing the interactions between components, we can at least limit the insanity we have to deal with at any one time.
There are valid exceptions to many of these maxims, but they are rare and you should not violate them without a bone-deep understanding of why they exist and what their purpose is. (Before tearing down a fence, know why it was put up.)
-
Programming 101
β SOLID is not just for objects
β Code is written for humans to read
β Concurrency is Hard
β Align Responsibilities And Capabilities
β Do Not Call Up That Which You Cannot Put Down
β Donβt Trust Anyone, Least Of All Yourself
β Config Structs are Awesome -
https://discourse.jujucharms.com/t/juju-specific-heuristics/2739
β https://discourse.jujucharms.com/t/user-operations-must-be-simple-and-valid/2740
β https://discourse.jujucharms.com/t/agent-operations-must-be-resilient/2741/2
β https://discourse.jujucharms.com/t/time-now-is-the-winter-of-our-discontent/2742
β https://discourse.jujucharms.com/t/worker-worker-is-a-sweet-ass-abstraction/2743
β https://discourse.jujucharms.com/t/use-dependency-engine-and-catacomb-catacomb/2744/2
β https://discourse.jujucharms.com/t/use-watchers-but-know-what-youre-doing/2745 -
https://discourse.jujucharms.com/t/feature-specific-heuristics/2746
β https://discourse.jujucharms.com/t/know-what-you-are-modelling/2747
β https://discourse.jujucharms.com/t/yagni-but-some-things-you-actually-will/2748
β https://discourse.jujucharms.com/t/model-self-consistent-concepts/2749
β https://discourse.jujucharms.com/t/internal-facades-map-to-roles/2750
β https://discourse.jujucharms.com/t/external-facades-are-more-like-microservices/2751
β https://discourse.jujucharms.com/t/all-facades-are-attack-vectors/2752
β https://discourse.jujucharms.com/t/all-facades-should-accept-bulk-arguments/2753
β https://discourse.jujucharms.com/t/cli-commands-must-not-be-half-assed/2754
https://discourse.jujucharms.com/t/how-to-write-and-apply-a-bug-fix-for-juju/2755
When fixing a bug that affects more than a single branch the prefered
process for fixing the bug is to perform the work against the oldest
branch (back porting) and then apply that patch up to each release branch
and finally in to master.
Sections
- How to backport
- Patching 3rd Party Libraries
https://discourse.jujucharms.com/t/code-review-checklists/2733
This document contains checklists to use when reviewing changes to Juju core. They have been synthesised from various documents written over Jujuβs history as well as issues that have been raised on actual reviews. These checklists donβt cover every possible thing that a reviewer should be thinking of when looking at a proposed change. The focus is on the biggest wins that can be practically included in a checklist.
https://discourse.jujucharms.com/t/continuous-integration-testing/2756
Juju has many Continuous Integration (CI) tests that run whenever new code is checked in. These are long-running integration tests that do actual deploys to clouds, to ensure that juju works in real-world environments.