1.7 KiB
1.7 KiB
How is the c4k-project section?
Status
accepted
Context
We need some place to collect common used code for our Convention4Kubernetes modules.
Discussion about project-section in general
- Value
- Smaller modules make it easier to cope with systems complexity
- test code seperately
- fewer people work on the same repo -> less merging
- Increase consistency by reusing code instead of creating redundancy
- enforces clearer architectur (decisions)
- separation of code along the different development velocities border.
- enforces architectural section
- Smaller modules make it easier to cope with systems complexity
- Cost
- increase of systems complexity
- Dependency Hell / transitive dependencies
- Section requires good documentation
- more artifacts
- Worse Developer Experience
- Refactoring across multiple modules is hard to handle
- Debugging of seperate modules my be time-consuming (multiple layers)
- some coding tools (e.g. jump to definition) do not work over multiple repositories
- slower development roundtrip (e.g. when using repl)
- less awarness of what co-workes are commiting/working on
- Danger of naive projcet section
- increase of systems complexity
Decision
- We move common used code (predicates for spec, config handling with aero, gopass resolution, yaml serialization and encoding) to c4k-common project.
- For cli & web frontend code we accept redundancy till we've a clearer picture on how to extract commons
- For postgres deployments we accept redundancy till we've a clearer picture on how to extract commons
Consequences
- We can use described code in common.
- After more experience we will decide about a changed section.