Refactoring disappointments

During my university days, I was a big fan of refactoring. I believed it should be done as much as possible in every situation when you encounter a code smell. But university days meant a lot of books and no real practice. Migration to the industry, specifically to SimCorp taught me that my beliefs were not true. Refactoring can be harmful in certain situations and it also can be really disappointing and demotivating activity. Here are some cases which I experienced in my career:

Refactor-distractor. Refactoring definitely takes away your time which could have been used for development of new features or fixing bugs. Now, sometimes refactoring is worth doing when you can clearly see the benefit of it when you can get 80% of improvement with 20% of the efforts. For example, you can see that few hours of refactoring can help putting important functionality under test or improve understandability of the frequently changed code. But often you will find yourself doing code improvements on the part of the system which rarely gets changed or doing improvements to the code which is already good enough. Diminishing returns law works here. You are pushing towards better code but into every further code improvement, you need to put more and more resources. I don’t know about you, but when I got caught by this type of refactoring, at the end the day I always feel pissed. The feature I am expected to deliver is not progressed and resulted code is not ideal because it is just never ideal.

Refactoring with no domain knowledge. Avoid doing refactoring if you don’t understand the domain of the software very well. This lesson was delivered to me by SimCorp. They have extremely complex financial software which they produce for a very long time. Every system which is in production for a long time has a lot of legacy code, SimCorp Dimension is no exception. And here I am, a freshman developer who just defended Ph.D. on refactoring and given the task to fix some bug deeply in the core of business logic. I discovered a function which length was over 7 hundred lines. It was definitely bleeding for refactoring and I immediately jumped in and starting extracting new functions. But there was a daunting problem! I did not know how to name those new functions. I had the best intentions and good technical knowledge but these prerequisites were far from enough to be able to do worth refactoring. I was running around distracting my colleagues and asking what they thought was the best name for this or that piece of code. I have finally done with this refactoring. It took few days and I was already exhausted and disappointed that my bug fix took that much time. But this was only the beginning of the trouble. Now, when something went wrong with this code, people started redirecting bug reports to me, although I absolutely was not aware what this code did in terms of business logic. No one actually came to me and said thanks for this clearing up! And this is because they were not happy with my changes at all. They knew the code well and now I have changed it and gave awkward names to the functions. Without domain knowledge, I made things even worth. Even after almost 4 years of my work there my, now good friends and colleagues, joked about names I gave to extracted functions.

Large refactoring by a dedicated team. As I said I was huge refactoring fan when I started at SimCorp. Therefore I joined the refactoring team which was forming soon after I joined this great company. The task of the team was to improve very badly rotted part of the system. Although I learned some good lessons from this experience, in about a year I understood it was a bad idea to have dedicated refactoring team. My discovery was supported by plenty of blog posts and books which described similar situations and came up with the similar conclusions. To make a long story short – it is very hard to justify for a business an existence of a dedicated team which does not deliver a tangible value. We completed only one project in a year which was only the part of big refactoring, although we worked pretty hard. Personally, I realized I wanted to deliver value to customers, it turned out it was a motivating aspect for me. Just re-coding what was already working well turned out to be a little fun to me. So I left the team and very soon it was dropped by the management. Most developers agreed that refactoring should be done gradually as a part of features development.

Facebooktwittergoogle_pluslinkedinmailFacebooktwittergoogle_pluslinkedinmail

Вступ до програмування на TypeScript

Дебютував у царині проведення вебінарів :-). Трохи виснажливо, трохи незвично говорити російською, трохи переслідував мене demo ефект, коли щось ломається або не працює у самий непідходящий момент, але я ніби впорався. Принаймні покищо лайків більше ніж дислайків :-).

Facebooktwittergoogle_pluslinkedinmailFacebooktwittergoogle_pluslinkedinmail

My 2 cents on why you should try TypeScript

