Coupling: Difference between revisions
From ym2149.org
Jump to navigationJump to search
No edit summary |
No edit summary |
||
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
* manufactured concern to protect developers who are afraid of refactoring and would rather maintain a pile of hacks | * manufactured concern to protect developers (or appease managers) who are afraid of refactoring and would rather maintain a pile of hacks | ||
** seems particularly prevalent in the web ecosystem but also leaking outside of it | ** seems particularly prevalent in the web ecosystem but also leaking outside of it | ||
* so-called coupling is actually a good thing, as everything can automatically benefit from improvements in the shared code | |||
** we do not need to predict the future if it's easy to make changes to the codebase, which should be the case anyway | |||
* when shared code does not support your use case, change it so that it does | * when shared code does not support your use case, change it so that it does | ||
** unit tests should be in place to ensure existing use cases remain supported | ** unit tests should be in place to ensure existing use cases remain supported | ||
Latest revision as of 08:43, 13 October 2024
- manufactured concern to protect developers (or appease managers) who are afraid of refactoring and would rather maintain a pile of hacks
- seems particularly prevalent in the web ecosystem but also leaking outside of it
- so-called coupling is actually a good thing, as everything can automatically benefit from improvements in the shared code
- we do not need to predict the future if it's easy to make changes to the codebase, which should be the case anyway
- when shared code does not support your use case, change it so that it does
- unit tests should be in place to ensure existing use cases remain supported
- tangled conditional logic, as ever, can be avoided via polymorphism
- there is always the option of inlining shared code that isn't fit for purpose
