[우아한 테크코스 4주차] 4(주)차 전직 미션 회고록

khyojun·2022년 11월 22일
1
post-thumbnail

❗ 마지막 전직

1, 2, 3, 4 주차를 거치면서 계속 머리를 쥐어짜 내며 성장이라는 키워드를 생각하며 진행했었다. 마지막 주차 역시 얻은 것이 상당히 많았었다. 그리고 깨달음도 많이 얻었던 한 주차이면서 이번 한 달간 진행했던 제한 없이 코스를 다시 돌아보는 과정이었던 거 같다. 이번 글에서는 4주 차의 내용도 다루긴 하지만 전체적으로 느낀 점도 풀어볼까 한다.

4주차 미션 내용
4주차 미션 PR링크


✔ 이번 미션에서 목표 삼을 것?

다른 주차에서는 여러 가지 목표를 잡았었는데 이번 주차에서는 따로 그렇게 잡지 않고 단 한 가지에 집중하였다. 바로 요구사항이다! 이번 주차에는 다른 때보다 더 구체적이고 세부적인 요구사항들이 있었다. 각각의 클래스마다의 요구사항들이었는데 코수타에서 말씀하여주시길 "이전에 애매모호하게 요구사항을 드리니 혼란이 있던 부분들이 많아서 이번에는 객체를 객체답게 만들 수 있도록 요구사항을 구체적으로 하나하나 드렸습니다!"라고 하셨기에 다른 무엇보다 요구사항 부분에 대해서 신경을 쓰자고 생각했다!


❗ 더 세밀해진 요구사항들

📌 메서드에서는 하나의 기능만!!

  • 함수(또는 메서드)의 길이가 10라인을 넘어가지 않도록 구현한다.
    • 함수(또는 메서드)가 한 가지 일만 잘하도록 구현한다.

이런 요구사항이 있는데 저번 주차에서는 15줄이었다. 그런데 진행하면서 진짜 이 부분 때문에 어떻게든 줄여보고 다른 객체로 떼어내고 쓸데없는 코드들 걸러내고 한다고 신경을 정말 많이 썼던 거 같다. 어떤 분은 커뮤니티에서 "코드의 자유를 억압당한 거 같다!" 라고 하실 정도로 정말 이 부분이 상당히 까다로웠다.

그치만 느낀 점은 그렇게 했지만 완성을 하고 나서 보게 되니 간결하니 일단 보기 좋고 하나에 다 넣지 않다보니 기능별로 메서드들이 구분이 잘 된 거 같다는 생각이 많이 들게 되었다. 그래서 요구사항의 안쪽에 한 가지 일만 잘하도록 구현한다는 말씀을 넣어놓으신 거 같다는 느낌을 많이 받게 되었다.

이때까지는 메서드를 만들면서 그 이름과 관련된 기능들을 다 하나에 넣으려고 했었는데 그런 습관을 깨는게 정말 쉽지 않은 과정이었던 것 같다. 실제로 너무 깊숙히 박혀있어서 계속 빼내려고 하다보니 힘든 과정이었다.😅😅

📌 메서드에게서 짐을 덜어내주기!

메서드의 파라미터 개수는 최대 3개까지만 허용한다.

파라미터를 이때까지는 물론! 클린코드라는 책에서 읽었던 것처럼 최대한 파라미터의 갯수는 줄여갈 수록 좋은 것이라고 했던 것처럼.. 깨끗한 코드를 만들기 위한 과정이었다. 처음 이제 스파게티 코드를 만들어 나갈때는 파라미터 개수가 4개는 그냥 기본적으로 다 들어있었던 거 같다. 그래도 줄여나가기 위해서 신경을 썻다곤 하는데 그래도 어떤 메서드에서는 4개인 코드가 있어서 어떻게 줄여나가야할지 계속 붙잡고 있었다. 그런데 그걸 해결하기 위하여서는 적절하게 클래스 변수도 사용도 해보고 인스턴스 변수에서도 범위 설정도 어떻게 해야할 지 고민도 해보고 하며 어떻게든 3개로 줄여보려고 했었다.

그리고 나중에 줄여나가게 되고 줄여보게 되니 각각의 메서드마다 정말 한 가지 기능만 하는거지 더 이상의 책임을 부여하지 않게 되니 메서드 마다 자유로워지는 느낌을 많이 받았던 거 같다. 이전까지는 어떤 코드의 메서드를 리팩토링 한다고 따졌을때는 그 메서드만 변경하는 것이 아니라 인수가 4,5개가 되버리면 그와 관련된 코드들도 다 변경을 해줘야하는 과정이 필요했었다. 그러나 3개로 줄이고 나니까 적어도 그때보다는 훨씬 덜 종속되어있는 느낌이 많이 들게 되었다. 진짜 메서드에게 짐을 덜어주는 역할을 하는 느낌이 강했다.

📌 지정된 클래스에서의 제약 사항

  • 각 클래스의 제약 사항은 아래 클래스별 세부 설명을 참고한다.
  • 이외 필요한 클래스(또는 객체)와 메서드는 자유롭게 구현할 수 있다.
  • InputView 클래스에서만 camp.nextstep.edu.missionutils.ConsolereadLine() 메서드를 이용해 사용자의 입력을 받을 수 있다.
  • BridgeGame 클래스에서 InputView, OutputView 를 사용하지 않는다.

제약 조건이 붙었다는 것은 진짜 너무나도 까다로운 조건이었다.

BridgeGame 클래스에서 InputView, OutputView 를 사용하지 않는다.

