우테코를 시작한지 한 달.. 드디어 여유가 생겼다.
\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가 필요 없어진다.
그렇게 큰 기대를 하지 않은 채 메일로 결과를 확인했다.
\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모든 기능을 TDD로 구현해 단위 테스트가 존재해야 한다. 단, UI(System.out, System.in) 로직은 제외
\n라는 요구 사항이 추가되어서 TDD로 미션을 진행했다.
TDD를 위해
\n위 과정을 거쳐가며 구현했다.
\n개인적으로 아직 TDD가 좋은 개발 방법인지는 모르겠다.
\n일반적인 인간의 사고 방식과는 반대로 되어 있어서 이해하기 힘들다는 생각이 들기도 하고, 그래서인지 구현 후 테스트 작성을 하는 방식보다 더 시간이 오래걸렸다.
그렇다고 장점이 아예 없다고 생각하지는 않는다.
\n우선, 가장 큰 장점은 테스트를 강제하기 때문에 테스트 커버리지가 높아진다는 점.
\n기능 구현 후 단위 테스트를 작성하는 방식으로 해도 되지만, 아직은 익숙하지 않아서인지 단위 테스트를 작성하지 않고 수동 테스트를 통해 확인하고 넘어가는 경우가 많다. 서비스가 커지면 수동 테스트보다 단위 테스트를 통해 테스트를 하는 게 효율이 좋다고 생각하는데, 이 때 TDD로 개발하면 단위 테스트 작성을 강제할 수 있어서 좋다고 생각한다.
또한 기능 구현 후 단위 테스트를 작성하는 방식은 이미 구현한 기능을 바탕으로 테스트 하게 되어서 예상 가능한 테스트만 하는 현상이 생길 수 있지만, 테스트 작성 후에 기능을 구현하면 이를 방지할 수 있다는 장점도 있다. (베로와의 대화에서 발췌,,)
\n따라서 TDD도 각자 기준을 정해두는 것이 좋다고 생각한다.
\n지금은 학습 단계여서 100% TDD로 구현하고 있지만, 실제 서비스를 구현할 때는 TDD의 장단점을 잘 구분해서 상황에 맞게 사용해야 한다고 생각한다.
이번 미션에는 여러 요구 사항이 추가되었는데 이 중에는 모든 원시 값과 문자열을 포장한다와 일급 컬렉션을 쓴다라는 객체지향 생활 체조 원칙 내용들도 포함되어 있었다.
public class User {\n private final Name name;\n private final Position position;\n\n public User(String name, int position) {\n this.name = new Name(name);\n this.position = new Position(position);\n }\n ...\n}그래서 위 코드와 같이 원시 값들을 포장하는 방식으로 구현했다.
\n단순히 아래와 같이 원시 값을 필드로 가져도 되지만
\nprivate final String name;\nprivate final int position;Name과 Position 클래스를 새로 만들어서 각각의 역할과 책임을 따로 관리하도록 했다.
처음에는 단순히 요구 사항이기 때문에 요구 사항을 만족시키기 위해 이렇게 구현했지만, 계속 미션을 진행하면서 코드가 길어지는 걸 보니 왜 이런 방식을 추구하는지 이해할 수 있었다.
\npublic class Name {\n private static final int MIN_NAME_LENGTH = 1;\n public static final int MAX_NAME_LENGTH = 5;\n public static final String NAME_LENGTH_ERROR_MESSAGE =\n \"[ERROR] 사람 이름은 \" + MIN_NAME_LENGTH + \"~\" + MAX_NAME_LENGTH + \"글자로 입력해 주세요.\";\n public static final String NAME_FORMAT_ERROR_MESSAGE = \"[ERROR] 사람 이름은 영문자만 가능합니다.\";\n private static final String NAME_REGEX_FORMAT = \"^[a-zA-z]*$\";\n\n private final String name;\n\n public Name(String name) {\n validateNameLength(name);\n validateNameFormat(name);\n this.name = name;\n }\n\n private void validateNameLength(String name) {\n if (isValidLength(name)) {\n throw new IllegalArgumentException(NAME_LENGTH_ERROR_MESSAGE);\n }\n }\n\n private boolean isValidLength(String name) {\n return name.length() < MIN_NAME_LENGTH || name.length() > MAX_NAME_LENGTH;\n }\n\n private void validateNameFormat(String name) {\n if (!name.matches(NAME_REGEX_FORMAT)) {\n throw new IllegalArgumentException(NAME_FORMAT_ERROR_MESSAGE);\n }\n }\n\n public String getName() {\n return name;\n }\n}위 코드처럼 검증에 대한 메서드가 추가되니 Name 클래스에 대한 코드가 점점 길어졌다.
\n검증에 대한 일 뿐만 아니더라도 추후에 다른 메서드가 추가될 수 있다는 확장성을 고려한다면, 이렇게 원시값을 포장하는 것이 좋다고 생각한다.
또한 Name 뿐만 아니라 Position 클래스도 상황이 비슷하기 때문에, 이런 코드들을 다 User 클래스에 두는 것보다는 클래스를 따로 만들어서 관리하는 것이 직관성에도 좋다고 생각한다.
기존 코드에서는 View에 도메인 객체를 직접 넘겨주고 출력하도록 했다.
\n하지만 이렇게 하면 View에서 도메인 객체를 조작하는 문제가 생길 수 있어서 이를 방지하기 위해 DTO를 사용해서 도메인과 View 사이의 의존 관계를 끊어보라는 리뷰어의 피드백이 있었고, 이를 바탕으로 다음과 같이 수정했다.
public class LadderDto {\n private final List<LineDto> lines;\n\n private LadderDto(List<LineDto> lines) {\n this.lines = lines;\n }\n\n public static LadderDto from(Ladder ladder) {\n return new LadderDto(ladder.getLines());\n }\n\n public List<LineDto> getLines() {\n return lines;\n }\n}public class LineDto {\n private final List<Boolean> line;\n\n private LineDto(List<Boolean> line) {\n this.line = line;\n }\n\n public static LineDto from(Line line) {\n return new LineDto(line.getLine());\n }\n\n public List<Boolean> getLine() {\n return line;\n }\n}이런 방식으로 LadderDto, LineDto, PrizesDto, UsersDto를 각각 만들어서 출력을 위해 OutputView에 넘겨줄 때, 도메인 객체를 넘기는 것이 아니라 해당하는 DTO 객체를 넘기도록 수정했다.
2단계 미션을 진행하면서 요구사항과 확장성 사이에 어떤 걸 중요하게 여겨야 할지에 대해 고민해보았다.
\n