It has been said a lot about the value proposition of TypeScript. But I still want to add my 2 cents and talk about the reasons to use TypeScript from the personal perspective. So, here is my list:

  • It’s main designer is Anders Hejlsberg. Well, strange reason, I know. But this guy has designed Turbo Pascal, Delphi, and C#. All widely adopted and great technologies. People love them. Let’s face it, experience matters and I think the guy with such a background behind TypeScript increases its chances to succeed.

  • It is supported and developed by Microsoft. Again strange reason, but it seems to me companies are good at certain things and it is very hard for them to become good at other things. Look at to Google’s social network Google+. Is it nearly as good as Facebook? Another example is Microsoft’s Bing search engine. Is it as good as Google’s search? Microsoft has always been good at creating great developer tools and this increases TypeScript’s chances to succeed.

  • Scientific research shows that static typing can help developers with maintenance tasks. This is a more objective reason and it is the core one. We have hard data which proves that TypeScript improves your effectiveness at JavaScript maintenance tasks. And you don’t have to reflect hard to see the reason. I have parts of my project at work in TypeScript and after working in such a part for some time I get used to autocompletion, “Find definition/pick definition” and renames. Recently I had to fix a pretty complex bug in the pure JavaScript codebase and I struggled a lot. Not that it was very hard to understand the code, but it was extremely hard to navigate in the code. For example, I open the function. I see it calls another function with some parameter. I want to see what this parameter is, like what is its type or whether it is an array or not but I can not. Now I want to see the definition of that called function but for this, I need to search the whole codebase. After I have found the definition I want to go back to the caller but this is again not a simple key stroke as it would be in TypeScript. I don’t even think about renaming the function. It simply does not work. To rename you have to go through all the codebase again and try to understand where you function is called and if this is your function or some other function with the same name. Entering new code in TypeScript is also faster than in JavaScript. This is because you just hit dot and you have the list of API options you can select while in JavaScript you have to remember all the API details. Since remembering never works, at least in my case, you have to search the web for API documentation to recall or learn how to use it. Hence TypeScript improves API discoverability. Pathikrit Bhowmick summarized experience with type system:

    Static typing is like spell check.
    Dynamic typing = writing your essay in Notepad.
    Static typing = writing your essay in Word (or Grammarly).

  • TypeScript is the mature and open source project. And this is important for production. It was introduced in 2012, so at this point, it is 4 years old language. It has many great and stable features, its compiler is fast and can be tuned to be even faster. It has native support in most popular IDEs like WebStorm and Visual Studio. It has a lot of tooling around it and even linter. It has huge, community developed code base of type definitions for popular JavaScript libraries and frameworks. It has a vibrant community which produces courses and answers questions on the forums. All in all, today starting doing a production with TypeScript is relatively easy and smooth.

  • TypeScript can help to deal with JavaScript’s quirks. It can not fix everything as it is a superset of JavaScript, but it can help a lot with some JS problems. For example, it can help you to not mess up your “this” accidentally. It will not allow you to forget to write your return statement and fall into the trap of semicolon auto insertion. It will not give you a chance to create a global variable inside the function. It will help to avoid shooting yourself in the foot with type coercion. I will write another blog post explaining how TypeScript fixes JavaScript later.

  • Fool protection. Here in Ukraine, we tell the system is fool protected if it has means to protect itself from user’s incompetent actions. For example, one can not insert battery the wrong way into the smartphone or insert the cable into the wrong computer’s port. This whole concept of inserting something only where it fits is extremely suitable to describe a type system. With TypeScript I can only insert a variable into the function where it fits. And this is great. Not that I am a total fool. I would like to be focused on solving the business problem not on whether it is ok or not passing something into the function. I also can be tired or ill or disappointed or distracted or not fluent with current codebase or whatever. All these reasons can cause me to make a fool mistake which will be corrected immediately by TypeScript and which would live until runtime in JavaScript.

  • Typescript is zero risk to your project. This is because it generates beautiful idiomatic JavaScript. Hence had you wanted to move back to JavaScript – you would just compile your TypeScript sources to JavaScript and off you go.

  • You can generate definitions of your RESTfull API from your backend code. This way if some breaking change happens on the back-end, after declarations regeneration, you will immediately get a compiler error and we all know, the faster feedback loop the better.

To summarize, I would say I just feel more relaxed doing TypeScript. It gives similar to C# and VisualStudio joy of coding.

Facebooktwittergoogle_pluslinkedinmailFacebooktwittergoogle_pluslinkedinmail