Hacker News Reader

Comment by wvenable | Hacker News Reader

> Don't redesign the database schema at the same time you are rewriting.

Chances are, that's the problem though. You have to re-write because your design is bad enough that it's necessary. The only time you'd re-write without changing the design is when changing languages or platforms.

View on HN

You could do a rewrite that takes into account the bad old database schema, but doesn't repeat the wrong code design choices based on it.

Then, when that's ready and stable and working with the existing schema, it's way easier to do a refactor and adapt to the new schema too.

"Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious. " -- Fred Brooks, The Mythical Man-Month

Attempting a design re-write without changing the data structures will just result in the same design. And you can't change the data design without then having to change the code to match.

I've done several huge rewrites over my sordid career, and a strategy that works well is to abstract your bad data design behind a good one. This involves some kind of transformer layer between your bad data design spec and your abstracted better one. There's of course performance hits of some kind no matter what, but the hope is that they're worth the benefits of the cleaner code/architecture that the better data design spec affords. It's difficult I'll grant, much harder than abstracting simply bad code, but it's possible, and also makes it that much easier to replace the actual data design at some point in the future, and remove the transformer layer. Hope that makes sense!

I've done the transformation layer in the small to keep components running during a re-write/refactor. Create a new structure and write some code (in the DB or otherwise) to make the new structure look like the old structure long enough to eventually replace that old code.

I can't imagine doing that as an independent step towards a rewrite.

Something similar I've seen is a bad data design that is embedded into a giant monolith, and has dependency tendrils everywhere. In that case it's worthwhile to factor out the logic (which includes cutting the dependencies) even leaving the schema intact. Once the problem layer is sequestered e.g. into its own microservice it is hopefully possible to release it on its own cycle much faster than the monolith, paving the way to improving the schema next.

Exactly. If I'm not refactoring the underlying data structures....the refactoring isn't a very interesting/difficult one at all

That would kind of be the point.

>Attempting a design re-write without changing the data structures will just result in the same design. And you can't change the data design without then having to change the code to match.

Sure you can. You decouple your data structures from your schema with an abstraction layer, facade, etc.

Changing languages or platforms is a frequent cause for a rewrite. (Especially if the old one is Modperl 1.)

On the other hand, if you need to refactor the database schema, don't rewrite the code. Just do the minimum modifications to keep the app working.

Just don't do both at once.

Reply on news.ycombinator.com