DEV Community

loading...

Discussion on: Don't Use The Date Object

Collapse
webbureaucrat profile image
webbureaucrat

I'm not crazy about this solution. You wrote a whole wrapper class and a fake for that wrapper class, all of which you have to maintain, when you could just

// pseudocode
function isTimeToSendEmail(now: Date): bool
{
    return now.ToFormattedString() === "Wednesday 8:00";
}
Enter fullscreen mode Exit fullscreen mode

This solution takes on less technical debt and is also functionally pure and referentially transparent. You know that every time the function is called for a given date object, it will always return the same result, which helps A LOT with debugging.

(Not that there aren't any valid reasons for writing a date wrapper--I've written them before for different reasons.)

Collapse
josepheames profile image
Joe Eames Author

Very good. Great alternative solution. Ultimately my solution and your solution are very similar. Two ways to accomplish the same goal.

On a different point, "this solution takes on technical debt". I see no evidence of either solution containing any "technical debt". Cutting a corner is technical debt. Debt is something that usually needs to be paid back. These techniques (like what you showed here) are about improving the quality of code, which if it has any effect on technical debt, is a reduction.

Collapse
webbureaucrat profile image
webbureaucrat

Good point. I was really unclear in my earlier comment. Perhaps "technical debt" isn't exactly the right phrase. When I said "technical debt", I was referring to the additional maintenance cost of the wrapper and the fake(s) and the cost of the additional developer time it takes to understand the codebase fully. Maybe it's not exactly "technical debt" like a hacky workaround that you know you'll have to eventually "pay back" by fully undoing. More like a technical utility bill or a technical property tax--a long term cost that is a lot smaller than a loan but that you don't ever really get rid of.