logoalt Hacker News

globular-toasttoday at 6:40 AM1 replyview on HN

But they should emerge right when they are needed, not some time later via a painful refactor.

I think every dev lives in fear of the situation where abstraction hasn't been done when it really should have. Maybe some junior dev came in after you and shoehorned in a bunch of features to your "simple" solution. Now you have to live with that but, guess what, there's no time to refactor it, in fact the business just wants even more features.

As usual these rules work best if everyone on the team understands them in the same way. If you work with people who can only see what is right in front of them (ie. the current feature), then it'll never work. You can always fit "one more feature" into the perfect codebase without thinking about the abstractions.


Replies

silisilitoday at 6:48 AM

In a perfect world, sure. In my personal experience, refactoring to introduce an abstraction is far less painful than refactoring to remove or fix one.

Usually because intent is far clearer in the former case.