Refactoring code

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

Share on facebook
Share on twitter
Share on linkedin
Share on print
Share on email

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.

Share this post

Share on facebook
Share on twitter
Share on linkedin
Share on print
Share on email

Editors Note

Don’t hesitate if you can’t see your comment immediately. Your first comment has to be approved by one of our editors.

Nik Sumeiko

Nik Sumeiko

Nik makes sure 4 million people transfer money with no trouble every day. He’s payments hacker, software engineer at George. Practices clean code, TDD and Refactoring. Nik is also passionate about people, contributes to building internal engineering culture within the company, champions knowledge sharing and creates growth opportunities for team members. Visit Nik's Twitter.

Leave a Reply