How to deliver software: Difference between revisions
From ym2149.org
Jump to navigationJump to search
No edit summary |
No edit summary |
||
| Line 12: | Line 12: | ||
** enforce business behaviour with unit tests to support that refactoring | ** enforce business behaviour with unit tests to support that refactoring | ||
** yagni also applies to requirements, functionality that isn't really needed is a major source of tech debt, also see playing the [[security card]] | ** yagni also applies to requirements, functionality that isn't really needed is a major source of tech debt, also see playing the [[security card]] | ||
*** consider the impact of not doing a ticket | |||
** see [[Defect driven development]] for YAGNI taken to its logical conclusion | ** see [[Defect driven development]] for YAGNI taken to its logical conclusion | ||
* most of the [http://www.extremeprogramming.org/rules.html extreme programming rules] | * most of the [http://www.extremeprogramming.org/rules.html extreme programming rules] | ||
Latest revision as of 13:56, 19 April 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
- https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good or good enough
- https://en.wikipedia.org/wiki/Worse_is_better e.g. simply propagate errors
- swallowing errors is a major cause of dev tasks taking excessive time
- https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it (YAGNI)
- trust future developers to build on what you've done (with any necessary refactoring) instead of building a framework that guesses the requirements they'll be given
- enforce business behaviour with unit tests to support that refactoring
- yagni also applies to requirements, functionality that isn't really needed is a major source of tech debt, also see playing the security card
- consider the impact of not doing a ticket
- see Defect driven development for YAGNI taken to its logical conclusion
- most of the extreme programming rules
- key construction e.g. in Spring causes identifiers to be unsearchable which interferes with refactoring
- use something fit for purpose like aridity where such hacks aren't needed
- eat the frog, within reason
- not eating the frog risks development that may need to be partially undone
- whereas picking too hard an option is at risk of delaying delivery due to too many surprises
- you are never going to find a roman road between A and B so it's not a big deal, focus on deliverables of value even if they're not the ones originally planned
Process
- default branch should always be releasable
- any developer starting a feature branch can be confident of a stable base
- also merging a feature branch into the default branch does not build upon questionable code
- a ticket is done when the changes are in production
- split work feature by feature, not layer by layer
- descope tasks that can later be fixed forward
- 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
