From the developers community: Why refactoring code is a win for everyone.

Refactoring code

Yesterday during a #hackday I’ve been doing pair programming with a teammate. We were refactoring a very start of George, our digital banking web application. Legacy code, responsible for booting up the app, is there for a few years now. It’s very hard to understand it. We wished to come up with a much more cleaner implementation in favour of clarity and readability, so any developer taking over this part in the future could quickly figure out what it does and easily follow business logic within.

Before changing a single line of code, Silviu and I spent a decent amount of time ensuring current implementation has 100% test coverage. Having tests prior to refactoring is the only reliable way to make sure observable behavior of the program stays the same after implementation changes. Writing new tests and maintaining existing once helped us to figure out how everything works. Actually, when tests are simple, they work as a documentation for a developer.

Then we made some purely internal changes, extracted few abstractions, clearly separated composition from operations by employing Integration Operation Segregation Principle (IOSP), all with a purpose to make the program easier to understand, easier to follow.

At the end of the day, I think pair programming gave us a good lesson. Well, as always. Every time we write code together, we learn. No matter, how experienced and skilled both of us are, pair programming enables developers to discuss and review the code from various angles, to challenge each other knowledge and come up with a clean, easy to follow source code.

Refactoring is a win for everyone.

For business, it’s about an economics. We refactor in order to get more features out, more rapidly, to make software more responsive to changes users or/and managers need. Business wins.

Developers win by learning refactoring techniques from each other, training patience and empathy while observing a work of a teammate. It’s also useful practice to formulate our opinion about implementation ideas proposed by a colleague, treating the work of other person with respect, still challenging it when appropriate.

Nik Sumeiko

Nik Sumeiko

Nik makes sure 8 million people transfer money with no trouble every day. He's a payments hacker and software engineer at George. By systematically posting on LinkedIn, Nik champions knowledge sharing and creates growth opportunities for software engineers all around the world. Connect with Nik.

George is presented by

Copyright © 2023 Erste Group Bank AG