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 |
||
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 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 | |||
* 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]] |
Revision as of 11:55, 12 October 2024
- manufactured concern to protect developers 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
- 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