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??
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (13)
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:
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.debugstatements 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.
Avoid the Code Crawl by Reading Tests
Brandon Martinez
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.
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.
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.
+1 for Working Effectively with Legacy Code - excellent book!
Yeah, this is definitely territory where UncleBobeology shines.
Thanks @ben . Yes, I have started writing some test code but needs lots of patience really!!
On this general topic, I really like this post from the current DEV homepage:
Why do great developers love writing tests?
anabella
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.