이런 조건처럼 클래스에서의 조건이 걸리는 것이다. 왜냐하면 나중에 구현을 다 하고 리팩토링하고 요구사항에 맞춰서 리팩토링하다 보니 이미 만들어진 곳에서는 Input과 Output을 사용해버린 탓이었다. 이에 따라 초기에 설계한 대로 잘 구성해서 코드를 구현해나가는 것이 얼마나 중요한지 잘 알게 되었다. 그리고 가장 놀라운 것이 이렇게 클래스에서의 제약조건이 까다롭긴 하였지만 실제로 나중에 구현을 완료하면 코치님께서 말씀하셨던 대로 객체답게 객체를 사용할 수 있게 되었다.

그리고 또 생각했어야 했던 것이 이러한 조건 사항에 맞춰나가려면 최대한 기능별로 메소드를 쪼개고 그리고 한 클래스에서 최대한 책임을 지지 않을 수 있도록 여러 개의 역할로 분산시켜줘야만 제약조건을 시킬 수 있었다.

굵은 글씨로 표현한 글에서 갑자기 떠오른 객체지향의 5대 원리라는 것 중 한 가지가 기억이 났었다. SOLID라는 원리 중 S에 해당하는 SRP(Single Responsibility Principle): 단일 책임의 원칙이었다.

SRP: 단일 책임 원칙(single responsibility principle)이란 모든 클래스는 하나의 책임만 가지며, 클래스는 그 책임을 완전히 캡슐화해야 함을 일컫는다. 클래스가 제공하는 모든 기능은 이 책임과 주의 깊게 부합해야 한다.

구현하다 느낀 점이 실제로 SRP의 개념과 비슷하게 겹치는 것이 너무나도 신기했었다. 코수타에서 말씀하셨던 것처럼 이렇게 요구사항을 부여하는 것이 객체답게객체스럽게 만들 수 있게 해주는 역할이었다는 것을 미션을 완료하고 나서 다시 느끼는 것 같았다. 그리고 이것이 얼마나 중요한 원칙인지를 코딩하다가 체화하면서 느껴갔던 거 같았다.

점점 세밀해진 요구사항에 구현하면서 4주 차가 역시 전직하기 가장 힘든 과정이었던 거 같다. 그렇지만 오래된 습관을 버리는 것이 너무나도 어려운 것처럼 기존에 코딩을 해왔던 방식은 잘못 가고 있었다는 것을 많이 느낀다. 그렇기에 머리를 쥐어짜 내면서도 어떻게든 가장 기본적인 요구사항들을 지키기를 위하여서 노력을 가장 많이 했던 거 같다. 요구사항이 느슨했었다면 이렇게까지 하지 않았을 거 같았는데 실제로 이런 부분들에 대해서는 더 살펴보고 연습해보고 코딩하며 체화시켜나가면서 원칙들을 깨달아가는 것이 중요하다는 것을 많이 느끼게 되었다.


📕 4주차 미션의 클래스 다이어그램

이번 과정을 진행하다가 알게 된 설계 과정에 대해서 다이어그램을 그려주는 것을 알게 되었는데 이번 과제를 진행한 것에 대해서 이렇게 클래스를 그리고 보게 되니 요구사항대로 계속 따라가다 보니 이렇게 여러 개의 클래스로 나눠진 게 된 거 같았다. 최대한 각자의 이름에 맞게 할 역할만 딱 하고 빠져나와서 다음 기능들을 실행하도록 설계했었다. 만약 다 한 클래스에 억지로 역할들을 넣었으면 이 다이어그램이 상당히 어지러웠을 거 같다. 어지러우면? 애초에 코드 자체가 책임을 분리를 많이 못 하게 되어있다는 것을 의미한다는 것도 여기서 많이 알고 가게 되는 거 같다. 책임을 잘 분리하여 객체마다의 역할을 잘 부여해야 하겠다는 것을 많이 느낀다.

😂 끝으로

진짜 프리코스 4주 차를 끝내고 뭔가 당장 다음날 코수타 후 미션 메일이 올 거 같은데 오지 않게 된다니 참 아쉽다. 1, 2, 3, 4주 차 벌써 한 달이 이렇게 지나갔던가 한 달 동안 이렇게 열심히 프로그래밍을 연속적으로 열심히 했던 경험은 정말 처음이었던 거 같다. 요즘에 뭔가 많이 듣는 얘기인 거 같은데 몰입하는 경험? 이런 것이 진정 제한 없이 프리코스 과정에서 느꼈던 것이지 않을까? 하는 생각을 되게 많이 한다. 정말 커뮤니티에서도 서로서로 힘내고 도와주려고 하시는 분들도 많고 되게 불안해도 격려해주시면서 성장하는 데 힘 쓰라고 말씀해주시는 코치님들의 응원 덕분에 다들 버티고 이렇게 무사히 끝내지 않았을까 싶다. 물론, 이후에 결과가 어떻게 될지는 모르겠지만 앞으로 이번 경험을 통해 배운 것을 기반으로 삼아서 계속해서 정진해나가는 개발자가 되어야겠다는 것을 참 많이 느끼게 되는 우테코 5기 프리코스였다. 올해 중 가장 보람 있었던 도전이었던 거 같아 너무 만족스러운 경험이었다.


화이팅!

진짜 5기 여러분들 너무 고생하셨고 좋은 말씀해주신 코치님분들 너무 감사드립니다! 프리코스 너무 좋은 시간이었습니다. 이후에도 다들 화이팅입니다!👍

profile
코드를 씹고 뜯고 맛보고 즐기는 것을 지향하는 개발자가 되고 싶습니다

2개의 댓글

comment-user-thumbnail
2022년 11월 22일

잘보고갑니다!
4차전직까지 정말 고생많으셨어요!! ㅋㅋㅋㅋㅋ

1개의 답글