[우테코/BE/7기] Weekly Rewind - 2주차

0. 시작하기 앞서

 

A) 주차별 풀이목표

이번 주차는 저번주차와 마찬가지로 문제에서 요구하는 바가 적다고 느꼈습니다.

또한 시험기간이 겹처 사용할 수 있는 시간이 많이 없었고, 이에 따라 저번주차에서 아쉬웠던 '객체 관점에서의 문제풀이'를  해결하는 연습을 해보자는 목표를 세웠습니다.

이와 함께 테스트케이스에 '단위테스트'를 추가하는 것을 목표로 하기로 했습니다.

 

1. 문제를 객체지향적 관점에서 분석하여 풀이하기
2. 단위테스트 적용하기

 

1. 프로젝트 정리

 

🔎 문제분석

 

문제에서는 저번주차와 마찬가지로 복잡한 요구사항을 요청하지 않았습니다.

다만 문제풀이 조건 상에서 depth 제한이 추가된 점이 있었는데, 관련 내용은 문제를 풀이함에 있어 적용하는 사항으로 판단, 요구사항 분석에 반영하지는 않았습니다.

 

 

 

🚪 문제접근 & 풀이

 

초반에 문제풀이를 위해 접근한 코드는 1주차와 마찬가지로 절차지향적 관점에서 설계된 코드들의 연속이었습니다.

이로 인해 코드들 내의 상호 간 객체의 의미가 퇴색되고, 코드의 재활용이 어려워지는 문제가 발생하였습니다.

 

저는 초기에 설정했던 본 주차의 목표를 다시 생각해보고 목표에 도전하기 위해 아래와 같은 과정을 거치며 코드 리팩토링을 진행하였습니다.

 

객체지향적 관점에서의 문제해결연습

이번주차의 목적달성을 위해, 저는 문제에서의 주요 관심사를 확인하여 이를 '객체'로서의 표현으로 나타내는 과정을 거쳤습니다.

 

이번주차 과제의 경우, 각 자동차 간 경주를 진행하여 '진행상태'와 '우승자'에 대한 정보를 알아내는 것을 목표로 합니다.

이 두개의 정보를 저는 문제의 주요 관심사로 판단했고, 이들을 담을 수 있는 객체를 '경기'라고 명명할 수 있을 것이라 판단하였습니다.

 

따라서 '경기' 객체를 생성하고 다음과 같이 진행상태와 우승자에 대한 정보를 가져올 수 있도록 객체를 설계하였습니다.

 

Q. Race 객체가 service 패키지에 있는데, 이유는?

 

위에서 언급한 바와 같이, 기존 절차지향적 풀이로 인해 산재되어있던 코드를 Race라는 객체를 중심으로 한 리팩토링 과정이 진행되었습니다.

이 과정에서 다수의 비즈니스 로직이 Race 내로 포함되게 되었고, 이로 인해 Race 내의 메서드 중요도 상승 및 복잡성이 증가하는 문제가 발생하였습니다.

 

개발당시, 저는 로직 상에서 본 객체를 domain으로 분리하기 위해서는 객체지향적 관점에서 완벽히 특정 대상을 '표현'한 객체를 담아야 한다는 아키텍처 설계규칙을 설정/적용하였습니다.

Race 객체가 경주를 '표현'하는 성격보다는 프로그램 전반적으로 흐름을 '제어'한다는 느낌을 강하게 받았고, 따라서 이를 'service'와 'controller' 중 하나로 보기로 하였습니다.

이 둘중 객체 및 메서드의 명명성격 상 'service'에 가깝다고 판단, service 객체로 분류하였습니다.

 

만약 시간적 여유와 코드를 고민해볼 수 있는 기회가 더 있었더라면

Race 객체의 전반적 흐름은 'controller'로,

주요 제어로직은 블록화하여 'service'로,

경주에 대해 표현된 로직은 'domain'에 'Race' 객체로 분리하는 시도를 했을 것 같습니다.

 

