My mistakes in working with legacy code

Hi everyone. A little bit time before, I have to work with legacy code. I need to extract the two from a lot of functionality. Of course the other functionality can work too. I need only change the way how it works and replace a kind of connection to database, servers and other applications. I made a mistake and I want to share my conclusion for it.

How will I do it today?

  • I will get a knowledge.
  • I will get the use cases.
  • I will validate the knowledge with the code and the use cases.
  • I will change only fragment of code, where I must change.
  • The end.

Why?

Get a knowledge

I started from getting a knowledge from my colleague. I ask a lot of questions, get information about core functionality and what they want. If you worked with legacy project you know that knowledge is very poor.

My first mistake was I didn't verify that knowledge in the code. I started working with code and three days later I got the blocker. I couldn't do it like I wanted, so next time I will try to validate this knowledge, because people sometimes think that work like that, but in real it work differently.

Extract only functionality which we want

I had an idea. The less functionality than the less problems, so I tried to extract functionalities, which I thought I needed. The two days later, I changed my mind. The functionalities were very linked. I must extract more than 50 percent of code and these still didn't work. I implemented some workaround and it worked. Next time, I won't extract the code. Why? Because if that code working together, when I touch it, it can stop working.

I want to change framework for one of functionality

The next problem was with functionality. I need to change it, but I don't have a lot of knowledge about the framework. I had the next best idea. I change that framework for my solution. This was stupid. Yes, I did it, but after that I know the framework, which I changed. The second problem was with the functionality of the framework. The first way is skipped some error on annotation, but the second doesn't work with these errors. I won't change a framework in legacy code if I don't need it. Of course, when I will do new module for that project, I want to do it better with other frameworks, but I will do it separated.

I don't ask about user story and I don't test everything

When the knowledge is poor, you have a problem with testing this product. I had the same problem. I tested cases which I read from code and when all of them working fine, I went to clients. After 30 minutes of testing this didn't work correctly. I could verify it before, but I didn't ask about all use cases. I knew only what I got, but that wasn't the use cases.

Summary

After that working I think that ambition is sometimes bad. I was working a lot of time with legacy code, but at that time I didn't have a knowledge about how I can do it better. Now, when I have a knowledge I wanted use it, but this was a killer for me. Now, I am smarter and I want to share that knowledge for you, because time never back.

Comments

Popular posts from this blog

Why TDD is bad practice?

How correctly imitate dependencies?

Software development using Angular 5 with Spring Boot