이것 뭐에요? 열심히 했던 프로젝트를 반년이 지난 후에 읽으니 나조차 읽을 수 없었다..!!
당시에는 좋은 코드라고 생각했던 구조가 지금 보니 단점이 보였고 그렇게 깨달은 점에 대해서 적고자 한다~! ^_^
문제상황 ps. 우리 그때 로그인 과정이 어떻게 되었죠?
같이 했던 팀원님이 카카오 로그인 흐름을 물어봤는데, 당시 제 프로젝트가 소셜로그인을 한 후, 서비스 이용을 위해서는 추가 닉네임 + 회원 유형을 입력하도록 했습니다.
따라서 유저 상태가 소설로그인만 완료한 상태와 소셜로그인을 완료하고, 추가적인 정보까지 등록한 완전한 상태로 나뉘는 거죠!
이 과정은 기억이 나는데 어디서 저 유저의 상태값을 검사하고, 업데이트하는지를 전혀전혀 전혀! 찾을 수 없었습니다.
PR을 열어봐도 찾기가 어려웠음당시 진행했던 프로젝트
카카오 부트 캠프 3단계에서 전세 사기 관련 종합 서비스를 기획하고 개발했다.
당시 프론트 3명, 백 4명이었고, 나는 백엔드 개발자로 백엔드 팀장을 맡았었다.
객체 어떻게 만들거에요??
객체를 만드는 방식에는 여러개가 있고, 우리 팀도 이를 고민했었다.
4명 모두 생각이 달랐고, 통일하는 것에도 필수다, 선택이다 논의했던것 같다. 당시 프로젝트를 봐주시던 멘토님께도 의견을 물어봤었다.
- 서비스 코드 중간에서 직접 빌더를 사용한다.
- 원 객체에 스태틱 메서드로 변환 매서드를 둔다.
- 요청 객체를 매개변수로 받는 생성자를 둔다
- 별도의 팩토리 클래스를 둔다.
4가지 방법에 대해 실제 코드를 확인하고 싶으시다면!!
관련해 팀원과 토의한 내용을 정리한 깃허브 문서
멘토님의 조언
- 통일이 필수 🔄. 1번을 제외한 어떠한 방식을 사용해도 괜찮음.
- 멘토님은 별도의 Mapper 클래스를 만들어 변환 로직을 관리하는 것을 가장 선호한다고 하셨지만, 1번을 제외한 어떠한 방식을 사용해도 괜찮다고 하셨다. (4번과 유사)
결국 요청 객체 + 생성자를 선택했다!
계속 이야기가 길어져서 투표를 통해 요청 객체 + 생성자 를 사용하기로 결정했다.
@Entity
public class User {
public User(JoinRequest joinRequest) {
this.name = joinRequest.name();
this.email = joinRequest.email();
}
}왜 그렇게 선택했을까요? ps. 메서드를 신뢰한다
당시에는 깊게 생각하지 않았지만, 내가 팀장을 맡고 있었고,
내가 3번 전략을 희망해서 3번을 하게 된 이유도 있었던 것 같다..
(팀원들 미아내 🙏)당시 내 판단의 이유는 이렇다.
1. 객체의 상태를 조절하고, 책임지는 주체가 생성자를 호출할 외부클라이언트가 아닌 객체가 되길 바랬다.
2. 따라서, 유저의 상태를 파악하고, 역할ROLE을 지정하는 주체는 서비스 코드가 아니라 객체라고 생각했다.
3. 또한 이렇게 둬야지, 메서드 내부 흐름을 외부에서 신경쓰지 않아도 되는 신뢰도 있는 메서드를 구축했다고 생각했다.
당시 나는 믿고 맡기는 코드, 호출하는 메소드가 알아서 다 해주겠지! 믿고맡긴다! 너가 알아서 해~? 스타일을 선호했다.
반년이 지난 지금은요...
질문을 받았을 떄는 나조차 답변하고, 해당 위치를 찾기 너무 어려웠다.
그렇지만 결국 찾아서 답변을 해주긴했다 😰
그런 과정에서 내 문제점 두가지를 찾았다.프로젝트의 코드를 모두 알 수 있을까?
개발 당시에는 팀장이여서 pr을 확인하고 머지하면서 대부분의 코드를 읽고 이해하고 있었다.
하지만 시간이 지나니 코드의 정확한 위치나 역할이 기억나지 않았다.
다른 팀원들은 모든 코드를 이해하고 있었을까??
그리고 모든 코드를 이해하는 것이 생산성측면에서 과연 도움이 되는 것일까?
나는 아니라고 생각한다.
이미 시작한 프로젝트에 합류할 수 있는 것이고, 프로젝트 크기가 점점 커지면, 모든 코드를 알 수 없을 것이다.
또한 내가 다 알고 있으니 팀원 또한 그럴 것이다라고 생각하는 것은 팀원들에게 부담을 주고, 팀 전체의 생산성 저하로 이어질 것이다.
그리고 역시 개발자의 역할은 마감기한 내 구현이지 코드 프로잭트 코드 모두 읽기는 아니니까! 생성자에는 어떤 의미도 포함 시킬 수 없다.
setName() 메서드보다는 updateName() 매서드가 좋다는 것에는 대부분의 개발자들이 동의할 것이라고 생각한다.
메서드 명으로만 이 메서드의 역할과 결과를 유추할 수 있기 때문이다.
나또한 이렇게 생생한 메서드명으로 호출하는 개발자에게 메서드의 정보를 주고, 믿고 사용할 수 있도록 하는 구조를 선호했던 것이다.
그러나 생성자 + 매개변수 조합으로만 메서드의 역할,결과를 믿는 것은 너무 도박이다!!
오히려 감추려고 했던 의도가 반대로 작용해 이 생성자가 어디까지 담당해야하는지 매번확인하게 만든다.
결국 이것또한 생산성 저하다. 💦
추가로, 한 메소드가 완벽한 역할을 한다는 건 그만큼 유연하지 못하다는 뜻?!
어떤 메서드가 너무 완벽한, 딱딱한 역할을 가지게 된다는 것은 그만큼 유연하지 못하다는 뜻인 것 같다.
굳이 따지자면 내 코드에서는 생성자 내부에 1. 객체 생성 / 2.상태 확인 후 적절한 멤버 역할 부여 두가지의 역할이 유연하지 못하게 담겨 있었고, 한 메서드가 하나의 책임만 가져야한다는 규칙을 위배했다고도 생각한다.
과거로 돌아간다면...?
생성자 + 매개변수 전략을 유지한다면, 멤버롤을 업데이트 하는 메서드를 따로 두어 유연성을 높이고 메서드역할을 분리할 것이다.
아예 전략을 바꾼다면 스태틱메서드로 이 메서드가 어떤 유저를 만드는지 명시하고 내부에 생성자를 두는 방식을 선택할 것 같다.
지금으로서는 이런 생각이지만, 앞으로 더 많은 경험을 통해서 더 좋은 정답에 도달할 것이라고 생각하고 또 좋은 생각이 든다면 추가로 적어놓겠다
이 회고를 통해서 내가 느낀점은... ! ^_^ 👍
결국 시간이 지나고서야 내 코드의 문제점을 확인 할 수 있었다.
1. 프로젝트의 코드를 모두 알 수 없다는 점
2. 메서드에 의도와 결과를 표현하고 싶으면 메서드명으로 표현해야한다. ps. 짐작은 서로 피곤해지는 것
3. 어떤 단위로 메서드의 역할을 결정해야하는가.
또한 팀원들과 함께 우려되는 점과 의견을 더 들었다면 위 문제점을 토의중에서 발견할 수 있었지 않았을까??라는 생각도 들었다.
내가 너무 내 생각을 밀어 붙였나라는 생각도 조금은 했다.
또 나는 경력이 절대적으로 부족하니까 그만큼 늘 내 코드의 문제점과 부작용을 고민해봐야겠다는 생각을 했고,
가장 크게 깨달은 것은 시간이 지나고 다시 내 코드를 읽는 건 정말 큰 공부가 된다는 사실이다.
역시 회고는 귀찮은 것이지만 ..^^ 이만큼 가성비 있는 깨달음도 없다는 걸 다시 생각해보며.. 오늘의 회고를 마치겠다..!!
찐 찐 찐 마무리에용
마지막으로 나에게 물어봐줘서 회고의 기회를 준 우리 팀원과 나와 함께 열심히 개발했던 팀원들 모두에게 이 깨달음의 영광을 돌림니다.. ^_^