5 ms·
This is super specific to each project but here things that worked for me in previous projects. Two assumptions: You plan to work on this longer-term (not a 1m
by andreasklinger 8y ago
This is super specific to each project but here things that worked for me in previous projects.
Two assumptions: You plan to work on this longer-term (not a 1month project stint) and there are things worth improving (eg barely used legacy app might not be worth your time)
#1 Get the team on board
if there are multiple people you need their buy-in and support for whatever approaches you want to do
#2 Plan for "health by a thousand small improvements"
it will be an iterative approach and you will refactor as you go.
#3 Don't assume different = bad
people might have done differently, consider using their approaches. you might do it differently. but it's better if you keep a consistency within the codebase. in codebase management consistency trumps cleverness
#4 Create space
Consider introducing a fix-it friday where everyone can work on little improvements
#5 Create non-blame culture
Stuff will break if people risk improving things. Avoid blame shifted to them. If bug trackers ping individual people consider pinging the whole team instead
#6 Consider automation
introduce linters, autoformating, codemods, danger.js, code complexity analysis, etc
#7 Introduce tests
This one is the most annoying. But worth doing: whenever you improve a feature a bit try adding a test - often in legacy apps there are no good tests. A lot of people recommend writing a test suite for the whole app before you do anything. If you are lucky enough to do this try it. I always found the iterative approach more realistic as you can also do feature work while refactoring.
When doing tests focus on integration (vertical/functional/etc) and not unit tests (unless the "unit" contains critical or complex logic). Your goal is to know "that you broke something" - you get by if you don't always know "what you broke"
#8 Acknowledge tech debt
not everything needs refactoring. If it's not critical and nobody needs to touch it consider acknowledging it as tech debt. Add larger notes above the problematic areas and explain why you aren't refactoring it, explain things worth knowing to understand the code better, etc. Whenever you leave comments remember that comments should explain "why" not "what" the code does.
hope that helps! good luck.
- JustSomeNobody 8y agoYour #3 seems to contradict nearly all the others. Most of the rest seem to be about assuming things need to change (different == bad).
- dragonwriter 8y agoThe others are largely about how to successfully manages the changes you determine are necessary, as I see it, not about assuming things need to change. If nothing needs to change, it's easy, you just try to look busy and collect your paycheck until you find a position with actual work (because eventually people will notice you aren't needed.)
- andreasklinger 8y agoYes - basically saying: just because previous workers did things differently than you would doesn't mean it's wrong i updated the comment to explain this (hopefully) better
- abraae 8y ago> "code that doesn't get touched dies" - so you want to "touch up" code as often as possible and get into a habit of small improvements. I've seen many cases where this is far from true. Tightly and well-written back end code in a well-designed system can run for years - even decades - hardly being touched. User-facing UI code less so of course.
- humbleMouse 8y agoI agree. That's one of the most ridiculous code tip's I've ever heard.
- andreasklinger 8y agodisagree here but in favor of simplicity of the main message removed it.
- YjSe2GMQ 8y agoDisclaimer: I don't know anything about managing a team, this advice is more for a solo developer or a developer joining a team. #2 is what I use. After one/two hundred tiny commits (even if it's sometimes just fixing grammar in comments) you'll feel more at home. And because they're small you can achieve that within a few weeks. This requires any way of telling that things still work. Sometimes you'll be able to do that because the transformation is an identity given the language definition, but for other cases I'd encourage #7. Having someone more senior (with respect to the codebase) review changes helps (this is what I mostly used), but I understand you don't have that option.