|
|
|
|
|
by lwhi
895 days ago
|
|
I find the decision is usually a cost vs. benefit exercise. Separating out business logic by making code more generic _is_ basic good practice. There doesn't need to be a high cost once you start to do this by default, and it leaves doors open for future changes. My general feeling is to 'leave doors open' (or allow for flexibility) if the cost of doing so is minimal. Simple / dumb / readable is something you can achieve no matter which route you take. Comment your code. Be more verbose if it helps legibility and necessary performance won't be impacted. Fundamentally, the only certain thing is that change _will_ be required at some point. And unfortunately, the decision as to whether something will be needed in the future is rarely something a developer has a say in. All you can do it make your future dev life easier by leaving doors open, not closed. |
|