4 ms·
I totally agree! The problem is that sometimes you just can't convince your coworkers. They'll say this XYZ feature is coming sooner or later, they'll argue tha
by hackernewsguy 13y ago
I totally agree! The problem is that sometimes you just can't convince your coworkers. They'll say this XYZ feature is coming sooner or later, they'll argue that abstraction means cleanness. And as future is so uncertain, arguing about what might happen in the future always ends up with no conclusion, and they still think their future-proof approach is worth it.
- vidarh 13y agoBut the true future proof approach is to not add the code, but write the code you do write in a way that makes it easy to support the expected changes anyway. E.g. for the pet example: Avoid hard-coding the class name all over the place, so that if you do end up having to add a Pet superclass and add Cat's in the future, you don't need to make changes more than one or two places. Writing loosely coupled and reusable code is good practice anyway, and also makes testing easier, but if you practice YAGNI it becomes extra essential: You know your code almost certainly will need to change in the future, so you should structure your code accordingly to make extension and refactoring easy.