Re:The Second Edition of “Refactoring”
by btilly on Saturday December 01, 2018 @04:27PM
(#18579049)
Which way you really want a refactor to go can depend on the presence of the type system. As well the reliability of refactoring doesn't.
For example consider the thing you constantly see in Java where you construct an object then assign each property through a method. The type system will catch it if the property is not passed correctly.
In a dynamic language like JavaScript the same is better done with an inline object. The reason being that the type system won't catch it if there is a mistake, and so you want to go for the easiest way to write it. On the theory that less code is less maintenance.
However now it is hard to rename a property and be sure that your refactor is correct. Because where does a property come from? It could come from anywhere - over the network, from an API call, the name of a database field - it is easy to miss it.
Which means that not only should the refactor go in a different direction, but how safe you feel in doing refactors will also go in a different direction!
For example consider the thing you constantly see in Java where you construct an object then assign each property through a method. The type system will catch it if the property is not passed correctly.
In a dynamic language like JavaScript the same is better done with an inline object. The reason being that the type system won't catch it if there is a mistake, and so you want to go for the easiest way to write it. On the theory that less code is less maintenance.
However now it is hard to rename a property and be sure that your refactor is correct. Because where does a property come from? It could come from anywhere - over the network, from an API call, the name of a database field - it is easy to miss it.
Which means that not only should the refactor go in a different direction, but how safe you feel in doing refactors will also go in a different direction!