심플 소프트웨어 책을 읽고, 내가 회사에서 하고 있던 행위가 떠올랐다.
한 때는 아키텍쳐 내에서 강한 의존이라는 버그를 끊어내기 위해 온갖행위를 했다. 과거에 했던 프로젝트 중에 Notification 프로젝트가 기억에 남는다. 이 프로젝트는 유저에게 메세지 채널을 통해 메세지를 전달하는 프로젝트이다. Slack, Email, MMS 등 메세지 채널이 될 수 있는 컴포넌트가 있고, 프로젝트 안에서 MMS 을 받지 못한다면, 카카오톡으로 메세지를 전달하도록 한다. 카카오톡으로 메세지를 읽지 않는다면, 메일로 전달한다. 내결합성에 대해서 고민했었다.
Update 가 아니라 Append 만 할 수 있는 코드 만들기
이 책에서 '복잡성은 감옥이다' 부분에서 재밌는 일화를 이야기한다. 이미 퇴사한 사람에게 코드에 대해서 묻는 에피소드인데, 부끄럽게도 나에게도 이런 경험이 있다. 누군가 짠 코드에 대해서 유지보수를 하는 상황에서 어떤 의도를 갖고 작성했는지 복잡해진 코드에 대해서 알 수 있는 길이 없었다. 당시 Java 로 된 언어로, 라인수가 약 76만라인의 코드였던 것으로 기억한다.
우리가 만드는 소프트웨어는 한번 만들어지면, 만들어진 코드에 대한 수정을 하며 기능구현에 이어간다. 이 때 발생하는 문제점은 기존 코드의 의도를 이해해야하는 것은 물론이고, 앞으로 작성될 코드에 대해서도 이해하고 있어야 하는데, 이것은 복잡도가 높아지는 원인이 된다. 나의 생각을 설명하기 위해 글이 길어지고 있는 것을 보면 복잡해지고 있다는 조짐이 명확하다. 그럼 어떻게 해야될까? 코드를 수정하는 것이 아니라, 코드를 더하는 식으로 프로젝트가 진행되어야 한다. Notifiaction 이 대표적인 프로젝트이다. 메세지 채널이 추가될 때마다, 개발자는 추가될 메세지 채널의 기능 구현만 집중하고, 그 외에는 일체 수정하지 않아도 된다. 이 때 필요한 건 디자인패턴과 객체지향프로그래밍이다.
단순성과 엄격성
Spring 기반의 Backend 를 개발하는 사람이라면 알법한 JPA 라는 구현 기술에 한 때 대해서 끔찍하게 싫어했던 적이 있다. 그 이유가 단순성과 엄격성에 있었다. JPA 라는 도구는 ORM 프레임 워크로 객체와 DB의 특정 컬럼을 쉽게 맵핑할 수 있도록 도와주는 도구이다. 내가 JPA 을 끔찍하게 싫어했던 이유는 JPA가 엄격하지 않아서 발생하는 문제점에 대해서 몸으로 때웠던 적이 있기 때문이다.
JPA 는 유연하게 다양한 맵핑관계를 만들 수 있다. 개발자는 신나게 이 유연함을 가지고 놀다 특정 구간에 막히니까, JPA 을 보조해주는 QueryDSL 이라는 것을 만든다. 점점 더 우연적 복잡성에 더 깊이 빠지고 있다. 사실 이정도 되면 단순하게 Native SQL Query 을 작성하는 편이 편리함에도 불구하고, JPA 에 갇혀서 헤어나오지는 못하는 사람을 더러 봤었다. (심지어 블로그에 JPA 만 검색해도 심각하게 많은 튜트리얼이 나온다. )
단순하다는 건 그만큼 엄격하다는 말에 대해서 납득가능하다. 코드는 엄격해야 한다. 앞에서 말한 JPA 의 단점을 보안해서 등장한 ORM 프레임워크는 DATA-JDBC 이다. 이 도구는 5세 이하가 가지고 노는 장난감이 떠오를 만큼 사용법이 단순하다. 단순함에서 오는 엄격함은 개발자로 하여금 복잡성에 빠지지 않도록 유도한다. 더 복잡한 것을 짤 때는 Native SQL Query 짜도록 유도한다.
--
개발을 인터넷에 있는 내용을 보고 따라 치는 것에 그치지 않아야 한다. 진심으로 심플하다고 부를만큼 코드에 대해서 집착 해야 한다. 이 부분을 이 책에서는 긴 호흡으로 설명하고 있는 것 같다.
'행위 돌아보기 > 독후감상문' 카테고리의 다른 글
소프트웨어 아키텍쳐 - The hard parts (0) | 2023.03.27 |
---|---|
우리 모두는 브랜딩이 될 수 있다 - [오늘부터 나는 브랜드가 되기로 했다] 책을 읽고 (0) | 2023.03.05 |
성장에 대해서 - [개발자 원칙] 책을 읽고. (0) | 2023.01.31 |
[린치핀]책을 읽고 (0) | 2022.12.26 |
[관점을 디자인 하라] 책을 읽고 (0) | 2022.12.04 |
댓글