4 ms·
I think it’s hard to do refactorings in the context of a product-oriented team that works in sprints of 2 weeks. I have two options: a) either I make the rewrit
by tkiolp4 3y ago
I think it’s hard to do refactorings in the context of a product-oriented team that works in sprints of 2 weeks. I have two options: a) either I make the rewrite 5 times in a row… but that would take a lot of time, so management won’t buy it (and I cannot just do it on the side because it actually takes time), or b) I do the rewrite one at a time, but then for every intermediate rewrite I need to open a PR and spend time with my colleagues doing the review. I don’t have anything against about PR reviews, but reviewing intermediate work feels like a waste of time (and kills the fun, because I know where I’m heading to, it’s just not obvious YET how to achieve it, hence the intermediate steps… I don’t really want to answer questions about intermediate work).
On personal projects, it’s a pleasure to rewrite code until I feel it “looks” good.
- ResearchCode 3y agoJoin a team that doesn't do "sprints" if you want to do meaningful work.
- Closi 3y agoThere is a different pressure on refactoring in 2023 than in the 1980s / early 1990s. If you need to fit your application into 5kb of pascal code so it can be bundled with an OS, there’s going to be less code to refactor and probably less ability to not-refactor. (Not saying refactoring isn’t important now - it’s just more of a choice now and would usually have different goals)