Programming is the task of efficiently creating software that works properly, and to do this well, you need to create code that is easy to maintain. A highly effective method to create a code that’s easy to maintain is to loosely couple an object. The Gang of Four said the following in a design pattern.

Program to an interface, not an implementation.

We call a coupling relationship which is independent of the implementation and relies on the interface, loose coupling. Loosely coupled code is easy to scale and maintain. It can still be managed as the program grows bigger and more complex.

The software design principle and pattern which allow loosely coupled codes to be written are called dependency injections. It is an element that cannot be found in a tightly coupled code, so to understand why this additional element is needed, you need to understand the advantages of a loosely coupled code first.

1. Late Binding is possible.

The implementation can be replaced without recompiling the code. Although not a perfect example, looking from a mobile app perspective, it’s similar to the principle where users can experience new features even when the app is not newly deployed when the OS gets updated or the framework provided by Apple/Android gets updated.

However, mobile app developers cannot relate to this. Because the app runs only in an environment defined and implemented by the developer, virtually there’s no need for the implementation to be replaced. For example, when creating an app that needs a database, there’s no need for a developer to make an assumption or even consider a case where his or her app is going to run on an environment with a different database other than the one introduced by that developer. Therefore, a late connection cannot be considered an advantage taken by a mobile developer. But there are more advantages of loose coupling other than this.

2. Easy to scale and reuse.

An app changes its requirements according to the users and continues to evolve according to the business. If the class/module is loosely coupled, it becomes easier to develop a new feature or modify and expand existing ones. Loosely coupled codes are open to scaling and closed to modifications. In a loosely coupled code, there is a separate composition root, where objects are assembled. Since actual implementations are created and injected here, it is not necessary for the codes that are using the interface to change.

For example, when there is a payment feature in the app, if the code on the product side relies on the payment-related interface, you don’t have to touch the codes from the product side that use the payment features when improving or restructuring the payment flow. You can think of A/B testing in a more general way. When you need to provide the same feature in several ways, you may add or remove a new feature without modifying the code which calls the feature.

3. Parallel development is possible.

As the project and the team grow bigger, many developers will work in parallel in one codebase. If the codes are loosely coupled, it’s easier for the developers to work on several modules simultaneously.

Grab mobile development team has more than 100 developers divided into less than 10 big TFs(Tech Family) in mobility, food, payment CX, etc. Each team uses features developed by other teams(real-time chat, payment, balance inquiry, reward points, user information/authentication, etc.) and is able to simultaneously develop the super-app thanks to loosely coupled codes.

4. Maintenance is easy.

A code that clearly distinguishes the boundaries and roles of classes and modules is easy to maintain. When developing a new feature, it’s easy to figure out where to modify it and recognize the scope of impact. Debugging is also less difficult in code that is coupled with a class or a module which has only one role. This is because if the role and the scope are well-separated, it’s possible to narrow down the point that may have caused the bug relatively well.

5. Testing is easy.

To be exact, unit testing is easy. To do a unit test, the test target needs to be isolated from its dependency. If the objects are loosely coupled, it’s easy to replace them as test targets.

There will be some people who do not appreciate the need for unit testing or the ease of testing for code structures. According to the Jetbrains developer survey of 2021, 62% of Swift/Obj-C developers do not make unit tests. However, once you experience the benefits of automated testing (with a little exaggeration), you can’t go back to the days when you didn’t make test codes.

Unit testing allows for the automation of significant testing tasks. More than 100 developers are creating hundreds of thousands of app codes in a month, it’s practically impossible to manually check the actions of the new and existing codes without unit testing. When our team was just newly created in Grab, the code coverage was low, but after more than a year of adding tests, the number of regression bugs and critical bugs decreased noticeably as a result.

Conclusion

According to Uncle Bob, the most powerful weapon given to developers by object-oriented languages is the safe use of polymorphism. Thanks to polymorphism being safe, developers can make all of the implementation details that their system is depending on into replaceable plugins.

It became possible to make the coupling between modules loose. Furthermore, Uncle Bob questions what is the reason for not designing the system this way when you know you can do it this way. (From The Future of Programming Languages Lecture)

얼핏보면 개발자는 각자 컴퓨터랑만 일하는거 같아 보인다. 하지만 보이지 않는 팀워크가 조직의 실행력 뿐 아니라 코드 품질과 개인의 성장까지도 결정한다. 여러 팀을 거치며 동료를 다양하게 많이 만날수록 팀 스포츠를 하고 있다는 생각을 한다. 똑같은 프론트엔드 개발자라 하더라도 누군가는 손이 빠르고, 누군가는 설계를 잘하고, 누군가는 UI를 매우 잘 만들고, 누군가는 멘토링을 잘하고, 누군가는 분위기 메이커 역할을 잘하는 등 여러 포지션을 나눠 가지고 있다. 그리고 의사결정을 할 때도 기술적으로 딱 떨어져서 만장일치가 되는건 환상에 가깝다. 팀이 처한 상황에 따라, 경험이나 능력에 따라, 또는 누군가의 영향력에 따라 유동적이다. 같은 문제라도 팀마다 다른 해결책을 도출해낸다.

그래서 중요한게 팀워크인거 같다. 문제 상황이 닥쳐도 유연하게 대처하고 빨리 회복하게 해주는 원동력이다. 그리고 팀워크의 기초는 안전감과 신뢰라고 생각한다.

