객체, 설계

들어가며

이 글을 오브젝트 내용을 기반하여 제 생각을 작성한 글입니다!

---

지금까지

지금까지 저는 레벨 1,2 에서 객체에 메세지를 보내는 법을 배웠으나, Spring 과 Spring data jpa 를 만나 무너졌어요. 😢
알고 있는 지식과 새로 습득한 지식을 새롭게 가공하는 일은 에너지가 많이 드는데, 그 과정을 세세히 하기에 레벨3는 너무나 바쁘고 치열했습니다. (라고 쓰고 변명이라고 읽는다) 그래서 레벨3는 최초의 기획한 요구사항에 맞춰 동작 가능하게 하기 + 체화 되어 있던 수준만큼만 객체지향적이게 작성하기 를 목표로 설정하고 달려왔어요.

객체, 설계.. 너희 너무 어려워

큰 프로젝트 경험이 없다면, 유지보수하기 좋은 코드를 작성해야하는 이유를 절실히 느끼지 못하는 것 같아요. 마치 체력이 꺽여야만 비타민을 소중히 챙겨 먹듯이요. 😄

 

저또한 그랬어요. 좋은 개발자란, 유지보수하기 좋은 코드를 작성해야하고, 솔리드 원칙을 지켜야하고.. 테스트 코드도 꼼꼼하게 작성해야하고.. 조건들이 많지만, 일단 개발자가 되려면 기능 구현이 우선이지! 라는 마인드가 강했어요. 마감 기한에 치이다보면 유지보수는 뒷 일이고, 우선 동작 가능하게 하자! 라는 마음이 컸던 것 같아요. 그러던 중 문제가 생겼습니다.

 

설계의 중요성

저희 팀은 면담 예약 서비스를 진행하다보니, 면담 시간에 대한 정책이 필요했어요. 현재는 면담 1번 당 30분씩 가능해요. 그래서 최초 면담 신청시 면담시작시간을 받고, 그 시간에 30분을 더해준 값을 면담 종료시간으로 설정해주는 로직이 생겨났어요. 그 로직은 intervieService 에 존재하고 있었고요.

 

어느날 사용자 경험에 대해서 묻다가, 실제로 30분 면담 시간을 잡지만 1시간 정도 면담을 진행하는 코치님도 있다는 것을 알게 되었고, 면담 진행 시간이 변경될 수도 있겠다는 생각에 변경 시나리오를 그려봤는데요. 세상에.. service 에서 면담 진행시간에 대해 다루다보니 30분을 1시간으로 바꾼 것 뿐인데, 테스트가 여기저기 깨지고, 번경점이 여러 클래스에 있는 것을 보고 유지보수하기 어려운 코드를 짜고 있었구나 라는 생각이 들었어요. 또한 이후로도 비슷한 상황을 많이 겪었고, 하나의 기능을 추가하는 것 뿐인데 매번 PR 을 머지한 후 rebase 할 때마다 conflict 가 엄청 나는 것을 보면서도 제가 작성한 코드가 의존성이 단단히 엮여있구나 설계가 잘못되었다 느꼈어요.

 

설계, 이론이 먼저일까, 실무가 먼저일까?

저는 주로 이론을 학습한 뒤 이론을 경험에 녹여내며 이해도를 올리는 학습을 했기 때문에 이론이 먼저라고 생각했어요. 이 생각은 이론이 만들어지기 위해서는 실무에서 이리저리 부딛치며 자주 겪는 문제들을 푸는 방식이 생겨나고 그걸 이론으로 확립한다. 라는 내용을 오브젝트 책에서 접하며 달라졌어요.

 

우테코 첫 걸음마 당시, 다른 크루들이 여기저기 설계에 대한 고민을 하는 모습을 많이 봤어요. 정답도 없는 문제를 가지고 하루를 꼬박 보내는 크루를 보면서 신기했던 경험이 있어요. (지금은 제가 그러고 있네요.ㅎㅎ)

그때 당시는 경험이 없었기 때문에 와닿지 않는 이론에 기대어 설계를 하려다보니 어려웠던 것 같아요. 지금은 프로젝트를 통해서 경험을 쌓고 있으니 이전보다 더 재밌는 고민들이 생겨나고 있네요. 이 글을 읽고 있는 초보 개발자라면 설계 없이 일단 구현해보고 거기서 개선할 점을 찾아가면서 경험을 먼저 쌓아보라고 추천하고 싶어요.

 

