[생각정리] 우아한테크코스 2주차 - 노력한다고 알아주지는 않는다

jeyong·2024년 11월 2일
0

공부 / 생각 정리  

목록 보기
119/120

이번 글에서는 우아한테크코스 2주차 미션을 수행하며 느꼈던 점들과 깨달은 부분들을 기록해보려 한다. 앞으로 성장해 나가면서 현재의 나를 되돌아보는 데 도움이 될 수 있도록, 지금의 생각을 솔직하게 적어보려 한다.

1. 미션

이번 주 미션은 자동차 경주 게임을 구현하는 것이었다. 내가 작성한 코드는 java-racingcar-7에서 확인할 수 있다. 저번 회고 글과 마찬가지로 미션의 구체적인 설명은 다른 게시글에도 나와 있으니 생략하고, 회고에만 집중해보겠다.

2. 회고

2-1. 프로그램 구현을 마친 후

지난 회고에서 결심했던, "자신을 뽐내기 위한 코드보다는 본질에 충실한 코드"라는 방향을 이번 미션에서 보여주었다. 레이싱 카 과제에서는 요구사항을 정확히 충족하는 것에 초점을 맞추었고, 기능이 정확히 작동하는지를 최우선으로 생각했다. 이번에는 복잡한 설계보다는 요구사항을 이해하고 충족하는 것이 우선이라고 판단했다. 예외 케이스도 꼼꼼히 살펴봤다.

또한, 구조도도 복잡하지 않게 핵심적인 내용만 담아 표현해보았다.

구조도에서 볼 수 있듯이, 최대한 이해하기 쉽도록 코드를 작성했다. 합리적인 추상화를 시도했고, 모델 간의 책임을 명확히 하여 서로의 역할이 자연스럽게 드러나도록 구성했다.

특히, 이번에는 필요한 유연성만 확보하고 불필요한 추측에 기반한 설계를 피하려고 했다. 자동차의 이동 전략을 결정하는 부분만 유연하게 구성했는데, 이는 경기 구성 시 변경 가능성이 높기 때문이다. 또한, 테스트를 용이하게 하기 위해 이 정도의 유연성은 필요하다고 판단했다.

또한, 커밋 메시지에도 신경을 많이 썼다. 기능 단위로 작성하려고 노력했고, 컨벤션에 맞춰 제목과 본문에 구체적인 내용을 담았다. 이를 통해 커밋 메시지만으로도 변경 사항을 충분히 이해할 수 있도록 구성하려 했다.

2-2. 다른 사람의 코드를 본 후

잘못된 생각일 수는 있겠지만, 나는 코드 리뷰를 많이 받는 코드가 최소한 읽기 좋은 코드임은 보증되었다라고 생각한다. 많은 리뷰 요청 속에서, 리뷰어들은 쉽게 이해할 수 있는 코드에 더 관심을 가지고 피드백을 줄 가능성이 높기 때문이다. 그래서 읽기 좋은 코드를 작성하려고 노력하는 나는 가능한 많은 리뷰를 받고 싶다는 목표가 있다.

이러한 생각속에 이번 미션을 수행한 코드가 나름 개과천선한 코드라고 생각하며, 읽기 좋은 코드 덕분에 코드 리뷰를 많이 받을 수 있을 것이라는 기대도 있었다.

평소 SNS 활동을 거의 하지 않지만, 코드 리뷰를 받으며 생각에 대해 이야기할 수 있는 기회가 별로 없다는 것을 알기 때문에, 이번에는 용기를 내어 코드 리뷰 요청 게시글을 작성해보았다.

제목이 문제였을까? 코드가 문제였을까? 이런 활동은 역시 어렵다 ㅎㅎ..

그래도 포기하지 않고 이번에도 지난 미션처럼 직접 찾아가서 리뷰를 요청했다. 리뷰 내용은 여기에서 확인할 수 있다. 이번에도 다섯 분에게 요청했으나 저번처럼 두 분만 리뷰를 남겨주셨다. 남들이 봐도 이해하기 쉽게 구현했다고 생각헀고, 커밋 메시지에도 신경 썻지만 현실은 냉혹했다. 그래도 한 분이 감사하게도 검증 로직에 대해 나의 생각을 궁금해 하셔서, 기쁜 마음으로 대답을 드렸다.

남이 내 코드에 관심을 가지고 질문을 해주니 즐겁게 대답을 했다. 과한 답장은 아니었나 하는 생각도 들지만, 프로젝트를 진행하며 기술적인 이야기는 많이 해봤어도, 기본기와 관련된 논의, 그리고 정답이 없는 주제에 대해 이야기하는 것은 색다른 재미를 느낄 수 있었다.

리뷰를 작성하면서 내 코드의 잘못된 점도 발견하게 되었다. 뷰는 대체 가능성이 있기 때문에 최소한의 책임만 수행하도록 구현하는 것이 좋다고 생각하여, 변환하는 로직은 모델에서 처리하도록 하였다. 하지만 특수한 상황인 쉼표로 구분하는 기능도 모델에서 처리하도록 하였는데, 이러면 모델이 쉼표라는 특정 구분자에 의존하게 된다. 만약 뷰가 바뀌어 구분자가 쉼표가 아닌 골뱅이로 변경될 경우 모델의 로직을 수정해야 하는 상황이 발생할 수 있다.

그래서 이번 미션부터는 구분자로 분리해주는 로직을 뷰의 책임으로 두었다. 사실, 상식적으로 봐도 뷰에서 최소한의 검증인 공백 검사는 수행하는데, 구분자로 나눈 뒤에 검사를 하는 것이 더 맞는 방식이었다. 이를 간과하고 스스로 점검하지 못했다는 것을 반성했다. 역시 다른 사람의 시각에서 내 코드를 보아야 이런 부분들을 더 잘 발견할 수 있다.

이번 미션에서 나름 여러가지로 노력을 했지만 저번과 비슷한 결과라 실망스러웠다. 그래도 코드 리뷰가 재미있고 많은 도움이 된다는 사실을 직접 느껴보고 좋았다. 다음 미션에서는 더 읽기 좋은 코드를 작성해서 더 많은 코드 리뷰를 받을 수 있도록 노력하겠다. 이를 위해 최소한의 추상화와 모델 간의 책임 분리는 기본으로 하고, 가독성을 높이기 위해 enum을 활용해 보려 한다.

노력한다고 알아주지는 않는다. 하지만 결국 내가 할 수 있는 것은 노력하는 것뿐이다.

profile
노를 젓다 보면 언젠가는 물이 들어오겠지.
post-custom-banner

0개의 댓글