DEV Community

samsha1
samsha1

Posted on • Updated on

How it's like to refactor code, written by other developer?

Currently, I am working in Menuboard manager project written by some other developer. Now, the developer is out of contact. So, I am given the task to refactor his code and add some module. My question is How can one understand the flow of code without any code documentation and project goal??

Top comments (13)

Collapse
 
rhymes profile image
rhymes

I love refactoring code, mine or other people's. It helps me learn something new and figuring out how it actually works or how it can be improved.

Just don't get carried away into refactoring everything.

Choose an inital goal, maybe a small one. Yeah this or that module could be better but:

  • are you refactoring to lower the technical debt?
  • are you refactoring just for the sake of refactoring?
  • are you refactoring to make way for new features?

I agree with @kuhnerdm , you should write a few tests of your own, especially if there's neither documentation nor comments.

Keep in mind that refactoring can introduce bugs, especially if there are no tests :D

Collapse
 
samsha1 profile image
samsha1

Hey, @rhymes thanks. Now, I am clear that tests are key things to start with as mentioned by many.

Collapse
 
rhymes profile image
rhymes • Edited

I forgot to mention this: I would begin with functional/integration tests first, unit tests later or at least I would de-prioritize them.

If there are no tests you should start testing for features, not necessarily for small units.

Play with the actual app, understand how it works, maybe sprinkle it with some log.debug statements if you're unsure, then write a test where you "excercise" a behavior and expect an output. If you do this a few times you setup a battery of tests tied to specific functionalities.

After that you can refactor with a little safety net in the form of those tests that can also act as a documentation for posterity.

Collapse
 
cseeman profile image
christine

This as been every job I have ever had. Some legacy code is worse then others! I typically term it code archeology. Hopefully you have some tests, that gives you some leeway with the code and can help you understand what it does. When I have to walk through new code I pick a direction, either UI on down, or start with the backend/db and work your way up through a workflow. Pick a feature, and try to understand how it works top to bottom.

If there are no tests, add some as you go. You can test how you think it is working, it will help your understanding, as well as improving test coverage and maybe even code quality.

Collapse
 
courier10pt profile image
Bob van Hoove

To get an idea of the control flow stepping through the debugger in a simple scenario may help, in this case that would be a menuboard with very few items.

If there are no tests you may be able to use tooling for automated refactoring to make the code a little bit easier to read.

Collapse
 
ben profile image
Ben Halpern

Oooh this is a juicy topic.

I think key to both understanding of the code and confidence in changes: Tests!

You're in luck if there are tests.

If you don't have tests, you still may want to start attempting to write tests to get your head on straight about the way the code works.

If it's not practical to write tests, I think it really becomes a matter of poking and prodding and learning about the behavior, and start making some small local refactors as you work your way into a better idea of the whole code base. You definitely want to be cautious and defensive in this process.

Collapse
 
derekjhopper profile image
Derek Hopper

Uncle Bob had a recent Twitter thread about this too: twitter.com/unclebobmartin/status/...

If you have no idea how the code works, poking and prodding seems like the best place to start. Once you start to reason about the flow and understand things enough, start adding tests. Basically, do whatever it takes to get the code under test.

You definitely want to be cautious and defensive in this process.

If you have time to read or study, the book Working Effectively with Legacy Code might give you some ideas on how to be defensive.

Collapse
 
bosepchuk profile image
Blaine Osepchuk

+1 for Working Effectively with Legacy Code - excellent book!

Collapse
 
ben profile image
Ben Halpern

Yeah, this is definitely territory where UncleBobeology shines.

Collapse
 
samsha1 profile image
samsha1

Thanks @ben . Yes, I have started writing some test code but needs lots of patience really!!

Collapse
 
ben profile image
Ben Halpern

On this general topic, I really like this post from the current DEV homepage:

Collapse
 
shubhamrai1993 profile image
shubhamrai1993

Personally I like refactoring as a great way of understanding someone else's code. Just keep adding comments wherever you struggled to understand. Usually useful to someone.

Collapse
 
kylegalbraith profile image
Kyle Galbraith

I agree with this for the most part, but I think it's important that the code you are refactoring has tests before you actually commit to refactoring. Another approach here, if the tests don't exist, is to write the tests yourself. This is another great way to learn some else's code.