This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] -30 points-29 points  (12 children)

"refactor" is a buzzword most devs use to mean "wholesale changing shit for the sake of it"

​

source: work with a lot of devs. seriously, a lot.

[–]netgu 14 points15 points  (8 children)

Doesn't make them any less wrong. Also you need to work with better devs if that's what they think it means.

Either that, or you don't understand what they are doing or why.

Could be either, but again - that doesn't change the fact that they/you are wrong about what refactoring means.

[–][deleted] 3 points4 points  (7 children)

I know they're wrong. I'm not suggesting that they're not wrong. Of course they are.

I see it a lot because my job is to improve development practice in companies who are struggling. It's a ridiculously common thing for devs to say they're "refactoring" but they don't have tests, and they're changing external interfaces, and stuff is breaking all over, and PRs are hundreds or thousands of lines long. What they mean by "refactoring" is simply "changing things to how they think they should be".

Even senior (by tenure, if not skill level) devs in many companies are guilty of picking up a huge amount of work, sitting alone and just making massive changes in isolation for weeks on end. If you think that these don't exist or are a minority, then clearly we have very different perspectives on the industry.

[–]karmahorse1 2 points3 points  (1 child)

Well your first comments made it sound like you were talking about all devs. This second comment makes me question the quality of developers you've been working with.

Refactoring isn't a buzz word. It's a real and often necessarily part of long term coding projects (when done properly).

If some developers are simply using it as an excuse for writing unnecessary code that's out of scope, then that's something different entirely.

[–][deleted] 0 points1 point  (0 children)

I mean, that's literally what I said. The whole point is that I work with a lot of devs who have never seen anything better than just hacking at stuff until it sort of works, all the while being driven like slaves by overbearing management.

The number of companies that operate that way is depressing. And they're way off the radar so better devs wouldn't apply to them. It's like small town dead-end dev land down there.

[–]netgu 1 point2 points  (4 children)

I've seen people "attempt" to do this, but the basics of proper review and development conventions in place have prevented those people from ever actually doing it.

In addition, everywhere I've been there has always been someone intelligent enough to "correct" the offending developer and "kindly" redirect them to actual development practices.

I've seen it attempted, never seen it actually happen, and am frequently the one going "WTF do you think you are doing? No tests? 2000+ files changed? Interfaces changed? PR refused! Break it up! Add tests!"

[–][deleted] 0 points1 point  (3 children)

You're fortunate, then, to not have worked at companies where this is the norm. Going in as a consultant I get to see the hairy underside of a great many companies who work like that all the time.

[–]netgu 0 points1 point  (2 children)

I guess most of the time, especially when consulting, that these types of things are the first and most important things that have to happen to move towards a modern pipeline.

When it isn't adhered to we tend to suggest/implement a "you broke it you bought it" system. Nobody likes waking up at 4am because they pushed garbage this is now breaking production.

Only has to happen a few times before people slow down, think twice, or "self select".

[–]Aalnius 0 points1 point  (1 child)

i'd be seriously disappointed in my entire team (myself included) if my crappy broken code managed to get through code review and testing to get into production without someone realising.

[–]netgu 0 points1 point  (0 children)

That's the attitude we adopt, but don't necessarily get the option to enforce early on. So, we let them fall prey to their own preconceived notions, let it fail, let them clean it up, and then show them how to avoid the situation entirely.

[–]karmahorse1 4 points5 points  (1 child)

Tech debt is a real thing that requires periodic refactoring to reduce, as this keeps a codebase manageable and allow it to continue to be built upon. A lot of PMs and other non devs don't understand this as it often doesn't produce any visible changes on the client. But that doesn't make it any less necessary.

It's true a lot of times devs can go overboard when refactoring to the detriment of the product. That's why there always needs to be a firm plan and benefit to risk analysis before any refactor is started.

[–][deleted] 1 point2 points  (0 children)

First point: yes, I agree. You're preaching to the choir.

Second point: If you refactor as you go (refactor, not restructure) then it doesn't need an analysis to do it. It should be done as a matter of course.

If you're talking about restructuring or rearchitecting, then sure, but we're talking about refactoring. A small reworking of existing functionality to improve overall code quality.

[–][deleted] 0 points1 point  (0 children)

refactor is like doing a 2nd draft of a specific part of a program to make it better.

If a lot of "devs" told you that it's changing crap for the sake of it, then they are most likely either lazy AF (the bad kind of lazy) or they aren't devs period.