|
|
|
|
|
by Terr_
3391 days ago
|
|
My motto is "Design for deletion." Your first priority is to design your code for the inevitable day when your successor (or perhaps you yourself) dislikes it. The less effort/risk to uncouple and remove it, the better. This helps avoid the well-meaning pitfall where you design things to be "customizable in the future", but the ways it needs to be customized aren't well known, and it turns out you've only complexity that gets in the way of the changes you eventually want. In contrast, any code that's easy to remove implies that there's a good boundary, interface, or contract. |
|