프리코스 끝난지 한달 됐는데 아직 회고 쓰는 사람이 있다..?! 그게 나야
\n사실 3주차 회고를 쓰는 중에 프리코스 결과가 발표났다.
하나도 기대 안하고 있다가 발표 났다는 소식을 듣고 확인했는데, 어떻게 된 건지는 몰라도 됐다,,,
\n엄청 당황했지만 바로 힘들게 기차 표 예매하고, 최종 코테 대비하고, 토요일에 최종 코테 치러 서울 갔다 오고 하다 보니 시간이 바쁘게 빠르게 지나갔다,,,
그리고 솔직히 말하면 프리코스 결과 발표는 하나도 기대 안했지만, 최종 코테는 정말 이게 올해 마지막이라는 마음에 간절해졌었다.
\n그러다보니 회고 쓰려고 프리코스 다시 보면 최종 코테에서 못한 것들이 생각나고 집중이 안돼서 회고는 최종 코테 발표날 때까지 넣어두고 다른 일들부터 했다.
\n한 달 뒤에 쓰는 회고도 그 때 생각을 다시 떠올리고, 그 때 생각 못했던 것들도 다시 떠올릴 수 있어서 나름 괜찮은 것 같다.
이번 4주차 미션도 저번 주차 미션보다 기능 요구 사항과 프로그래밍 요구 사항이 많아졌다.
\n특히 함수의 길이가 15라인에서 10라인으로 타이트하게 줄어든 것을 볼 수 있고, 메서드의 파라미터 개수도 3개로 타이트하게 제한했다.
그리고 이번 4주차 미션의 전체적인 학습 목표는 다음과 같다.
\n위아래 둘 중 하나의 칸만 건널 수 있는 다리를 끝까지 건너가는 게임이다.
\nIllegalArgumentException를 발생시키고, “[ERROR]“로 시작하는 에러 메시지를 출력 후 그 부분부터 입력을 다시 받는다.\nException이 아닌 IllegalArgumentException, IllegalStateException 등과 같은 명확한 유형을 처리한다.…
\n다리 건너기 게임을 시작합니다.\n\n다리의 길이를 입력해주세요.\n3\n\n이동할 칸을 선택해주세요. (위: U, 아래: D)\nU\n[ O ]\n[ ]\n\n이동할 칸을 선택해주세요. (위: U, 아래: D)\nU\n[ O | X ]\n[ | ]\n\n게임을 다시 시도할지 여부를 입력해주세요. (재시도: R, 종료: Q)\nR\n이동할 칸을 선택해주세요. (위: U, 아래: D)\nU\n[ O ]\n[ ]\n\n이동할 칸을 선택해주세요. (위: U, 아래: D)\nD\n[ O | ]\n[ | O ]\n\n이동할 칸을 선택해주세요. (위: U, 아래: D)\nD\n[ O | | ]\n[ | O | O ]\n\n최종 게임 결과\n[ O | | ]\n[ | O | O ]\n\n게임 성공 여부: 성공\n총 시도한 횟수: 2다리 건너기 게임을 시작합니다.\n\n다리의 길이를 입력해주세요.\n3\n\n이동할 칸을 선택해주세요. (위: U, 아래: D)\nU\n[ O ]\n[ ]\n\n이동할 칸을 선택해주세요. (위: U, 아래: D)\nU\n[ O | X ]\n[ | ]\n\n게임을 다시 시도할지 여부를 입력해주세요. (재시도: R, 종료: Q)\nQ\n최종 게임 결과\n[ O | X ]\n[ | ]\n\n게임 성공 여부: 실패\n총 시도한 횟수: 1지금까지 미션을 진행하면서 클래스 구조를 어떻게 하면 잘 설계할 수 있을지에 대해 많이 고민했다.
\n그래서 지금까지 MVC 패턴에 가깝게 미션에 맞는 클래스 구조를 설계했고, 마지막으로 4주차 미션에서는 비슷한 방식으로 설계하되 지난 주차 미션에서 아쉬웠던 점들을 보완하고자 했다.
4주차 미션에 추가된 프로그래밍 요구 사항에는 각 클래스 별로 제한 사항들이 많이 있었다.
\n그 중에서도 BridgeGame 클래스에서 InputView, OutputView 를 사용하지 않는다. 이 부분에 주목했다.
\n일단 저번 주차 미션에서 아쉬웠던 점 중 하나로 InputView 클래스를 만들지 않았다는 점이 있었다. OutputView 클래스는 구현했지만 InputView 클래스를 구현하지 않았었는데, 이번에는 InputView 클래스를 요구 사항에서부터 주었기 때문에 이 점은 쉽게 해결할 수 있었다.
\n하지만 지금까지 InputView, OutputView 클래스의 메서드들을 service 클래스에서 사용하고 Controller는 따로 구현하지 않는 방식으로 했었는데, 이번에는 요구사항에 BridgeGame 클래스에서 InputView, OutputView 를 사용하지 않는다. 이런 문구가 있어서 Controller와 Service를 확실하게 분리하여 구현하라는 말로 해석했다.
\n이전처럼 InputView, OutputView 클래스의 메서드들은 각 도메인에 해당하는 service 클래스에서 호출하여 사용하고, 하나의 BridgeGame이라는 Controller 클래스에서 각 상황에 필요한 service 메서드들을 호출하여 사용하는 방식으로 구현했다.
또한 이전 미션까지는 잘못된 값을 입력한 경우 IllegalArgumentException을 발생시키고, 에러 메세지를 출력한 후 종료하는 방식으로 예외 처리를 했었다.
\n하지만 이번 미션부터는 기능 요구사항에서 사용자가 잘못된 값을 입력할 경우 IllegalArgumentException를 발생시키고, \"[ERROR]\"로 시작하는 에러 메시지를 출력 후 그 부분부터 입력을 다시 받는다.라는 방식으로 예외 처리 방식이 바뀌었다.
\n그래서 이 부분도 반복문 안에서 try-catch 문을 사용하여 예외 상황이 발생하면 계속 반복하는 방식으로 구현했다.
3주차 피드백을 보면 위와 같이 객체는 객체스럽게 사용한다라는 피드백이 있다.
\ngetter 사용해서 데이터를 직접 꺼내는 방식을 지양하고 메시지를 직접 던져주는 방식을 지향하자라는 피드백이다.
\n피드백으로 이전 주차 미션을 예시로 간단하게 코드를 통해 설명하고 다음의 참고 문서도 제공해주었다.
참고 : getter를 사용하는 대신 객체에 메시지를 보내자
\n해당 피드백에서는 이전 주차 미션을 예시로 간단하게 코드를 통해 설명해주었지만 메시지를 던져준다는 말이 어떤 방식인지 잘 이해가 되지 않았다. 그래서 위의 링크로 들어가 문서를 참고했다.
\n2주차 미션에서 3주차 미션으로 넘어오면서 setter를 사용하는 방식을 지양하도록 주의하며 구현했다. 하지만 getter 사용은 크게 문제가 되지 않을 거라고 생각했는데 그렇지 않았다.
\ngetter를 사용해서 데이터를 직접 주고 받는 방식을 사용하면, 이 또한 외부에서 값을 변경할 수 있다는 위험성이 조금이나마 생기게 된다.
\n이를 보고 피드백과 위 문서에서는 객체스럽지 못하다고 설명하고 있다.
또한, getter를 남용하면 디미터의 법칙을 위반할 가능성이 생긴다고 설명하고 있다.
\n디미터의 법칙은 다른 객체가 어떤 데이터를 가지고 있는지 서로 모르게 하여 객체 간의 결합도를 낮춰야 한다는 법칙이다.
\n그렇기 때문에 getter를 사용해서 데이터를 직접 주고 받는 방식보다는 필요한 메시지만 주고 받는 메서드를 만들어서 이를 호출하는 방식으로 구현해야 디미터의 법칙을 위반하지 않게 구현할 수 있을 것이다.
따라서 이번 미션에서는 최대한 getter를 지양하는 방향으로 주의하며 객체를 객체스럽게 구현하고자 했다.
\n이전 주차 미션에서도 Enum을 사용했지만 그 때는 처음 접하는 거라 어떤 상황에서 사용해야 하는지, 어떻게 사용해야 하는지 잘 모르는 상태로 사용했다.
\n그렇기 때문에 이번 미션에서는 Enum에 대해 정리된 여러 문서들을 참고해서 Enum에 대해 알아본 후 구현했다.
우선 이번 미션에서는 다리를 생성하기 위해 BridgeNumberGenerator를 사용하는데 여기서는 0과 1 중 랜덤한 정수 값이 반환된다.
\n그러면 이 정수 값들을 저장해서 생성된 다리 정보를 저장해야 하는데 처음 요구 사항에서 주어진 makeBridge 메서드의 반환 값은 List<String>이다.
\n따라서 랜덤 생성된 정수 값을 문자열로 반환해서 저장하는 과정이 필요했고, 이 과정을 Enum을 사용하여 해결하면 되겠다고 생각했다.
1이면 \"U\", 0이면 \"D\"로 반환해주면 됐기 때문에 이 값들을 각각 매핑해주고 필드 값들을 추가했다.
public enum Position {\n UP(1, \"U\"),\n DOWN(0, \"D\");\n\n private final int positionNumber;\n private final String positionValue;\n\n Position(int positionNumber, String positionValue) {\n this.positionNumber = positionNumber;\n this.positionValue = positionValue;\n }다음으로 이 positionNumber를 positionValue로 변환해주는 기능이 필요했는데, 다음과 같은 메서드를 만들고 stream을 이용해 값을 반환하도록 했다.
public static String convertNumberToValue(int number) {\n return Arrays.stream(Position.values())\n .filter(position -> position.positionNumber == number)\n .findAny()\n .orElseThrow(() -> new IllegalArgumentException(\"[ERROR] 0 또는 1의 값만 가능합니다.\"))\n .positionValue;\n}또한 게임의 성공 여부를 출력하는 부분에서도 불필요한 if문이 반복되어서 이를 해결하기 위해 Enum을 사용해야겠다고 생각해 리팩토링했다.
\nprivate static void printIsSuccess(boolean status) {\n if (status) {\n System.out.println(\"게임 성공 여부: 성공\");\n }\n if (!status) {\n System.out.println(\"게임 성공 여부: 실패\");\n }\n}위와 같이 status 불리언 값에 따라 출력 값이 달라지는 경우였다.
\n하지만 이렇게 if문을 나눠서 사용하는 것은 else 예약어를 사용하지 말라는 요구 사항에도 맞지 않다고 생각했고, Enum을 사용해 해결할 수 있을 거라 생각했다.
public enum Status {\n SUCCESS(true, \"성공\"),\n FAIL(false, \"실패\");\n\n private final boolean check;\n private final String message;\n\n Status(boolean check, String message) {\n this.check = check;\n this.message = message;\n }\n\n public static String convertCheckToMessage(boolean check) {\n return Arrays.stream(Status.values())\n .filter(status -> status.check == check)\n .findAny()\n .orElseThrow(() -> new IllegalArgumentException())\n .message;\n }\n}앞선 Position enum 클래스와 거의 비슷하게 Status enum 클래스를 만들고,
\nboolean 값을 String 값으로 변환해주는 메서드도 만들었다.
private static void printIsSuccess(boolean status) {\n System.out.println(\"게임 성공 여부: \" + Status.convertCheckToMessage(status));\n}이를 이용해 위에서 if문이 반복되어 문제가 되었던 코드도 한 줄로 깔끔하게 리팩토링 할 수 있었다.
\nOutputView에 단순하게 정해진 문자열만 출력하면 되는 메서드들이 있음(Enum을 사용하면 관리하기 보다 편할 것 같음)Collections.unmodifiableList() 같은 Unmodifiable Collection을 사용하자프리코스가 끝나자마자 바로 회고를 작성하려고 했는데 다른 일들을 하다 보니 생각보다 늦어졌다. 예전 프로젝트 회고를 작성하면서도 느꼈지만 블로그 글 쓰는 것부터가 아직 서툴고 회고를 쓰는 데 생각보다 시간이 오래 걸리는 것 같다,, 많이 쓰다 보면 나아지겠지
\n2주차 미션이 끝나고 바로 3주차 미션이 시작되었다.
\n3주차 미션은 로또 게임 구현으로 이전 미션보다 기능 요구 사항이 많아졌고, 프로그래밍 요구 사항도 많아졌다.
필요한 흐름을 크게 4가지 단계로 나누고, 여기서 해당 단계에 필요한 기능과 예외 처리 부분들을 정리하는 방식으로 설계했다.
\n이 때 기능이 최소 단위가 되도록 더 나눌 수 있으면 분리하는 방식으로 진행하며, 이 후 구현 과정에서 하나의 함수가 정말 한 가지 기능만 담당할 수 있도록 했다.
2주차 미션 공통 피드백 중 하나로 함수가 한 가지 기능을 하는지 확인하는 기준을 세운다가 있었다.
기능 목록을 설계할 때, 가장 작은 단위로 기능을 분리하려고 했지만 그래도 여전히 더 분리할 수 있을 수도 있다.
\n이를 위해서 15라인 제한을 두었고, 구현 단계에서 만약 함수가 15라인을 넘어가면 기능 설계에 문제가 있었다는 것을 인지할 수 있도록 해 기능 분리와 함수 분리 연습에 많은 도움이 되었다.
2주차 미션 에서도 MVC 패턴에 가깝게 클래스 구조를 설계하려고 했지만 이 때는 MVC 패턴이 무엇인지 정확하게 모르고 있었기 때문에 이번 주차 미션에서는 MVC 패턴에 대해 공부한 후, 클래스 구조를 설계했다.
\n다음으로 클래스 구조 측면에서 바꿨던 점은 service 부분이다.
\n이전 주차 미션처럼 MVC 패턴 중 Model에 해당하는 부분을 domain 패키지와 service 패키지로 나누어 구현했다.
\ndomain 패키지에서 핵심 비즈니스 로직을 다루고, service 패키지에서는 비즈니스 로직에 필요한 작업들을 처리하도록 했다.
\n하지만 이번에 달라진 점은 domain에 맞춰서 service를 분리했다는 점이다.
\n이전 주차 미션에서는 비즈니스 로직에 대한 작업들을 처리하는 service 클래스를 하나만 만들어서 했지만, 이번 주차 미션에서는 domain 별로 나누어서 service 클래스를 만들었다.
\nservice를 도메인 로직에 맞춰 분리하여 구현하면서 보다 관리하기 편하게 했고, Controller 역할은 기능 범위가 크지 않아서 main에 있는 Application 클래스에서 담당하도록 했다.
마지막으로 domain 클래스에 값을 저장하는 방법도 바꿨다.
\n이전 주차 미션에서는 setter를 사용하여 값을 저장하는 방식을 사용했는데, setter를 사용하면 사용 의도를 알기 어렵고 값의 일관성을 유지하기 어렵다는 단점이 있다. 이런 이유 때문에 setter 사용은 지양하고 있고, 그래서 이번 주차에서는 생성자를 사용하는 방식으로 변경했다.
\nSetter 사용 지양과 관련해서는 추후 따로 포스팅할 예정이다.
2주차 미션에서도 단위 테스트 코드를 작성해서 테스팅을 진행했지만, 이 때는 정말 예제 코드를 따라서 몇 개 끄적여본 수준이었다.
\n이번에는 미션 목표에서부터 도메인 로직에 대한 단위 테스트를 작성하는 연습이라고 적혀있을 정도로 단위 테스트 구현에 대한 방향성이 제시되어 있었고, 그래서 이에 따라 구현하려고 노력했다.
그렇게 큰 기대를 하지 않은 채 메일로 결과를 확인했다.
\n‘축하드립니다’라는 문구를 확인하고 얼떨떨해서 메일을 계속 다시 읽다가 정신 차리고 기차 표부터 구했다.
\n당장 바로 3일 뒤였기 때문에 아침 일찍 기차로 표를 겨우 구하고 이제 내가 어떻게 붙은 건지 생각해봤다.
사실 이건 아직도 의문이다.
\n비전공자를 우선으로 한다는 말도 조금씩 나왔었고 소감문도 평가 요소에 포함된다는 말도 있는 등 여러 방면에서 나에게 이득이 되는 평가 요소는 많지 않았다. 그래서 내가 어떻게 합격하게 되었는지 정확히 알 수 없었다.
\n하지만 조금이나마 추측해보자면, 우테코에서 원하는 방향과 내가 미션을 해결하면서 찾고자 했던 방향이 비슷했던 것 같다.
\n구현하기 전에 클래스 구조를 설계하는 과정을 우선시 하고, 미션 요구사항을 중요하게 생각하는 등 이런 생각이 우테코에서 원하는 프리코스 목표와 비슷했지 않을까. 그리고 다른 사람들이 보기에는 나도 다른 사람들처럼 간절해보이지 않았을까. 그렇게 생각한다.
12월 17일.
\n아침 일찍 KTX를 타고 서울로 갔다.
도착해서 점심을 먹고 선릉역에 도착해서 선릉 캠퍼스로 가는 길은 떨리기보다는 설렜다.
\n보통 이런 시험을 앞두고 많이 긴장하는 타입이지만 왠지 모르게 이 날은 설렜다.
\n기대도 안하고 있던 시험이어서 보너스로 기회가 주어졌다는 생각이 커서인지 긴장하는 마음 하나 없이 도착했고, 오히려 유튜브로만 보던 코치님들을 보니 반가운 마음이 들었다.
도착해서 가장 놀랐던 점은 엄청 자유로운 환경이라는 점이었다. 코테 중간에 자유롭게 화장실 이용은 물론이고 준비된 간식들을 가져와서 먹거나 구경하는 것도 가능해서 놀랐다,,
\n당연히 노트북 거치대나 마우스, 키보드 사용이 안될 거라 생각하고 안가져갔는데 사용 가능했다,,,
그리고 13시부터 점심 메뉴 추천이라는 주제의 최종 코딩 테스트가 시작되었다.
\n한 주의 점심 메뉴를 추천해 주는 서비스다.
\n, 로 구분해서 입력한다.)\nIllegalArgumentException를 발생시키고, “[ERROR]“로 시작하는 에러 메시지를 출력 후 그 부분부터 입력을 다시\n받는다.\nException이 아닌 IllegalArgumentException, IllegalStateException 등과 같은 명확한 유형을 처리한다.…
\n점심 메뉴 추천을 시작합니다.\n\n코치의 이름을 입력해 주세요. (, 로 구분)\n토미,제임스,포코\n\n토미(이)가 못 먹는 메뉴를 입력해 주세요.\n우동,스시\n\n제임스(이)가 못 먹는 메뉴를 입력해 주세요.\n뇨끼,월남쌈\n\n포코(이)가 못 먹는 메뉴를 입력해 주세요.\n마파두부,고추잡채\n\n메뉴 추천 결과입니다.\n[ 구분 | 월요일 | 화요일 | 수요일 | 목요일 | 금요일 ]\n[ 카테고리 | 한식 | 한식 | 일식 | 중식 | 아시안 ]\n[ 토미 | 쌈밥 | 김치찌개 | 미소시루 | 짜장면 | 팟타이 ]\n[ 제임스 | 된장찌개 | 비빔밥 | 가츠동 | 토마토 달걀볶음 | 파인애플 볶음밥 ]\n[ 포코 | 된장찌개 | 불고기 | 하이라이스 | 탕수육 | 나시고렝 ]\n\n추천을 완료했습니다.합격이었다..
\n정말 2022년 마지막이라고 생각했던 라스트 댄스가 성공해서 너무 기뻤고 믿기지 않았다.
\n단위 테스트랑 리팩토링이 부족해서 남들보다 기준치에 약간 밀리지 않을까 걱정했었는데 아마 이번에도 내가 생각했던 방향과 우테코가 원했던 방향이 맞았던 것 아닐까 생각한다.
\n기초부터 탄탄히 설계를 잘한 다음에 돌아가는 쓰레기를 만들어 놓으면, 그 다음 과정은 우테코에서 가르치겠다는 그런 뜻이 아닐까