개인을 탓하지 않는 분위기

문제가 발생했을때 일을 맡았던 담당자나 문제 코드를 작성한 개발자를 탓하는건 쉽다. 하지만 이건 심리적 안전감을 해치는 정말 나쁜 문화다. 게다가 개인의 잘못이나 실수라고 여기고 끝내면 그 팀은 똑같은 유형의 문제를 나중에 또 겪을거다. 문제 자체보다는 ‘누가’ 일으켰는지만 기억에 남기 때문이다. 문제와 사람을 분리하지 않고 문제 자체를 더 깊게 파고 들어가보지 않았을 것이다. 그러면 팀원들은 이번엔 나만 아니길 바라며 조마조마한다.

예전 조직장님은 문제를 수습한 이후에 꼭 팀을 모아놓고 이렇게 말하셨다. “문제를 피하고 싶으면 아무것도 안하면 된다. 레거시도 잘 돌아가니까 그냥 두고 새로운 도전도 하지 말고. 그런데 우리는 그러면 안된다. 계속 발전하고 성장해야 한다. 문제를 겪었으면 재발 방지책을 철저히 세우고 또 도전하면 된다”고 독려했다.

예전 매니저도 문제 발생 상황시 팀 전체가 모여 해결책을 논의하는 자리는 언제나 이런 말로 회의를 열었다. “누구를 탓하고 추궁하려고 모인게 아니다. 여기 있는 누구라도 이런 실수를 할 수 있었고 그렇기 때문에 앞으로 똑같은 실수를 우리 팀에서 원천 차단할 수 있는 해결책을 마련하기 위해 모인 미팅이다.”

자신이 문제를 일으켰다는게 밝혀지면 사람은 본능적으로 자신을 방어하게 된다. 다른 사람이 하는 말들이 자신과 자신의 능력에 대한 비판으로 들린다. 그래서 리더가 더 적극적으로 이런 분위기를 만들어서 문제와 사람을 분리하게끔 유도하면, 개인은 안전감을 느끼고 이걸 토대로 팀 차원에서 문제를 해결하고 방지책을 세울 수 있다.

머리로 하는 회고

문제와 사람을 분리하고나서 하는 냉철한 회고는 성장통과 같다. 당사자 입장에서는 부끄럽고 곤욕스러울 수 있으나 자신의 인격에 화살이 향하는게 아니라는 안전감이 있으므로 문제 해결과 재발 방지를 위해 무슨 일이 있었는지 투명하게 공개해서 팀이 함께 대처하고 회복할 기회를 얻을 수 있다.

그랩에서는 핫픽스를 하게 되면 몇 주 내로 공개적인 회고를 한다. 회고에 앞서 미리 사후 보고서를 양식에 맞게 채워놓아야 한다. 문제 조치한 시각표, 사고의 영향, 원인, 방지 대책 등 최대한 구체적이고 자세히 적는다. 그리고 1시간의 회고 시간 동안 개발자 수십명이 모여 날카로운 질문을 던지고 해결책을 제안을 하며 집단 지성을 발휘한다. 얼버무리면서 넘어갈 틈은 없다.

처음 참석했을 때는 제 3자가 들어도 살벌하다고 느낄 정도로 직설적이어서 흠칫하기도 했다. 하지만 계속 듣다보니 모두가 한 마음으로 모였다는 걸 알 수 있었다. 청문회가 아니라 작전 회의인거다. 최대한 감정을 빼고 차갑게 회고를 하면 함께 성장할 수 있다.

같이 성장하려는 자세

오랜 멘토님은 프로그래밍 실력을 언급할 때마다 개인이 아니라 팀을 주어로 놓고 말씀할 때가 많았다. 전체적인 코드의 품질이나 코드 리뷰의 수준은 가장 잘하는 개발자가 아니라 팀의 평균 실력을 따라간다는 것이다. 그래서 우리가 문제를 더 잘 해결하려면 누군가 혼자만 잘해서는 안되고 팀원 전체가 같이 성장해야 한다. 스터디를 지속적으로 만들고, 또 열심히 참여해서 지식을 나누는 개발자들은 이걸 아는게 틀림없다.

아주 가끔씩 그런 개발자가 있다. 새로운 팀에 오자마자 레거시의 잘못된 부분을 죄다 지적하고, 본인의 기준에만 맞춰 코드 리뷰를 하면서 기존 팀원들을 깎아 내린다. 레거시란 어제까지는 최선의 선택이었다는 말이 있다. 자신이 새롭게 기여할 점이 보인다면 팀원들을 설득하고 지식을 전파해서 팀의 평균을 끌어 올리는게 맞다고 생각한다. 자신과 팀을 분리해서 생각하면 양쪽 모두에게 이로운게 없다.

사람들은 혼자 돋보이려는 사람과 진심으로 팀을 위해 헌신하는 사람을 아주 잘 구분할 수 있다. 선의와 친절로 서로를 대하는 사람들 사이에는 신뢰가 생기고, 반면에 혼자만 잘하려고 하는 사람은 팀워크를 해친다. 그래서 어떤 선배 개발자는 채용할 때 인성이 제일 중요하다고 말하고, 어떤 유명 코치는 개인의 능력이 아니라 그 사람의 태도를 보고 채용해야 한다고 말하는 것 같다.