How to deliver software: Difference between revisions
From ym2149.org
Jump to navigationJump to search
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
== Guidance == | == Guidance == | ||
* https:// | * https://wiki.c2.com/?PrincipleOfLeastAstonishment | ||
* https://wiki.c2.com/?KeepItSimpleStupid | |||
* https://en.wikipedia.org/wiki/Don%27t_repeat_yourself | * https://en.wikipedia.org/wiki/Don%27t_repeat_yourself | ||
* https://github.com/romenrg/evergreen-skills-developers | |||
== Process == | == Process == | ||
Revision as of 21:18, 20 March 2024
Guidance
- https://wiki.c2.com/?PrincipleOfLeastAstonishment
- https://wiki.c2.com/?KeepItSimpleStupid
- https://en.wikipedia.org/wiki/Don%27t_repeat_yourself
- https://github.com/romenrg/evergreen-skills-developers
Process
- split work feature by feature, not layer by layer
- squash merge makes the history less useful for investigations or revert
- in particular, a story may result in a refactor commit followed by a feature commit. combining those throws away a ton of information and may make refactoring less attractive to developers. they should not be in separate pull requests as refactoring needs context or may be negative work, and benefits from a free round of testing
- merge your own pull requests, own that responsibility
- keep your own tickets up to date. in particular, only the assignee knows when it can really be moved to done e.g. experimental cloud resources may need to be tidied up
