News for hackers. Stuff that matters.

A comment on Refactoring vs. defactoring. Parent comment

Re:Refactoring vs. defactoring by splittingTimes on Wednesday October 27, 2021 @06:53PM (#29020039)
Great point. We use method/class names in config files that get parsed and dynamically evaluated. You could break the whole application by changing class names as an init config could fail.

Also persisting stuff in customer DBs that depends on class names (and reflection) is nice source of terror. Shipping a new version of your software with a refactored class names corrupts the whole DB of a customer.

[ Parent | on HN ]
Re:Refactoring vs. defactoring by Zababa on Wednesday October 27, 2021 @07:02PM (#29020102)
> Also persisting stuff in customer DBs that depends on class names (and reflection) is nice source of terror.

We do that but with XML files, most of our tables are dynamically generated. I'm a bit scared every time I touch this part.

[ Parent | on HN ]
Re:Refactoring vs. defactoring by splittingTimes on Wednesday October 27, 2021 @07:08PM (#29020170)
We have a whole framework that handles migrations of costumer DBs after updates. But when you don't even know that your changed class gets persistent (because of spaghetti inheritance/type hierarchy) and you do not enter it in the migration scripts, you duck up.
[ Parent | on HN ]