4 ms·
while I agree with you, your description of refactoring scares me. It makes me imagine an over-engineered hot mess. I had a conversation with a junior enginee
by celticmusic 7y ago
while I agree with you, your description of refactoring scares me. It makes me imagine an over-engineered hot mess. I had a conversation with a junior engineer just today about valuing simplicity and avoiding abstractions until you're sure you really need them.
because cleanliness isn't really the goal, the goal is meeting business needs, stability, and discoverability. Often times abstractions create complexity, and that complexity hurts discoverability, it potentially hurts stability, and it can often times be detrimental if business needs change.
So I say abstract when it's clear that you need to, not before.
That's not to say I disagree with the sentiment to get the code working and then go back over it with an eye for cleaning it up, I just dislike the sentiment that this cleanup should be for abstracting things.
- agentultra 7y agoI realize I said, Abstract away superfluous variables with function application which is not the kind of over-engineered mess you're warning us about. I'm referring to lambda abstraction, that is replacing an expression with a name and closing over the free variables in it with the parameters to the function. The reason for this is that assignment is a common source of errors in imperative programs. We should aim to use as few of them as possible, define them local to their use, and limit their scope. I'm only talking about small, local refactors that make the code yo wrote easier to understand and maintain. Refactoring code to introduce new patterns or re-architect a module are better done earlier in the process and much more deliberately, I agree.
- celticmusic 7y agoNo one thinks their overengineered mess is an overengineered mess, that's kind of the point.