본문 바로가기

우아한테크코스 7기

우아한테크코스 7기 프리코스 2주차 회고

노션으로 적었던 회고를 블로그로 옮겨보겠습니다.

2주차 미션은 레이싱 미션이었습니다.

 

프로그램을 실행하면 쉼표를 기준으로 경주할 자동차의 이름을 입력받습니다. 이후 시도할 횟수를 입력하면 0에서 9 사이의 무작위 값을 구하고, 무작위 값이 4 이상일 경우에만 전진하여 최종 우승자를 결정하는 게임입니다.

예시)

경주할 자동차 이름을 입력하세요.(이름은 쉼표(,) 기준으로 구분)
pobi,woni,jun
시도할 횟수는 몇 회인가요?
5

실행 결과
pobi : -
woni : 
jun : -

pobi : --
woni : -
jun : --

pobi : ---
woni : --
jun : ---

pobi : ----
woni : ---
jun : ----

pobi : -----
woni : ----
jun : -----

최종 우승자 : pobi, jun

 

 

2주차에서 가장 집중했던 부분은 문서 작성이었습니다. 프로젝트마다 리드미는 다른 형태를 가질 수 있지만, 어느 정도 기본 틀을 잡아두면 앞으로 작업이 수월해질 것이라 생각했습니다. 그래서 가장 많이 변화하고 신경 쓴 부분이 리드미 작성이었습니다. 목차를 작성하고 프로젝트 구조를 포함시켰습니다. 2주차에는 요구사항도 모두 기재했지만, 공통 요구사항은 제외하는 것이 더 깔끔하다고 판단했습니다. 인덴트는 2까지만 허용하고, else나 switch는 사용하지 않는 등 여러 가지 요구사항이 있었습니다. 2주차까지는 요구사항을 대부분 충족시켰던 것 같습니다. 기능 구현에는 큰 어려움이 없었던 것 같습니다.

 

 

1주차와 달랐던 점은 exception과 validator의 분리였습니다. 기능을 나누고 확장성을 고려해 분리했는데, 작은 프로젝트에서 예외 처리를 따로 두는 것이 가독성을 떨어뜨리지 않을까 하는 생각이 들기도 했습니다. 여기서 Car 객체를 분리해서 구현할 생각을 하지 못했었는데, 생각해보면 위치와 상태를 가지고 있는 자동차 객체가 존재하는 것이 자연스러운 것 같습니다.

 

 

 

2주차까지 의존성 주입을 직접 하는 것이 낯설었습니다. 전체적인 개념도 부족했고, 어떤 절차와 원리로 해야 하는지, 접근제어자를 어떻게 사용해야 하는지 등 기초적인 부분이 많이 부족했습니다. 정규표현식을 활용하는 부분도 자주 등장했고, 앞으로도 자주 필요할 이유를 알 것 같았습니다. 소통을 위해 상대방의 말을 이해해야 하듯이, 처리해야 할 것들이 많았습니다. 이때에도 TDD는 굉장히 낯설었습니다. 솔직히 감이 잘 오지 않았고, 기존에는 구현하면서 수정하는 방식으로 해왔기 때문에 많이 어색했던 2주차였습니다. 만들어놓고 테스트를 하는 방식으로 진행했습니다.

 

출력 부분도 고민이 많이 되는 작업이라는 것을 배웠습니다. 이 과정에서 static으로 처리할지에 대한 고민도 했지만, 2주차에는 그냥 진행했습니다.

public class RacingCarViewer {

    public void promptCarNamesInput() {
        System.out.println("경주할 자동차 이름을 입력하세요.(이름은 쉼표(,) 기준으로 구분");
    }

    public void promptTryNumber() {
        System.out.println("시도할 횟수는 몇 회인가요?");
    }

    public void showWinners(List<String> winners) {
        String result = "";
        for (String winner : winners) {
            result = result.concat(winner);
            if (!winner.equals(winners.getLast())) {
                result += ", ";
            }
        }
        System.out.println("최종 우승자 : " + result);
    }

    public void showFinalRacingResult(Map<String, String> racingResult) {
        racingResult.forEach((k, v) -> System.out.println(k + " : " + v));
        System.out.println();
    }

    public void showRepeatRacingResult() {
        System.out.println("실행 결과");
    }
}

 

