우테코 프리코스 그리고 최종 코테가 끝난지도 한달이 지났다.
\n다시 한 달 전의 기억을 살려서 최종 코딩 테스트 후기를 써보려고 한다.
\n지금까지 썼던 회고와는 다르게 일기 느낌으로다가,,
11월 23일.
\n4주 동안의 프리코스 과정이 끝났다.
프리코스가 끝나고 바로 들었던 생각은 ‘떨어져도 괜찮을 것 같다’였다.
\n자바를 싫어하고 자바에 대해서 1학년 수준의 기초 밖에 모르는 상태에서 시작했던 프리코스였기 때문에 이미 이 4주 동안의 프리코스 과정만으로도 많은 것들을 배웠다는 생각이 들었다. 게다가 프리코스를 진행하면서 각 주차가 끝나고 다른 사람들의 코드를 봤을 때, 나랑은 완전 차원이 다르게 잘하는 사람이 많구나라고 생각했다. 각 주차가 끝나고 쓰는 소감문도 정말 간단하게 해당 주차에 새롭게 배운 핵심 내용들만 적었던 나로서는 ‘나보다 더 간절한 사람이 붙겠지’라는 생각만 들었다.
그리고 12월 14일 1차 심사 결과가 나왔다.
\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기초부터 탄탄히 설계를 잘한 다음에 돌아가는 쓰레기를 만들어 놓으면, 그 다음 과정은 우테코에서 가르치겠다는 그런 뜻이 아닐까
프리코스 끝난지 한달 됐는데 아직 회고 쓰는 사람이 있다..?! 그게 나야
\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을 사용하자우테코를 시작한지 한 달.. 드디어 여유가 생겼다.
\n생각보다 빠르게 한 달이 지나갔다. 미션 회고도 쓰고 여러 블로그 글도 쓰고 싶었지만, 미션 진행하고 우테코 생활 적응하는 것만으로도 바빠서 못하고 있었다. 사실 글 쓸 때 쓰고 지우고 고민하느라 시간이 많이 걸리는 게 한 몫 했다ㅎ,,
\n이미 자동차 경주 미션과 사다리 타기 미션을 끝내고 블랙잭 미션을 진행하고 있지만 늦게나마 지난 미션들을 회고해보려 한다.
자동차 경주 미션은 우테코에 들어와서 진행한 첫 미션이다.
\n모든 미션은 2개의 단계로 나뉘는데, 1단계는 페어 프로그래밍으로 진행하고 2단계는 혼자서 진행한다. 각 단계가 끝나면 리뷰어에게 코드 리뷰를 받고, 피드백을 반영하여 머지 되면 다음 단계를 진행하는 방식으로 한다.
사실 처음 미션을 시작하기 전에는 페어 프로그래밍이 무서웠다.
\n하나의 노트북으로 같이 페어 프로그래밍을 진행하면 내 실력이 낱낱이 드러날까봐 그게 무서웠다. 물론 지금도 어떤 페어와 매칭이 될지 미션이 시작하기 전에는 떨리긴 하지만 막상 시작하면 생각했던 것만큼 힘들진 않았다. 같이 했던 페어들이 엄청 편하게 대해줬고 새로운 의견을 얘기할 때도 항상 다른 의견은 없는지 배려해줘서 편하게 페어 프로그래밍을 할 수 있었다.^^
자동차 이름 입력
\n시도할 횟수 입력
\n게임 실행
\n라운드 실행
\n결과
\n미션을 시작하기 전에는 나도 페어도 일급 컬렉션이 뭔지 몰랐다.
\n일급 컬렉션이 뭔지 모르니 일급 컬렉션을 써야겠다는 생각도 하진 못했고, 그냥 단순하게 구현해야겠다고 생각하고 구현했다.
그러다가 자동차의 이름과 진행 상황(자동차 위치)을 어떻게 저장할지에 대해 페어랑 고민하게 됐다.
\n처음에는 HashMap으로 자동차 이름이랑 진행 상황들을 저장해야겠다고 생각했다.
\n그러면 Car라는 클래스에서 이름이랑 위치를 가지도록 하고, Car들을 List로 저장해두는 방식이 더 깔끔하지 않을까?
\n어, 이게 일급 컬렉션인가???
\n이렇게 페어랑 고민하는 과정을 거쳤고, 일급 컬렉션이 뭔지 알게 되었다.
이번 미션에서 가장 많이 배웠고 뿌듯하다고 생각한 부분이다.
\n일급 컬렉션이 뭔지 알고 적용했다는 점도 중요하지만, 사용해야 하는 이유를 직접 페어랑 고민하며 찾아가는 과정을 거쳤다는 점이 뿌듯했다.
\n한 단계 더 성장했다는 느낌을 직접 받을 수 있었고, 이런 부분이 페어 프로그래밍을 하는 가장 큰 이유라고 생각한다.
MVC 패턴을 사용하고, Controller와 Service를 나누도록 구현했다.
\n하지만 여전히 Controller나 Service의 제대로 된 역할을 알지 못한 채 구현했다.
처음에는 Service에서 진행에 관한 기능도 다 담당하고, 입출력에 대한 책임도 담당하도록 했다.
\n이렇게 했을 때 문제점은 Service가 View와 관계를 가지고 서로 의존하게 된다.
\n여기서 Service는 MVC 패턴에서 Model의 역할을 분리한 계층 중 하나다.
\nMVC 패턴에서는 Model과 View가 직접 소통하지 않고 Controller를 거쳐서 소통한다. 그게 Controller의 역할이다.
\n하지만 이렇게 되면 Service가 View와 소통하며 Controller의 역할을 하게 되고, Controller가 필요 없어진다.