[회고] 6개월 차 개발자의 리팩토링 대작전

회고 항목은 퍼블리 아티클을 참고로 작성했습니다.

https://publy.co/content/5873?s=ywuezy

아직도 1분기 회고 안 했어? 회고 습관을 키워주는 노션 템플릿

목차

1. 내가 한 것과 잘한 것
2. 배운 것과 성장 지점
3. 아쉬운 것과 다음에 다시 시도해볼 수 있는 것
4. 미래의 나에게

---

1. 내가 한 것과 잘한 것

1) 레거시 코드 리팩토링

기존 코드들은 A 상태에 진입되면 그에 따라 버튼 상태, 메세지 상태 등을 로직을 따라가면서 바꿔줘야 했다.
이에 따라 하나의 클래스에 너무 많은 기능(하나의 클래스에서 상태 바뀌는 것도 알려줘야 하고, 버튼, 메세지등등 사용자가 필요한 것들도 변경해줘야 한다.)이 들어가게 된다. 또한, 추가 기능이 생기게 된다면 이에 따라 연관된 상태들을 찾아가면서 변경해야 했다. 이번 프로젝트의 가장 큰 목표는 바로 레거시 코드를 리팩토링하는 것으로 정했다.

2) 자바스크립트 클래스 정의

먼저 각각의 상태에 진입되었을 때 내가 정의한 클래스에서 어떠한 행위를 해야 하는지 정리했다.
예를 들어 "전화연결 성공"이라는 상태에 진입되면, "전화 끊기" 버튼이 활성화되고, "통화연결에 성공하였습니다."와 같은 문구로 변경되는 것처럼 말이다.

먼저 클래스 다이어그램으로 내가 필요한 상태들을 디파인 하였다.
divide and conquer > 최대한 잘게 디파인 하고, 공통적인 행위를 하는 클래스들은 다시 하나로 합쳤다.

클래스 다이어그램을 토대로 상태 다이어그램과 이벤트 다이어그램으로 정의했다.

상태 다이어그램은 A 클래스에서 B 클래스로 상태가 바뀔 때 구체적으로 어떠한 데이터가 변경되는지 정의했다.
이벤트 다이어그램은 특정 행위를 했을 때 (버튼 클릭, 전화 끊음 등과 같은 행위)를 했을 때 어떤 클래스로 변경되는지를 정의했다.

공통적으로 사용해야 하는 메서드에 대해서는 부모 클래스에 정의하였고, 자식 클래스에서는 super. 키워드로 부모 클래스에 정의된 메소드에 접근했다. 자식 클래스 내부에 정의된 메서드를 호출할 때는 this. 키워드로 접근하였다.

콜 상태 등과 같은 전역적으로 사용되는 데이터는 하나의 클래스로 정의했고, 전역 객체의 멤버 변수는 해당하는 클래스에서만 변경되도록 하였다. (바깥에서 직접적으로 해당 멤버 변수의 데이터를 변경하지 못하도록 막았다.)

참고 자료

클래스
https://ko.javascript.info/class

클래스와 기본 문법

상속

[JS] 객체지향 자바스크립트 -상속과 프로토타입

getter / setter 메서드
https://axce.tistory.com/59

#14. 자바스크립트(javascript) - getter 와 setter

3) ENUM 사용

각각 상태에 따라 변경되는 데이터들을 ENUM으로 정의했다. 전역 객체의 멤버 변수는 모두 ENUM을 통해서만 변경할 수 있도록 했다. 공통적으로 사용되는 메시지 (통화 중입니다. 통화가 종료되었습니다. 등)는 동일한데 ENUM형 식이 아닌 해당 문자열을 직접 입력한다면 공통적이지 않은 메시지를 세팅할 수 있기 때문이다. 그리고 해당 문구가 변경된다면..? 위 경우 해당 문자열을 따라가면서 직접 변경해야 하지만, ENUM의 경우 해당 정의된 부분 딱 한 곳만 문구를 변경하면 ENUM을 사용한 데이터 전체가 변경된다.

2. 배운 것과 성장 지점

처음에 리팩터링이라는 과업이 주어졌을 때.. 정말 막막했다. 미천한 내가 감히... 이런 걸 할 수 있을까(?)라는 생각도 했고,
포기하고 싶지 않은 마음과 잘 해내고 싶은 욕심 때문에 심적으로 너무 힘들었던 날들의 연속이었다. 그럼에도 했다.
울면서 했다는 말이 맞을 정도로.. 정말 이해가 안 가지만 어떻게든 이해하기 위해서 애를 썼다.
사수님한테 끈질기게 물어보고, 많이 혼나고(..?) 그럼에도 불구하고 다시 물어봤다. 그렇게 조금씩 조금씩 성장했다.
그 당시에는 이해가지 않는 일들도 지나고 보면 아 ... 이래서 이걸 썼구나.. 싶은 순간이 오는 것 같다.

물론, 지금도 100% 완벽하게 이해했다!라고 말할 수는 없지만 그래도 쬐....끔 맛은 본 것 같다.

내가 정의한 클래스가 각각 기능에 맞게 동작하고, 기존의 기나긴 코드가 딱 한 줄로 짧아질 때의 희열은 온전하게 나만 느낄 수 있는 소중한 순간이다. 물론, 그 과정은 너무너무 힘들었다. 그럼에도 불구하고 나는 그 시간들을 버텼고, 덕분에 그 짜릿한 순간을 느낄 수 있었다는 생각이 든다.

3. 아쉬운 것과 다음에 다시 시도해볼 수 있는 것

원래는 State 패턴까지 적용하려고 했으나 적용하지 못하였다. 다음에는 디자인 패턴을 적용해서 좀 더 완성도 있는 설계를 해보고 싶다.

아래 표는 프로젝트 마감 회고로
프로젝트를 마감하며 잘한 점과 아쉬웠던 점, 보완할 점을 정리하였다.

4. 미래의 나에게

나를 조금 더 믿고, 너무 고통스러워하지 않으며 재미있게 오래오래 개발했으면 좋겠다.

---

(2022.06.19 추가)

지난 화요일, 드디어 서비스가 사용자에게 오픈 되었다.
일주일 동안 모니터링했는데 아직까지 특이사항 없으니 이번 프로젝트 오픈은 대성공이라고 하자 😊
이번 프로젝트는 정말 정말 창작의 고통이라고 해도 좋을 정도로 마음고생을 많이 했었는데,
지금 돌아보면 그 기간은 절망의 골짜기였던 것 같다.
(* 절망의 골짜기란.. 성장하기 직전에 폭발적으로 절망하는 구간..^^..ㅎㅎ)
아무튼 나는 절망의 골짜기를 잘 지나왔고, 이때를 기점으로 많이 성장했다는 게 스스로도 느껴졌다.