🏗️ 문제구현

프로젝트 아키텍처

직전주차보다 요구사항이 많고 구현의 관점에서 로직흐름을 관리하는 별도 관리객체의 필요성을 느껴

MVC패턴에 조금 더 가까운 아키텍처를 차용했습니다.

 

• racingcar.constant: 프로젝트 내에서 사용되는 상수와 에러메세지를 관리하는 Class 패키지
• racingcar.domain: 요구사항에 따라 문제를 나타내는 주요대상이 표현되는 객체를 관리하는 Class 패키지
• racingcar.dto: 각 패키지 간 데이터 이동을 위해 사용되는 Class 패키지
• racingcar.io: 콘솔을 통한 입출력 제어를 전담하는 Class 패키지
• racingcar.service: 프로젝트 로직의 전반적인 흐름을 담당하는 Class 패키지
• racingcar.validation: 입출력 및 메서드 내 로직처리 간 필요한 형식 준수여부를 확인하는 Class 패키지

 

문제해결방식

문제의 요구사항은 racingcar.service에서 racingcar.io로부터 차량 이름목록을 DTO 객체를 통해 전달받아 Car 객체를 생성 후,

Car 객체 내에 구현된 run() 메서드를 통해 랜덤하게 움직인 후 그 움직인 결과를 가져오는 방식으로 구현했습니다.

 

이에 더해 이번 주차부터 테스트케이스를 설계/적용하는 과정을 추가하였습니다.

Validation과 io처리에 대한 테스트를 진행하고자 하였으나, 시간부족으로 인해 Validation 테스트는 처리하지 못했습니다.

 

구현코드는 여기에서 확인하실 수 있습니다.

 

Q. 랜덤판단을 Car객체 안으로 넣어버렸는데, 그 이유는? 테스트가 힘들어지지 않나?

 

처음 Car 객체를 설계하며 고민했던 항목 중 하나는 '캡슐화'입니다.

객체지향설계의 특징들 중 하나인 이 특성을 고려하기 위해, run() 메서드를 설계하는 과정에서 랜덤판단로직의 분리여부를 고민했습니다.

 

설계당시 저는 랜덤에 대한 판단여부가 외부에서 결정될 수 있도록 한다면 외부의 영향을 통해 값이 조작될 수 있음을 우려했습니다.

Car 객체를 구현함에 있어, 저는 자동차를 '스스로 움직이는 대상'으로 보았고, 이에 따라 외부요인으로 인해 이 판단여부가 결정되어서는 안된다고 판단하였으며, 이에 따라 판단여부를 보호하기 위해 run() 메서드 안에 판단로직을 포함시켜 외부주입을 막았습니다.

후술하겠지만, 이후 이 판단이 잘못된 판단이었음을 자각하였습니다 (회고에서 자세히 다루겠습니다.)

 

2. 프로젝트 회고

🙋🏻 구현코드의 이해난이도

1주차에서 아쉬웠던 객체지향적 설계의 아쉬움을 위와 같은 과정을 거치며 극복하였으며,

주어진 코드 및 요구사항 명세를 명확하게 확인하는 과정을 통해 빠르고 정확한 코드를 작성해낼 수 있었습니다.

이는 구현되는 코드에서 존재할 수 있는 중복되는 보일러 플레이트 코드를 최소화해주었으며,

이를 통해 작은 기능단위로 분리된 메서드 설계를 만들어내는 것이 가능해졌습니다.

 

이와 함께 문제에서 요구하는 명세사항이 많지 않았기 때문에 코드의 길이가 비교적 길지 않았고, 이에 따라 구현 코드의 이해가 쉽게 가능했습니다.

 

😅 아쉬웠던 점

 

A) 오래 투자하지 못한 시간

1주차와 마찬가지로 중간고사 시험기간과 겹치는 문제로 인해 거의 하루정도만 온전히 몰입할 수 있었습니다.