클래스 레벨에서 불러올 수 있는 것은 꽤 유용하지만, 객체지향의 핵심인 상속과 오버라이딩을 제한하는 치명적인 단점이 있다고 생각했습니다. 그렇다고 무작정 배제하기에는 static의 장점도 있다고 생각합니다. 메모리 절약이나 코드의 간결함, 클래스 이름으로 바로 이어지는 가독성 같은 부분도 그렇습니다. 유틸리티 클래스나 변하지 않지만 여러 곳에서 사용되는 경우에 적용할 만하다고 생각합니다. 2주차에는 객체지향에 대해 다시 생각해볼 수 있는 시간이었지만, 막상 코드를 작성할 때는 생각처럼 쉽지 않았습니다.

 

 

 

제출했던 2주차 회고를 첨부하며 마무리하겠습니다

 

프리코스 2주차 회고

이번 프로젝트에서는 디렉토리 구조를 나누고 exception과 validator를 분리하여 책임을 명확히 하려고 노력했습니다. 도메인(Car, Dto 등)을 별도로 분리할 필요가 있는지에 대해 고민했지만, 이번 프로젝트에서는 현재 구조를 유지하기로 결정했습니다.

과제 진행 중 기능 단위 커밋과 함수가 한 가지 일만 수행하도록 하는 요구사항을 철저히 지키지 못했던 것 같습니다. 기획과 설계 단계에서 예상하지 못했던 부분들이 많이 드러나 수정 작업이 잦았기 때문입니다.

이번 프로젝트에서는 모든 메서드를 검증하기보다는, 중요한 메서드에 대한 검증에 집중했습니다. 다양한 예외 케이스와 사용자 입장에서 궁금할 만한 요소들(예: 자동차 이름에 공백이 포함되어도 되는지 등)에 대해 다양한 관점에서 고민했습니다.

또한, Map, Set 자료구조에 대해 더 깊이 이해할 수 있는 시간이었습니다. 무작위 숫자의 검증 방법이나 void 타입의 검증 방법에 대해서도 생각해볼 기회가 있었습니다.

가장 크게 달라진 점은 문서 작성의 중요성을 깨달았다는 것입니다. 문서의 중요성에 대해 실감하며 많은 시간을 투자하고 구상했습니다. 이번 프리코스 기간 동안 저만의 문서 작성 틀을 만들어가고자 합니다.


지원서에 작성한 목표를 얼마나 달성하고 있다고 생각하나요? 그 이유는 무엇인가요?

 제 목표는 약 80% 정도 달성하고 있다고 생각합니다. 기초에 충실하고 꾸준한 습관을 유지하는 부분에서는 잘 진행되고 있으나, 프리코스를 통해 몰입을 위한 기초가 부족하다는 점을 느끼고 있습니다. 특히 객체지향적인 설계와 기능 분리에 많은 어려움을 겪고 있습니다. 나머지 20%를 채우는 것도 목표지만, 현재 달성한 80%를 잘 유지하는 것 또한 중요한 과제로 삼고 있습니다.


지원서에 작성한 목표를 변경해야 한다고 생각하시나요? 그렇다면 그 이유와 어떤 목표로 변경하고 싶으신가요?

 큰 방향성에는 변함이 없습니다. 다만, 세부적인 목표를 조금 더 구체적으로 세울 필요가 있다고 생각합니다. 프리코스에서 제시하는 클린 코드, 협업을 위한 코드 컨벤션, 기초적인 공통 사항, 테스트 주도 개발, 책임의 분리 등 기초적인 부분을 반복적으로 학습하고, 자바에 대한 이해도를 높이는 데 집중하고자 합니다.


프리코스를 진행하면서 눈에 띄는 변화나 깨달은 점이 있나요?

 정말 많은 변화가 있었습니다. 같은 문제를 다양한 시각으로 바라보는 과정을 통해 시야가 넓어졌습니다. 무엇보다 개발에 열정이 있는 사람들과 의견을 활발히 교류하는 과정이 매우 흥미롭고 설레는 일이라는 것을 느꼈습니다. 부족함을 느끼지만 동시에 자신감이 생겼습니다. '이렇게 하면 되겠구나', '이렇게 하면 성장할 수 있겠구나'라는 생각을 많이 하게 되었습니다. 목표를 향해 가야 할 길이 더욱 또렷하게 보이기 시작했습니다.

무엇보다 요구사항을 정확히 파악하고 정리하는 것이 얼마나 중요한지 깨달았습니다. 개발 중간에 미처 파악하지 못한 요구사항을 발견하면 많은 수정이 필요하다는 점을 실감했습니다. 요구사항 분석과 기록의 중요성을 많이 배우는 시간이었습니다.

이러한 배움을 바탕으로 블로그에 기록해두어 앞으로도 발전할 수 있는 계기를 마련하고자 합니다.