우테코 5기 프리코스에 참여하게 되었다. 선발되지 않더라도, 프리코스 자체만으로도 배울게 많아 보였다. 또한 우테코, 배민의 개발 문화를 알아볼 수 있는 기회같아 기대되었다. :) 1주차 온보딩에서는 7 문제를 풀이하는 과정이었다. 이전까지는 스프링 프레임워크를 사용해서 거의 기본 CRUD만으로 프로젝트를 구현했었다. 그리고 자바 문법/CS/객체지향 개념은 이론적으로만 배웠고, 실제적으로 많이 활용하지는 못했었다. 이번 기회에 좋은 구현, 클린 코드 등을 확실히 배워야겠다고 생각했다.

프리코스 과제 받기 전 코수타 타임에서 좋은 개발 능력에 대한 이야기(구현, 클린코드 등)를 들었다. 그래서 첫 주차에서는 구현에 품을 많이 들이기로 했다. 이론적으로만 배웠던 객체 지향 4 특징, SOLID 5원칙, 디자인 패턴 등등을 최대한 활용해보고자 했다. 온보딩 1주차는 비교적 단순한 문제라고 볼 수 있지만, 후에 확장성을 고려해보면서 구현에 신경쓰며 진행해보고 싶었다. 사실 1주차는 몸풀기..?이지 않을 까 싶어서 공부하기 위해 여러 시도를 해봤던 것 같다.

다음은 1주차에서 가장 신경 쓴 점들이다.

✔ 고려 사항

• 구현 사항 이해 후 기능 목록 작성하기
• 한 메소드에 하나의 기능만 구현하기, 메소드 분리
• 변수명/메소드명 다른 사람에게 이해가 쉽도록 짓기
• 다형성을 위해서 추상화, 상속 활용하기

🤔 구현하면서 고민 사항 + 공통 피드백 후 배운 내용

확장성/유지보수

개인적으로 가장 시도해보고 싶었던 부분이 확장성/유지보수를 위해 추상화/상속 활용하는 것이었다. 그래서 이번에 쉬운 문제들이더라도 추상화와 상속을 활용해보고자 했다. 다만, 이번 문제에서는 약간의 오버프로그래밍이 되지 않았나 싶기도 하다. 다음 주차부터는 흐름이 너무 길어지지는 깨지는 않도록 적정 범위를 지키면서 구현 범위를 정해야 될 것 같다. 유지보수를 위해 추상화/상속을 사용했는데, 오히려 너무 흐름이 길면 다른 사람이 이해하는 데 오래 걸릴 수 있을 것 같다는 생각이 든다.

메소드 분리 / 커밋 단위

메소드 분리 단위가 고민이었다. 우선 하나의 메소드에 최소 기능만 구현하기로 했다. 근데 그러다보면 메소드가 너무 많아지는데, 이 적정선을 찾아가는 게 중요할 듯 싶다. 일단 첫 주차에는 최대한 작게 분리하여 구현했다. 그리고 작은 메소드라도 하나씩 커밋을 했었는데, 전체 피드백 시간에 들어보니 작은 메소드들은 묶어서 한번에 커밋해도 좋을 듯하다.

커밋 메세지

커밋 메세지도 PR 이후 아고라를 통해 참고해보니, scope나 이슈를 남겨 놓는 게 좋을 것 같다. 확실히 다른 분들의 커밋 내역을 봐도 scope나 이슈가 함께 나와있는 게 가독성이 좋게 느껴진다. 그리고 커밋할때 중요한 기능 먼저 커밋하는 게 좋을 것 같다. 탑다운 방식으로..! 사실 실제 구현은 탑다운으로 했어도, 자잘한 기능 먼저 커밋한 문제도 있었는데 이부분은 확실히 중요한 기능 먼저 커밋해야겠다. 내 예전 커밋이나, 다른 분들의 커밋 메세지를 계속 읽어보니 어떤 게 더 가독성 있고, 이해하기 쉬운 지 약간 기준을 잡아가는 것 같다. 오히려 정답을 한번에 보는 것보다, 뭐가 잘 안읽히네, 잘읽히네를 찾아가면서 배우니까 더 와닿는 느낌이다 😅

다음은 각 문제에 대한 회고이다. 회고록 쓰는 과정에서 코드를 다시 보고, 다른 분들 아고라/PR도 참고하고, 구글링하면서 배우는 게 더 많은 것 같다.

1번 : 페이지 펼쳐 승부

덧셈/곱셈 연산이 실제 +, * 하는 과정 뺴고, 두 배열을 더하는 과정 등이 공통적인 기능들을 많아 상속을 활용하고자 했다. 그래서 Calc 인터페이스에 공통 메소드는 default 메소드로 구현하고, 실제 연산하는 메소드는 각각 Sum , Multiply 클래스에서 각자에 맞게 구현했다.

3번 : 369 게임

3,6,9 문자를 제거해서 3/6/9 갯수를 카운트하는 방식으로 구현했는데, 지금 생각해보면 Stream을 사용하는 게 더 효율적일 것 같다. 그때는 컬렉션 객체를 사용하지 않고 간단하게 (?) 구현하려고 했던 것 같은데 오히려 메소드명이 기능과 정확하게 매치되지 않아 모호해진 것 같다! 그리고 컬렉션을 사용하는 게 원래 코드보다 성능적으로도 떨어지나 한번 알아봐야 겠다!! 다음에는 컬렉션 객체들을 적극 활용하고, 메소드명과 기능이 정확하게 일치하도록 구현해야 겠다. 그리고 이 당시에는 메소드 분리에만 신경 써서 문제를 못 느꼈는데, 회고록 쓰면서 다시 보니 아쉬운 점이 너무 명확히 보였다..ㅠ 아쉬운 김에 다음에는 컬렉션 사용을 확실히 하도록 복습해야 겠다. ㅎㅎ

4번 : 청개구리 문자 해독

이 문제 또한 추상화/상속을 활용했다. 대문자일 경우와 소문자일 경우로 나눠서 입력 받고, 결과 계산해야되서 각각의 클래스가 필요했고, 인터페이스에 이들의 공통 메소드인 isTrue 와 translate 를 추상 메소드로 정의해 두었다.

7번 : SNS 아는 친구

자료구조를 많이 사용하여 인자로 많이 보내게되서 static 변수로 선언했다. 지금 생각해보니, 한 클래스에 너무 많은 메소드가 담겨있는 것 같다. 기능별로 클래스를 분리해도 좋았을 것 같다.

이론 공부하면서도 문법/이론 지식들이 따로 노는 느낌이라 이게 맞나 싶기도 했고, 개발 공부에 있어 방향성을 잘 잡지 못했던 것 같다. 근데 구현을 실제 해보면서 배우니까 그 방향성이 좀 잡히는 것 같다. 오버 프로그래밍, 불분명한 메소드명, 문서화 등 처음에는 잘못하면서 오히려 더 배울 수 있는 것 같다. 일단 다시 볼때는 다른 사람 코드 읽는 느낌인데 너무 흐름이 길고, 메소드명이 이해가 잘 안된다던지 등등.. 이런 과정에서 배우는 게 많은 것 같다. 1주차 회고록을 2주차 구현 마친 후 작성하고 있는데, 그래서인지 아쉬운 점들이 많이 보인다. 1주차라 아쉬운 점들이 많이 느껴지기도 하지만, 그래도 배운 게 정말 많은 한 주였다. 그리고 생각할 거리가 많아 단순 CRUD 보다 확실히 재미있었다. 다음 주차에는 이번에 아쉬운 점을 개선하고 ✨클린 코드에 집중하며 구현해야 겠다. 🤓