소프트웨어 설계를 통해 원하는 것

• 아무래도 첫 번째는 실행중에 제대로 동작하는 것이 될 것 같아요.
• 두 번째는 변경하기 쉬운 코드를 만드는 것.
• 세 번째는 코드를 읽는 사람과 의사소통을 하는 것.

 

이 세가지를 얻고 싶어서 설계에 대해서 고민하고 있어요.

이 중 첫 번째는 비교적 쉬운데, 두 번째, 세 번째가 참 어렵죠? 🤣

 

변경하기 쉬운 코드는 기능을 구현하는데 필요한 최소한의 의존성만 유지하고 불필요한 의존성을 제거하는 것. 그래서 한번에 하나의 클래스만 변경할 수 있는 설계가 되는거죠! 그럴려면 데이터를 가지고 있는 주체가 동작을 하는 주체가 되어야 해요. 책임이 한 객체에만 집중되어 있는 것도 분산 시켜줘야하고요. 책에서는 의존성을 적절히 관리한다고 표현하고 있는데, 적절히가 뭔지는 많은 경험을 쌓아야 찾아갈 수 있을 것 같네요.

 

---

설계에 대한 내 생각.

1. 설계하는 방법은 한가지 이상일 수 있다.

프로젝트를 하면서 패키지 구조에 대한 고민을 한 적이 있어요. 현재 우리 서비스는 작은데 이걸 모듈 패키지로 나누게 되면 오히려 파일을 찾기 어려워 지지 않을까? 라는 생각에 익숙하고 간단하 Mvc 패키지로 시작했죠. 그런데 서비스가 점점 커지다보니, 한 패키지 안에 파일이 10개가 넘게 위치하게 되고, 점점 찾기 어려워지기 시작했어요. 그때 모듈 패키지 전환을 고려해보게 되었죠. 모듈 단위로 패키지를 나누게 되면 고민 거리들이 많이 생겨나요. 의존성을 여러개 맺고 있는 클래스가 있다면 어디에 위치 시켜야할까 ? 패키지간 의존성이 생기는데 이건 어떻게 끊어내야할까. 등등 .. 어떤 설계를 해도 장단점이 있다고 느꼈어요.

 

그때 상황에서 적절했던건 Mvc 구조가 맞았고, 상황이 바뀐 시점에 모듈 구조로 변경을 하는 것 또한 적절하다고 생각해요. 변화에 맞춰서 프로젝트 또한 변해야 살아있는 코드 아닐까요 ? 그래서 설계를 다시 해야할 것 같다고 좌절하지 말고, 더 많은 고민을 할 수 있는 좋은 기회다 . 우리 상황이 바뀌었구나! 하고 생각했으면 좋겠어요. 이런 순간들이 어려우면서도 흥미진진하고 내 코드에 대한 애정을 더욱 크게 만들어주는 것 같아요. 😇

2. 개발자는 의사다.

객체 지향의 사실과 오해라는 책을 보면, 객체를 의인화 해서 마치 살아있는 생명처럼 대해요. 그래서 객체 본인이 자율적으로 행동해야 객체 지향적이다라고 할 수 있어요. 이런 맥락에서 개발자는 객체를 태어나게 하고, 살아가게 하고, 죽이기도 하니 의사가 아닐까 .. 싶네요? ㅋㅋㅋ

정리

설계는 코드를 작성하는 매 순간에 어디에 코드를 배치할 것인지 결정하는 과정에서 나오기 때문에 설계와 구현은 떨어트려서 얘기할 수 없다고 느껴요. 설계가 잘못되었는지는 코드를 작성하지 않고서는 검증할 수 없거든요. 그래서 어떻게 하면 좋은 설계를 할 수 있을까에 대한 방법으로 오늘 완성해야하는 기능을 동작가능하게 하며, 내일 쉽게 변경할 수 있는 코드를 짜자.라고 정의 내려봤어요.

 

앞으로 Object 책과 함께 기존 코드를 변화에 유연한 코드로 만들기를 진행하면서 해당 내용에 대해서 깊이를 채워갈 예정이에요. 읽어주셔서 감사합니다. 😀