My mistakes in working with legacy code

By -

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

Post a Comment

Popular posts from this blog

When we should use Mockito on Unit test?

By -
Image
As I mentioned, I would like to tell you something about Mockito on unit tests. You should know about where use unit test, because I will use that context for this post. What Mockito is? I changed my thinking about Mockito object and this step allows me to use it only in a good place for it. I think about Mockito objects only like data source (on "given" section) and communicate with other system (on "then" section). Why? Because I think when you use a lot of Mockito objects, you don't have a single responsibility in testing code. You use mock or stub for a lot of objects, because you think that part of the code isn't currently important. I don't think that it doesn't important if you have on that method. Maybe it should be another function in another place. When you think like me, You will use it only for a really important place for it. What can I stubbing? As I mentioned You can stubbing data sources. This is a good place for it, because Y...
Read more >>

How correctly imitate dependencies?

By -
Image
This is continuous of my previous post about why we should imitate our dependencies. I did it not long ago. I though about how do it properly and when I can say that it is correct. Start from test and real dependencies I am starting from the tests. I wrote the simple tests which, I though, are correct. That was my learned about dependencies. I had the good situation that I had some prepared tests before. During the writing test I got a knowledge. A lot of time, I verified what the system return. After it, I got the full automated tests for my dependency. Now, I am sure that dependency works like I think. Like my test use it. I think this is a very good advantage. Extract the interface for communicating The implementation to communicate is implemented and tested. Our test, if you implement it like functionality test, not code test, should show us, how we want to use our dependency. We know what parameters we use, what methods. We know what we want. That is a place where we must extr...
Read more >>

Czysty kod - komentarze

By -
Przedstawię tutaj moją opinie (opartą na doświadczeniu, książkach oraz opiniach innych ludzi) na temat komentarzy w kodzie. Co to są komentarze? Wiem, każdy wie co to są komentarze. Przedstawię tutaj tylko inną definicje komentarzy. Komentarze to ZŁO (czasami konieczne). Zaraz dowiecie się dlaczego. Komentarze opisujące kod Jestem całkowitym przeciwnikiem komentarzy, ale często sam je stosuje. Zapytać teraz możecie "ej, ale dlaczego?". Wykorzystuje je właśnie jako pomocnik do poprawy czytelności cudzego, a nawet czasami swojego, kodu. Staram się nie zostawiać komentarzy w kodzie. Są one półśrodkiem do refaktoringu. Refaktoring dużej, brzydkiej i nieczytelnej funkcji zaczynam właśnie od podzielenia kodu tej funkcji na sekcje i napisaniu odpowiedniego komentarza opisującego te bloki kodu. I tutaj właśnie zauważyć można dlaczego tak surowo oceniłem komentarze. Uważam, że komentarze po prostu próbują zaślepić użytkownika kodu, aby nie zauważył, że jest napisany źle i nieczyte...
Read more >>