5 ms·

Having had to do the occasional "start with an empty file" kind of rewrite/refactor, both in hobby projects and at work, I just take the "copy/paste" approach.

Having had to do the occasional "start with an empty file" kind of rewrite/refactor, both in hobby projects and at work, I just take the "copy/paste" approach. Start with the structure of what you really want it to be and then flesh it out. Soon discover that a lot of the existing code is OK, anywhere from a simple "for" loop to an entire module, because they work just as well in the new structure and don't have significant technical debt on their own. These can be pasted into the rewrite and possibly adjusted lightly. There's rarely need for a truly clean sheet.

spiffyk 2y ago
Wholeheartedly agree with this! When I was working on Knot Resolver, I did a pretty successful rewrite of its I/O. The original one was a mess, but of course a lot of it did make sense in the grand scheme of things - it's only that the requirements had changed with time (mostly caused by the addition of DNS-over-TLS, DNS-over-HTTPS, and, in the future, DNS-over-QUIC), so various adaptations needed to be made to the original code. But, as the changes were largely incremental, it resulted in something that was pretty hard to reason about. So I literally tore out the thing that I considered the most "wrong" about it, but sort of kept it at the side; then I started reimplementing it by mixing new code better suited for the current (and hopefully near future) requirements with the old copy-pasted code. Spinning a bit off-topic, but perhaps sort of relevant to anyone planning to do something like this. The biggest gratification for that effort did not come immediately. Rather, the result was initially pretty underwhelming. Yes, the code seemed to be more readable, robust, and extensible, but since there was no immediate need to touch that area for some time, I started questioning whether it was actually worth it. But then, about a year and a half later, some new requirements arised, which proved that the effort was actually worthwhile. And we even had a direct comparison, because a security fix was needed for both the old, still-supported, version, and the new one, so it was nice to see the difference between what it took to fix the old one and the new one.

spiffyk 2y ago

Wholeheartedly agree with this! When I was working on Knot Resolver, I did a pretty successful rewrite of its I/O. The original one was a mess, but of course a lot of it did make sense in the grand scheme of things - it's only that the requirements had changed with time (mostly caused by the addition of DNS-over-TLS, DNS-over-HTTPS, and, in the future, DNS-over-QUIC), so various adaptations needed to be made to the original code. But, as the changes were largely incremental, it resulted in something that was pretty hard to reason about. So I literally tore out the thing that I considered the most "wrong" about it, but sort of kept it at the side; then I started reimplementing it by mixing new code better suited for the current (and hopefully near future) requirements with the old copy-pasted code. Spinning a bit off-topic, but perhaps sort of relevant to anyone planning to do something like this. The biggest gratification for that effort did not come immediately. Rather, the result was initially pretty underwhelming. Yes, the code seemed to be more readable, robust, and extensible, but since there was no immediate need to touch that area for some time, I started questioning whether it was actually worth it. But then, about a year and a half later, some new requirements arised, which proved that the effort was actually worthwhile. And we even had a direct comparison, because a security fix was needed for both the old, still-supported, version, and the new one, so it was nice to see the difference between what it took to fix the old one and the new one.