이미 프리코스 시작 전부터 예상했던 문제였지만, 생각하는 시간이 길어질 수록 결과물의 완성도가 높아짐을 알고 있기에 그 아쉬움이 더 컸습니다.

가능한 최대의 시간을 온전히 할애하는 경험을 이번 프리코스 기간 중 삼고자 하는 목표로 설정하여 4주 중 남은 주차만이라도 몰입하는 경험을 할 수 있도록 노력해야할 것 같습니다.

 

B) 메서드/변수명의 불명확성

이번주차부터는 함께 7기 테크코스를 준비하는 아주대학교 학우들과 함께 스터디를 구성하여 서로의 코드를 리뷰하는 시간을 가졌습니다.

코드리뷰 과정에서, 각 메서드와 변수의 이름이 한번에 이해할 수 있도록 와닿지 않는다는 것을 알게되었고, 이를 통해 이름선정에 신중하지 못했던 과거의 모습에 아쉬움을 느꼈습니다.

 

C) 지켜지지 못한 코딩 컨벤션

1주차 리뷰에서 언급된 코딩 컨벤션과 관련된 리뷰사항을 이번 주차에서 작성한 코드에서 온전히 표현해내지 못했습니다.

FE개발을 하던 과거 습관들이 BE개발까지 그대로 이어지며 코드에 묻어났고,

스터디를 진행하는 과정에서 이런 문제점을 직접적으로 인식할 수 있었습니다.

1주차 리뷰를 다시 한번 읽어보며 습관화 해야할 것 같습니다.

 

D) 구현체에 대한 이해부족

HashMap은 key-value 형태로 데이터를 저장할 수 있도록 해주는 java.util 내 Map 구현체로, 입력된 값들에 대한 입력순서를 보장하지 않고 데이터를 함께 제공되 key를 기반으로 저장합니다.

이에 대해 우테코 시작 전 약 1달간 공부했으나, 막상 사용할 때 공부했던 내용을 사용환경에 따라 명확히 판단하지 못하고 적용했습니다.

특히 Race 객체에서 participant를 저장할 때 데이터를 입력받아 HashMap에 저장하는데, 이로 인해 만약 key의 ascii코드가 더 작은값이 나중에 입력되는 경우 먼저 출력되는 버그가 발생하게 되었습니다.

 

이 문제는 스터디에서 코드리뷰를 하는 과정에서 알게 되었는데,

이를 통해 테스트코드의 중요성 및 필요성과 스터디를 통해 얻을 수 있는 다양한 장점들의 필요성에 대해 알 수 있었습니다.

 

🤔 오랫동안 고민했던 부분

 

아무래도 이번주차의 주요목표로 설정했던 '코드의 객체지향적 설계'인 것 같습니다. 이를 위해 문제를 분석하는 과정에서부터 '객체지향'이라는 개념을 고려하며 문제를 보는 기회가 되었고, 이를 통해 저만의 객체지향적 코드설계 방법을 수립하게 되는 계기가 되었습니다. 관련된 글은 별도 포스팅을 통해 정리하도록 하겠습니다.

 

💡 새롭게 배운 점

 

A) 객체지향적 설계의 중요성

객체지향적인 설계를 통해 도메인과 비즈니스로직을 분리해 설계하는 연습을 할 수 있었습니다. domain을 중심으로 표현되는 기능들과 이를 개발명세에 맞춰 실행하는 비즈니스 로직들의 필요성에 대한 분리관리의 필요성을 느낄 수 있었으며, 잘 정리된 코드를 작성하는 가장 쉬운방법이라는 것을 배웠습니다.

 

B) 작명의 중요성

작명 또한 코드를 쉽게 읽을 수 있는 방법이 될 수 있다는 것을 알 수 있었습니다.

