Coupling: Difference between revisions
From ym2149.org
Jump to navigationJump to search
(Created page with "* manufactured concern to protect developers who are afraid of refactoring and would rather maintain a pile of hacks * 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 * there is always the option of inlining shared code that isn't fit for purpose Category:Programming") |
No edit summary |
||
| (2 intermediate revisions 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 | |||
* 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 | ||
** 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 | * there is always the option of inlining shared code that isn't fit for purpose | ||
[[Category:Programming]] | [[Category:Programming]] | ||
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
