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

Updated on Nov 19, 2018

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??

Did you find this post useful? Show some love!
DISCUSSION (14)

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

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

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.

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.

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.

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.

Even if tests already exist, you should also probably be writing your own. This will either a) find cases that the existing tests don't cover, or b) help you realize you're understanding something wrong.

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

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.

Yeah, this is definitely territory where UncleBobeology shines.

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

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.

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.

Classic DEV Post from Jun 2

Javascript needs competition on the front end. Thoughts?

...

samsha1
I can't quit learning!

A blogging community of over 100,000 software developers Join dev.to