스터디에서 진행했던 코드리뷰 과정은 제게 메서드명을 통해 해당 메서드가 처리하는 일을 나타냄으로서 JavaDoc의 작성필요성을 줄이고, 변수명/상수명을 통해 해당 값이 나타내는 바를 명시적으로 전달함으로서 코드의 맥락을 보다 빠르게 파악할 수 있음을 느낄 수 있었습니다.

 

C) 테스트 코드의 중요성

테스트케이스를 통해 단순히 기능을 '테스트'하는 것 뿐만 아니라 해야할 일을 명시적으로 나타내는 것 또한 가능하다는 것을 알 수 있었습니다.

미리 계획된 기능들을 적어두고, 그 기능을 명확하게 수행할 수 있는 다양한 방법들을 구현하여 한번에 완벽한 설계여부를 확인할 수 있는 테스트코드는 단순한 테스트의 역할을 넘어 개발자가 해야하는 기능구현업무의 to-do list로서 사용될 수 있음을 느꼈습니다.

이를 통해 테스트코드를 잘 설계하는 방법에 대한 고민을 해볼 수 있었으며, 그 과정에서 저만의 테스트코드 설계원칙을 수립할 수 있었습니다.

해당내용은 별도의 포스트를 통해 다루도록 하겠습니다.

 

---

 

3. 2주차 총평

 

개인총평

규칙의 중요성

 

이번주차 프리코스는 제게 규칙읮 중요성을 다시 한번 일깨워주는 기회가 되었던 것 같습니다.

변수/상수/메서드의 이름과 코드 속 숨어있던 저의 코딩스타일을 통해 비춰진 저만의 코드 규칙은

같은 구현이라 하더라도 개발자가 이해하기 편한코드가 될 수도, 이해와 수정이 어려운 코드가 될 수도 있다는 것을 느꼈습니다.

회사별, 프로젝트 별 컨벤션을 설정하는 이유와 그 효용에 대해 다시 한번 생각해볼 수 있는 주차였으며, 앞으로의 코드구현과정에서 채득하며 실력을 기를 것입니다.

 

공통풀이 분석

2주차 과제는 함수의 분리와 테스트도구의 사용법을 익혀보는 주 였습니다.

 

기능목록을 관리하기

 

기능목록을 작성할 때는 클래스 설계/구현 등의 상세내용을 포함하지 않아야 합니다.

또한 기능목록을 중심으로 정리하되, 예외상황 또한 함께 정리해야 합니다. 다만 예외상황은 시작단계에서 한번에 파악이 어려우므로 기능을

구현하며 지속적으로 보완합니다.

 

메서드가 1가지 일만 하도록 설계하기

 

안내메세지 출력, 사용자 입력처리, 유효값 검증은 모두 사용자 입력을 처리하는 기능들이지만 각기 다른 기능이기도 합니다.

따라서 각 기능을 모두 하나의 메서드에서 처리하는 것이 아닌 여러 메서드에서 각각 담당할 수 있도록 분리하는 것이 좋습니다.

이를 통해 메서드 당 코드길이를 줄이고 단일책임원칙을 지킬 수 있으며, 테스트에 용이해집니다.

메서드가 1가지 일만 하는지 확인하기 어렵다면 다음 체크리스트를 적용해보며 고민해보면 좋습니다:

• 여러 메서드에 중복된 코드가 존재하는가
• 메서드의 길이가 긴가 (ex: 15줄 이상인가?)

테스트를 잘 작성하는 방법

 

테스트 작성은 기능의 정확성점검 뿐만 아니라 코드의 즉각적 피드백을 받을 수 있다는 점에서 중요합니다.

나아가 코드의 구조와 의도를 명확히 이해할 수 있도록 도와주기도 합니다.

 

이런 면에서 테스트코드를 처음부터 큰 단위로 작성하는 경우

여러 기능을 한번에 테스트하기 때문에 문제를 발견하기까지 오랜 시간이 걸리게 됩니다.

따라서 문제를 작게 나누어 핵심 기능부터 bottom-up 방식으로 테스트하는 것이 효과적입니다.