반응형

 

 

 

 

우아한테크코스 5기 백엔드 과정에 지원했고,

2022년 12월 17일에 시험을 마치고 왔습니다.

 

지난 기수 분들의 후기를 통해 많은 도움을 받아 합격할 수 있었기에,

이번 5기 시험에 대한 정보를 나누고자 글을 적어 봅니다.

 

적고자 하는 내용은,

 

1) 우아한테크코스 최종 코딩테스트를 준비한 방법 공유

2) 5기 시험에 대한 정보 공유 (난이도 등..)

 

입니다.

 

글을 읽으시기에 앞서,

우테코 최종 코딩테스트 유형에 대해 잘 모르신다면,

아래 링크를 통해 5기 최종 코테 리파지토리를 확인하실 수 있습니다.

 

GitHub - woowacourse-precourse/java-menu

Contribute to woowacourse-precourse/java-menu development by creating an account on GitHub.

github.com

 

 

 

 

 

 


지원자 상황 공유

최종 코딩테스트와 관련한 얘기에 앞서서,

저의 상황을 대략적으로 공유드리는 것이 객관적인 정보 획득에 도움이 될 것 같아

몇 자 적어봅니다.

 

  • 비전공자(전자전기공학 전공 / 컴퓨터 관련 과목 교양 C언어, Matlab만 수강)
  • 개발 공부한지 약 10개월 차에 지원 (파이썬, 노드로 프로젝트 경험 O)
  • 자바 경험 X (위키독스 점프 투 자바 1 회독 한 경험만 있었고, 그마저도 까먹어 우테코 지원하면서 다시 1 회독했습니다.)
  • 풀타임으로 우테코에 집중할 수 있는 상황 (주 2회 아르바이트, 주 1회 학교 등교 정도 외에는 우테코에 전부 집중했습니다.)

 

 

 

 

우아한테크코스 최종 코딩테스트를 준비한 방법

 

이번 5기는 지원자 전원이 프리코스(4주)에 참여할 수 있었고,

지원서 + 프리코스(4주)의 정성적 평가로 최종 테스트 대상자를 선발했습니다.

 

프리코스부터 최종 코딩테스트를 준비하며 제가 선택한 전략은

"할 수 있는 모든 것을 하기"였습니다.

 

 

최종 코딩테스트를 위해 준비한 것을 나열해 보겠습니다.

 

  • 프리코스 기간 동안, 미션 해결하기 전에 시간 재서 풀어보기
  • 프리코스 기간 동안 받았던 피어 리뷰 복습하기
  • 5기 미션 동안 구상한 프로그램 설계 정리하기 -> 추후 문제 풀면서, 빠른 풀이에 적합한 설계 확정
  • 5기 미션 시간 재서 다시 풀어보기
  • 1~4기 프리코스 미션 시간 재서 풀어보기
  • 2~4기 최종 코딩테스트 시간 재서 풀어보기
  • 5기 프리코스 기간 동안 받은 공통 피드백 다시 읽어보고 공부하기
  • 불편한 상황에서 문제 풀기(시끄러운 카페의 기울어진 책상에서 60%의 시간 재고 문제 풀기)
  • (오픈북 시험이므로) 위의 모든 과정 동안, 시험장에서 사용할 참고 노트 작성
    • 자바 문법 관련 정리
    • 프로그램 설계 및 구현 방식 정리
    • 시험 직전 및 제출까지의 체크리스트 정리

 

문제를 풀 때는,

1. 시간 재서 문제 풀고 채점하기 (테스트 코드 동작 확인, 모든 프로그래밍 요구사항 만족 체크)

2. 어려웠던 부분, 새롭게 사용한 문법 등 -> 적절한 참고 노트에 정리

3. 다른 사람들 코드(PR) 보면서 참고할 부분 정리 -> 다만, 

 

요약하자면 아래와 같습니다.

1. 프리코스 기간에 공부한 내용을 복습하고,

2. 이번 + 지난 기수 모든 문제를 풀면서 참고 노트를 정리하고,

3. 여러 돌발 상황에 대해 대비하고,

4. 시험장에서 해야 할 일들(세팅, 설계, 구현, 검사)을 정리하고 이미지 트레이닝하기

 

프리코스가 끝나고 1차 합격자(최종 코딩테스트 대상자) 발표가 2주,

그리고 발표부터 시험까지가 3일밖에 주어지지 않았습니다.

 

3일이라는 시간은 (적어도 저에겐) 최종 코딩테스트를 준비하기에 턱없이 부족한 시간이라고 생각했고,

나름의 객관적인 판단(많은 사람들의 미션 확인, 나의 지원서에 대한 지인들의 평가 등)을 통해

1차는 합격할 것이라는 확신이 있었기 때문에,

1차 발표 전부터 코딩테스트를 계속 준비해 왔습니다.

 

그 덕에 여유를 가지고 계획한 모든 것을 잘 준비할 수 있었고,

다행히 5기 최종 코딩테스트에서 테스트 케이스 통과,

그리고 (개인적 확인으로는) 모든 요구사항을 만족시킬 수 있었습니다.

 

 

제가 정리한 노트, 기수 별 문제 링크 정리한 것 등

자료들을 전부 공유드리고 싶지만,

 

저의 공유가 도움을 주는 것 이외에

전형 자체를 너무 고이게 만들고, 그것이 결국 지원자분들의 피로를 가중시키는 일이 될까 봐

고민 끝에 자료 공유는 하지 않기로 했습니다.

 

다만 요구사항에 "테스트 코드가 통과하지 않으면 0점으로 간주한다."는 내용이 있다면

테스트 코드 통과를 최우선 목표로 하시는 것이 좋지 않을까 싶다는 생각을 전달드립니다.

 

 

그리고 제가 준비한 내용들이 누군가에겐 무난하게 보일 수도,

누군가에게는 너무 과하다고 생각이 들 수도 있을 것 같습니다.

여러 사람의 준비 과정을 보고 들은 것으로는,

제가 평균보다는 확실히 많이 투자한 것으로 이해해주셔도 될 것 같습니다.

 

무엇보다, 구글링을 통해 접할 수 있는 많은 지원자들의 후기를 통해

종합적으로 판단하시는 것을 추천드립니다.

 

 

 

 

5기 시험에 대한 정보 공유

 

우테코 5기 최종 코딩테스트 문제에 대해 간단하게 생각을 적어보고자 합니다.

아직 문제를 풀어보시기 전이라면, 문제를 풀어보고 읽어보시기를 추천드립니다.

(이건 스포를 싫어하는 제 성향이니 무시하셔도 좋습니다.)

 

 

난이도

무난하다 못해 쉽게 느껴지는 난이도였다고 생각합니다.

물론 시험 자체, 문제 자체가 쉬운 것은 아니고

제가 똑똑해서 쉬웠다는 것도 절대 아닙니다.

이전 기수의 모든 문제를 풀어본 경험 + 다른 지원자들의 얘기를 미루어볼 때 그렇습니다.

 

3기 최종 코딩테스트였던 지하철 경로 문제는 개인적으로 쉽지 않았고,

4기 최종 코딩테스트였던 페어 매칭 문제는 개인적으로 정말 어렵다고 느꼈었는데요,

그에 비해 이번 5기 점심 메뉴 추천은, 설계부터 구현까지 비교적 직관적으로 진행할 수 있었습니다.

 

 

풀이

개인적으로 Enum을 잘 활용한 것이 이번 시험을 무난하게 마칠 수 있었던 결정적 이유라고 생각합니다.

관련하여, 저의 풀이 PR 링크를 공유드립니다.

 

[점심 메뉴 추천] 이우진 미션 제출합니다. by horsehair · Pull Request #152 · woowacourse-precourse/java-menu

프로그램 설명 입력된 코치들에게 점심 메뉴를 추천해주는 프로그램 기능 구현 목록 UI InputView 코치 이름 목록 입력 (예외 처리) 시작과 끝에 있는 "," 제거 요청 못 먹는 메뉴 목록 입력 콘솔에

github.com

 

 

아래는 Enum을 사용한 코드입니다.

public enum Category {
    JAPANESE(1, "일식", Arrays.asList("규동", "우동", "미소시루", "스시", "가츠동", "오니기리", "하이라이스", "라멘", "오코노미야끼")),
    KOREAN(2, "한식", Arrays.asList("김밥", "김치찌개", "쌈밥", "된장찌개", "비빔밥", "칼국수", "불고기", "떡볶이", "제육볶음")),
    CHINESE(3, "중식", Arrays.asList("깐풍기", "볶음면", "동파육", "짜장면", "짬뽕", "마파두부", "탕수육", "토마토 달걀볶음", "고추잡채")),
    ASIAN(4, "아시안", Arrays.asList("팟타이", "카오 팟", "나시고렝", "파인애플 볶음밥", "쌀국수", "똠얌꿍", "반미", "월남쌈", "분짜")),
    WESTERN(5, "양식", Arrays.asList("라자냐", "그라탱", "뇨끼", "끼슈", "프렌치 토스트", "바게트", "스파게티", "피자", "파니니"));

    private final int number;
    private final String name;
    private final List<String> menus;

    Category(int number, String name, List<String> menus) {
        this.number = number;
        this.name = name;
        this.menus = menus;
    }

    public static void checkMenuExist(String menu) {
        boolean haveMenu = false;
        for (Category category : Category.values()) {
            if (category.haveMenu(menu)) {
                haveMenu = true;
                break;
            }
        }
        if (!haveMenu) {
            throw new IllegalArgumentException("[ERROR] 존재하지 않는 메뉴입니다.");
        }
    }

    private boolean haveMenu(String menu) {
        return menus.contains(menu);
    }

    public static Category getRandomCategory() {
        int randomNumber = Randoms.pickNumberInRange(START_NUMBER_OF_CATEGORY, COUNT_OF_CATEGORIES);
        return Arrays.stream(Category.values())
                .filter(category -> category.isNumberOf(randomNumber))
                .findAny()
                .orElseThrow(() -> new IllegalArgumentException("[ERROR] 존재하지 않는 번호의 카테고리입니다."));
    }
    
    public String getRandomMenu() {
        return Randoms.shuffle(menus).get(0);
    }
	// 이하 메서드 생략
}

 

 

시험 진행 관련 정보

1) 실제 교육 장소에서 시험을 치렀습니다.

아마 백엔드 과정은 선릉 캠퍼스에서 시험을 응시하신 것 같고,

다른 과정은 정확히는 모르겠으나 잠실 캠퍼스에서 응시하시지 않았나 싶습니다.

 

2) 넓지 않은 책상에서 시험을 응시했습니다.

노트북, 마우스와 패드, 노트와 펜, 충전기

이 정도를 사용하고자 하면 책상이 가득 찰 정도의 너비였습니다.

아무래도 많은 지원자가 교육장에서 한꺼번에 시험에 응시하니 어쩔 수 없지 않나 싶습니다.

좁은 자리에서 연습해보시는 것도 좋을 것 같습니다.

 

3) 이어폰, 노트북 거치대, 키보드는 사용 가능했습니다.

다만 기수 별로 어떻게 바뀔지는 모르겠습니다.

저는 블루투스 이어폰을 착용하고, 노래는 틀지 않은 채 노이즈 캔슬링 기능만 이용했습니다.

시끄러운 카페에서 연습하다, 이어폰에 노캔을 켜고 작업하니 세상 집중이 잘 되었습니다.

 

4) 과자, 물, 귤, 마이쮸 등 제공

당 보충용 초콜릿을 사갔는데, 간식을 엄청나게 제공해 주셨습니다.

진짜 최고최고..

 

 

그 외

영상으로만 뵈었던 코치님들을 실물로 뵈니 좋았습니다 ㅋ ㅋ

교육장에서 사진, 셀피 찍어도 되냐고 여쭤보니

당연히 된다고 하셨습니다! 일부를 공유합니다.

 

크리스마스 전 주라 테헤란로의 크리스마스 야경을 내려다볼 수 있었습니다.

 

불 꺼진 페어룸..

 

 

 

 

 


 

최종 코딩테스트가 쉽지는 않지만,

프리코스에 열심히 참여하고

코딩테스트 준비에 많은 시간(진짜 많이..ㅋㅋ) 할애하면

자바를 잘 모르던 비전공자도 만족할 만한 결과를 얻을 수 있다고 말씀드리고 싶습니다.

 

파이팅 하세요 🔥🤞

 

 

 

 

 

 

반응형
반응형

썸네일용 테스트 성공 화면. 수고했다 나 자신..

프리코스 4주간의 대장정은 끝이 났고,

전 세계는 프리코스 참가자들을 축하하며 '월드컵'이라는 축제를 열었다(?)

 

늘 다음 미션에 대한 기대감 반, 두려움 반이 공존된 상태로 회고를 적곤 했었는데,

기대와 두려움이 모두 사라진 평온~한 상태로 회고를 적자니 조금 어색하기도 하다.

 

쉼 없이 달려왔기에, 스스로에게 잠깐의 휴식을 주고 싶은데..

미뤄둔 할 일이 많아 쉽지 않다.

 

그런 와중에도, 4주 차 미션을 통해 배운 많은 것들에 대한 기억이 휘발되기 전에

회고를 적으려고 블로그를 켰다.

 

회고 시작시작!

 

 

목차

- 객체를 분리하다 MVC를 깨닫다

- 리팩터링이란 몰까..?

- 자연스러운 TDD

- 예외처리와 자만

- 프리코스 커뮤니티

 

 


객체를 분리하다 MVC를 깨닫다

3주 차에서 MVC 패턴이라는 나에게 어려운 개념을 지워버리고, 객체 간 관계에만 집중했었다.

그러다 보니 나도 모르게 Lotto 클래스와 같은 도메인 로직에서 입출력 클래스를 호출하곤 했다.

스스로의 코드를 읽어보며, 도메인 로직과 UI 로직이 완전히 분리된 것이 아니라는 생각을 했다.

 

이번 4주 차 미션에서는

"BridgeGame 클래스에서 InputView와 OutputView를 사용하지 않는다"

라는 요구사항이 적혀 있었다.

 

도메인과 UI 로직이 서로를 의존하지 않게 하기 위함이라고 생각했다.

그런데.. 도메인의 내용을 출력하거나, 입력을 받아 도메인 로직에서 사용하려면 결국 연결이 되어야 한다.

근데 도메인과 UI는 분리되어야 한다..

..

..

..

그래서 Controller가 생긴 것이구나!

라는 깨달음을 얻었다.

 

사실 대단한 깨달음도 아니고, MVC 패턴 관련 아티클을 정독하다 보면 자연스럽게 알 수 있는 내용이었지만,

아무리 아티클을 읽어도 나에겐 와닿지 않던 내용들이었다.

 

하지만 객체 간 관계, 도메인 로직과 UI 로직이라는 개념, 객체 간 의존 관계 등 객체에 대한 여러 개념을 이해하고 나니,

MVC 패턴이 왜 생겨났고, 어떻게 사용되어야 하는지 이해되었다.

그동안 나는 거꾸로 된 순서로 공부를 하고 있었다..!

 

정말 신기하고 뿌듯한 경험이었다. ⭐️

 

 

 

 

리팩터링이란 몰까..?

이전의 나에게 리팩터링이란 그저 '실수를 수정하는 행위'에 지나지 않았다.

 

하지만 이번 미션의 학습 목표 설명에

"먼저 기능이 작동하도록 구현하고, 리팩터링으로 코드를 개선해 보는 경험"

을 언급하셨다.

 

그 이유가 있을 게 분명했다.

그래서 나는 리팩터링이 왜 중요한지 그 의미를 생각하며 미션을 해결하려고 노력했다.

 

우선 내가 리팩터링을 좁은 의미로 생각한 이유를 고민했는데,

아마 코드를 수정하는 것이 두려워서였던 것 같다.

 

설계 없이 코드부터 냅다 작성하던 과거의 나에게, 코드 수정은 엄청 복잡한 일이었으리라..

하지만 지난 미션들을 해결하며, 유지보수가 훨씬 수월해졌음을 느꼈다.

용기를 갖고 많은 부분을 리팩터링 단계로 넘기리라 다짐했다.

 

그랬더니 생긴 이점들은,

기능 구현 시 흐름이 끊기지 않을 수 있었으며, 고민이 필요한 부분은 리팩터링 단계에서 충분히 고민할 수 있었다는 것이다.

이전에는 기능을 구현하면서 동시에 깊게 고민하고, 찾아보고, 공부하고.. 그러다 보면 프로그램 전체 flow가 헷갈리고..

이런 일이 많았지만,

리팩터링에 많은 부분을 넘기면서 훨씬 수월하게 기능 구현을 마칠 수 있었다.

 

몇 가지 리팩터링 한 부분이 기억에 남는데,

공통 피드백과 피어 리뷰 내용을 적용한 것이다.

공통 피드백의 객체를 객체스럽게 사용하는 방법, final 키워드 사용 방법,

그리고 피어 리뷰에서 배운 String 객체를 리터럴 방식으로 선언할 때의 이점 등을 공부한 후에 코드에 녹일 수 있었다.

 

그리고 30줄짜리 메서드를 10줄로 분리했던 경험도 생생하게 떠오르고, (분기되는 부분, 공통되는 부분을 기준으로 메서드 분리..!)

다리 현황을 기록하는 객체를 Monitor라고 칭했는데, Drawer(다리 그림을 기록하는 객체)와 picture(그림으로 된 다리 이동 기록)로 표현을 수정한 것도 기억에 남는다.

 

 

 

 

자연스러운 TDD

TDD가 자연스러웠다니.. 도저히 믿어지지 않는 일이다.

2주 차 요구사항으로 테스트 작성이 추가되면서, 넌지시 알고 있던 TDD 방식을 적용해보았다.

 

테스트 코드가 기능 구현 시 나침반, 설계도와 같은 역할을 해준다는 사실을 깨달았긴 하지만..

테스트 구현이 익숙하지 않은 채로 TDD 방식을 사용하는 것은 너무 고통스러웠다.

 

그런데 4주 차 기능을 구현할 때는,

아주 자연스럽게.. 테스트 코드에 먼저 손이 갔다.

 

객체와 책임을 먼저 설계했고, 테스트 케이스 구현이 익숙했기 때문에 가능했던 일이라고 생각한다.

추후에 스프링과 같은 프레임워크를 공부하더라도, 처음부터 TDD를 고집하면 굉장히 괴로울 것이다.

하지만, 기본적인 구조와 기능을 익히고 자연스럽게 TDD를 사용할 수 있다면 굉장한 무기가 되어줄 것이라고 생각했다.

 

기본을 공부하며 응용을 깨달은 이 경험이, 앞으로 나의 공부에 좋은 영향을 줄 것이라고 많이 기대된다.

 

 

 

 

예외 처리와 자만

지난 3주 차 미션의 최대 난제였던 "예외 처리 후 프로그램 종료" 문제를 해결한 후,

나는 예외 처리 개념에 통달했다는 자만에 빠졌다.

 

하지만 4주 차 미션의 요구사항

"사용자가 잘못된 값을 입력할 경우 IllegalArgumentException를 발생시키고, "[ERROR]"로 시작하는 에러 메시지를 출력 후 그 부분부터 입력을 다시 받는다."

를 해결하면서 바로 겸손해졌다..

 

3주 차에서 사용한 방식대로,

예외를 최상위 메서드 한 곳에서 처리하는 방식으로는,

입력을 다시 받을 메서드를 호출할 방법이 없었다.

 

예외 처리를 발생하는 각 지점에서 수행하고,

입력 메서드를 재귀적으로 호출함으로써 요구 사항을 만족시킬 수 있었다.

반복문으로 해결하는 방법도 공부를 했지만,

가독성 측면에서 재귀적 호출이 낫다고 판단했다.

 

공부한 내용을 기억하고 + 나누고자 아티클도 작성해보았다.

 

[Java] 예외처리 반복 - 올바른 입력값을 받을 때까지 (try-catch)

프로그램을 작성하다 보면 예외를 처리한 후, 예외가 발생된 메서드를 다시 실행해야하는 경우가 있습니다. 그것을 수행하는 몇 가지 방법에 대해 정리해보고자 합니다. 예외 처리의 기본적인

woojin.tistory.com

 

자만이 깨지면서 느낀 점은..

하나의 지식은 하나의 문제로 얻을 수 없다는 것이었다.

여러 문제를 다뤄봐야 비로소 하나의 깊은 지식이 완성된다는 것을 깨달을 수 있었다.

(책 하나만 읽은 사람이 제일 어설프다 그런 것과도 비슷한..)

 

 

 

 

프리코스 커뮤니티

이번 주에도 커뮤니티로부터 많은 것을 얻으려고 노력했다.

  • 주간 회고록 공유
  • 동료분들의 회고 10개 정독하기 (사실 읽다 보니 20개는 읽은 듯)
  • 피어 리뷰 10개 작성

다만 시간이 좀 부족해, 지난주처럼 토론 글을 모두 정독하지는 못 했다.

 

지난 주차 동안 꾸준히 리뷰에 참여했더니, 리뷰 속도가 많이 개선되었다.

빨리 하는 것이 중요한 것은 아니지만, 기본적인 로직을 이해하는 속도가 빨라지자

다른 곳에서 여유를 가질 수 있었다.

 

지난 리뷰들은 요구사항과 관련된 실수, 네이밍에 관한 조언 등

비교적 단순한 코멘트를 달았다면,

이번 리뷰에서는 객체의 상태가 꼭 필요한지, UI 로직이 잘 분리되었는지와 같은 고차원적인 부분에 대한 의견을 전달할 수 있었다.

무엇보다, 동료분들의 일주일 간의 노고가 깃든 코드에서 빛나는 부분을 찾아볼 수 있는 여유가 생겼고

힘이 되는 칭찬을 드리기 위해 나름대로 노력했다. 그게 참 좋았다.

내가 받은 리뷰를 통해 많은 자신감을 얻었기 때문에, 돌려드리고 싶었기 때문.

 

회고를 읽는 것은 너무 재밌었다.

비슷한 고민이 담긴 글을 보고 위로를 많이 구할 수 있었다.

그리고 내가 해보지 못한 생각들로부터 많은 인사이트를 얻을 수 있었다.

특히, 실수가 두려움의 대상이 아닌 성장의 시작이라는 관점이 크게 와닿았다.

 

 

아쉬운 점이 하나 있었다면..

맞리뷰 오신다고 했는데 잠수 타신 분들이.. (세 분이나..)

늦게라도 와주실 거라 믿습니다 ^^.. 사실 안 믿고요

 

그래도 많은 분들께서 맞리뷰 해주셔서 감사했습니다!

 

 

 

 


끝이라니.. 믿어지지 않고.. 많이 허전하겠지만,

일단 월드컵을 볼 생각에 무척 설레고요,

새롭게 공부를 시작할 생각에도 설렙니다.

 

모두 행복하세요!

 

감사합니다.

 

 

 

 

 

 

 

 

 

 

반응형
반응형

비전공자 && 자바 어린이의 백엔드 프리코스 회고

 

 

지난 주차 소감에, 전례 없이 몰입하겠다고 다짐했던 기억이 난다.

다행히도 이번 주는 그 다짐을 지켰다. 후회가 남는 순간이 떠오르지 않을 만큼 최선을 다 했다.

 

그만큼이나 많은 것을 배우고 느낀 시간이었다. 어느 정도였냐면..

미션 제출 시에 소감을 작성해서 내야 하는데, 명시는 되지 않았지만 글자수 제한이 5,000자라는 것을 누군가 공유해주셨다.

1주차에 그것을 듣고 "5,000자를 쓰는 사람이 있어..? 너무 늘여쓴 거 아닌가.."라고 생각했는데

이번 주의 내 소감 초안은 6,000자였다..

자소서를 다듬듯이 수정해서 글자수를 맞추고 제출했다는..

 

그리고, 여러번 검토해서 실수 없다고 생각했는데 제출하고 보니

"첫째로, 결과를 통해 과정을 돌이켜본다는 것입니다.."

라고 적은 것을 발견했다.

왜 아련한 건데..

 

아무튼 회고 시작!


기술적인 배움

 

클래스(객체) 분리

MVC를 흉내냈던 지난 주차와는 달리, '객체'에만 집중해서 프로그램을 설계했다.

M(model)도 잘 모르면서 MVC를 쓰던 나였는데,

코수타에서 말씀해주신대로 요구사항에 집중해보기로 했다.

(역시 그것만으로도 벅찼다..)

 

'도메인' 로직과 'UI' 로직을 분리하라는 요구사항도 있었다.

'도메인'이라는 단어가 잘 와닿지 않아 따로 찾아보며 공부했고,

'프로그램이 해결하려는 문제, 또는 그것이 속한 분야'라고 나름대로 정의를 했다.

 

객체를 설계할 때는 현실세계의 개념을 차용했다.

프리코스를 진행하며 '객체지향' 개념을 처음 제대로 공부했고,

'객체지향의 사실과 오해'라는 책의 도움을 많이 받았다.

이번 미션에서는, 책에서 배운 내용을 제대로 써먹을 수 있었다.

 

특히, 핵심 책임(행동)을 먼저 떠올리고,

  • 입력한 금액 만큼의 로또를 발행한다.
  • 로또의 당첨 여부를 계산한다.
  • 총 로또의 당첨 결과를 계산한다.

책임을 위해 오고갈 메시지에 집중했다.

 

그렇게 도메인 모델을 설계할 수 있었다.

지금 다시 보니 부족한 부분이 많이 보이지만..

그래도 내가 이런 다이어그램을 손으로 그렸다는 것 자체가 뿌듯했다.

필요한 정보들이 많이 부족할 수도 있지만..

핵심 메시지만 간결하게 담아, 읽히기 쉽다는 장점은 확실히 있는 듯하다.

 

이후에는 기능 구현 목록을 자세히 작성하고, 구현을 시작했다!

 

아무튼, 이렇게 설계에 공을 들이고나서 구현을 시작하니, 거칠 것이 없었다. (사실 많았다..)

 

 

 

 

도메인 로직에 대한 단위 테스트

지난 미션을 통해 '테스트 케이스 구현'에 대해서 익숙해질 수 있었다면,

이번 미션을 통해서는, 테스트의 의미와 설계, 구조와 리팩토링 등 전반적인 실력을 향상시킬 수 있었다.

 

그에 앞서, 지난 주의 나는 public, private, default의 뜻만 알고,

그것을 어떻게 써야하는지 전혀 몰랐다.

 대부분의 메서드가 default로 선언된 것만 봐도 그렇다..

동료분께서 남겨주신 피어 리뷰의 일부.. 접근 제어자를 왜 안 썼냐면.. 몰라서요.. ㅋㅋ......민망..

 

하지만 피어 리뷰와 아고라 정독을 통해 관련 키워드를 공부할 수 있었고,

이번 주에는 public 메서드와 그것을 뒷받침하는 private 메서드를 분리해서 구현했다.

하지만 private 메서드를 어느 범위까지 설정하고, public 메서드 테스트로 대체해야하는지 정확한 감이 없었다.

--> 3주차 공통 피드백에서, private 메서드 사용 범위에 대해 짚어주셨다.. 나름대로 소름이 조금 돋았다..

 

또, 2주차 미션에서는 테스트 코드의 가독성이나 컨벤션을 전혀 고려하지 않았다.

하지만 3주차 미션에서는 구현이 익숙해지니 가독성과 유지보수 같은 것들을 신경쓸 수 있었다.

 

should_기대결과_When_테스트상태 컨벤션으로 메서드명을 수정했다.

물론 DisplayName이라는 어노테이션으로 테스트 케이스 설명을 작성할 수 있지만,

메서드명을 아무 의미 없이 흘려보내지 않고, 직관적으로 이해할 수 있도록 작성하는 것은 의미가 크다고 생각했다.

 

BDD 패턴의 일종인 'given, when, then' 패턴도 적용해보았다.

테스트 코드 가독성 뿐만 아니라, 테스트 케이스의 목적을 스스로 정확히 이해하는 데에도 도움을 주었다.

직관적인 코드는 언제나 득이 된다.

 

 

그리고, 공통 피드백에 언급되었던 내용대로

테스트 코드를 작성하는 이유에 대해 고민해보았다.

 

기능을 빠르게 검증할 수 있어서 구현 당시에도, 리팩토링 시에도 큰 도움을 받을 수 있는 것은

지난 주에 이미 절실히 깨달았다. 그리고 그 외에도 느낀 점이 많았다.

 

첫째로, 결과를 통해 과정을 돌이켜볼 수 있다는 것이다.

기능을 구현할 때는, 내가 알고 있는 이론들로 가설을 세우고 코드로 표현한다. 거기에 더해 테스트 코드를 작성하면, 기능 요구 사항을 토대로 다양한 케이스를 검증할 수 있다. 결과를 토대로 프로덕션 코드의 과정을 되돌아 볼 수 있는 것이다.

 

마치, 경제학의 이론을 세우는 것이 구현이라면, 그것이 시장에서 적용이 되는지 확인하는 것은 테스트와 같다고 생각했다.

테스트를 구현하고 실행하면, 그 즉시 코드의 실용성을 많은 부분 파악할 수 있었고,

부족한 부분, 모순된 부분을 파악해 이론에 적용할 수 있었다.

 

둘째로, 학습을 위한 새로운 도구가 되어줬다는 것이다.

공통 피드백에 있던 내용인데, 테스트를 학습 도구로 사용했다.

기존에는 어떤 자료형과 메서드를 사용해보고 싶으면, 새로운 프로젝트를 만들어 실행시켰다.

여간 번거로운 일이 아니었다.

 

하지만, 테스트 코드로 원하는 기능을 작성하고 실행하면 간단하게 그 결과를 확인할 수 있었다.

거기에다 프로덕션 코드 작성 중 학습 기록을 아주 쉽게 참고할 수 있어 더욱 좋았다..

이런 생각을 여태 못 했다니..

 

특히 이번 미션에서는, 나를 아주 못살게 굴었던 수익률 계산을 연습할 때 큰 도움을 얻었다.

 

Math.round(), String.format() 등 다양한 메서드를 사용하다가

DecimalFormat이라는 녀석을 알게 되었고,

테스트 코드를 통해 쉽게 연습할 수 있었다!

 

 

종합하면,

테스트 코드는 기능을 검증하고, 촘촘한 기능 설계를 도우며, 학습을 위한 도구로도 사용이 가능하다는 것을 깨달았다.

설계, 작성, 학습, 유지보수까지, 개발 전 과정에 걸쳐 지대한 영향을 미치는 것이다!

 

 

 

 

예외 처리

메일로도 공지가 왔던 예외 처리 요구 사항을 구현하면서,

많은 지원자들이 겪던 문제를 나도 동일하게 겪었다.

사용자가 잘못된 값을 입력할 경우 IllegalArgumentException를 발생시키고, "[ERROR]"로 시작하는 에러 메시지를 출력 후 종료한다.

위의 요구사항이었는데,

try catch를 통해 IllegalArgumentException을 발생시키고, 콘솔에서도 확인했지만

테스트가 통과되지 않았다.

 

테스트 코드가 정의된 곳에서 발견한 NoSuchElementException을 발생시키니 테스트 통과는 되었지만,

의도한 바가 아니라는 것을 쉽게 알 수 있었다.

 

아무리 생각해도 방법이 떠오르지 않자.. 그냥 포기할까 생각도 했지만..

나는 프로그램이 종료되는 것이 아니라 '종료한다'는 표현에 집중했다.

 

그 결과! 나의 코드는 프로그램을 종료한 것이 아니라, 비정상적으로 종료된 것임을 깨달았다.

 

예외의 메시지를 출력하고, 예외를 발생시켜서 비정상 종료되는 것이 아니라!

예외 메시지를 출력하고, 더이상 실행할 명령이 없어 자연스럽게 프로그램을 종료하는 그림을 떠올렸다!

그 결과, main 메서드에 try catch를 적용함으로써 문제를 해결할 수 있었다..

 

와.. 이걸 깨달았을 때 카타르시스는 정말 잊을 수 없었다..

그리고 이 과정을 통해 예외처리에 대한 없던 기초가 세워졌다.

내 프로그래밍 인생 처음으로(길지도 않지만 ㅋㅋ), 예외처리 개념을 제대로 이해했다고 느꼈다.. 

(관련해서 블로그 아티클도 적었다!)

 

[Java] 간단한 예외처리(try catch) 원리 (feat. throws IllegalArgumentException은 왜 빨간 줄이 안 생길까?)

예외를 처리하다 보면, 아래와 같은 에러 문구를 쉽게 볼 수 있습니다. 바로 Unhandled exception 입니다. 예외 발생 예외의 종류는 다양하고, 예외가 발생하는 코드도 다양합니다. 본 아티클에서는,

woojin.tistory.com

 

 

 

 

프리코스 커뮤니티

이번 주차 목표 중 하나는, 프리코스 커뮤니티에서 얻을 수 있는 모든 것을 얻는 것이었다.

  • 주간 회고록 공유
  • 동료분들의 회고 10개 정독하기
  • 피어 리뷰 10개 작성
  • 토론 글 전부 정독
  • 토론 글 작성하기

위 내용을 목표로 나름대로 최선을 다해 커뮤니티 활동을 했다.

역시 넘치게 많은 것을 배울 수 있었다..

 

동료분들의 회고에서는, 프리코스를 바라보는 새로운 시각, 기술적인 배움을 구할 수 있었다.

 

피어 리뷰는 정말 기술적으로 크게 성장한 경험이었는데,

리뷰 경험이 거의 없던 나는 타인의 코드를 이해하는 것이 너무 벅찼다..

하지만 리뷰를 계속할수록, 로직을 이해하는 속도가 빨라졌다!

그리고 남의 시선으로 바라본 나의 코드의 문제도 계속해서 떠올랐다..

 

그리고 토론..

아고라 들어가보신 분들은 아시겠지만, 주제랑 의견의 퀄리티가 상당하다..

엄청나게 많은 글이 올라오지는 않지만,

미션 진행하면서 혹은 개발 공부하면서 한 번쯤 고민해봤을 문제를 가지고 의견을 나누고 계신다.

특히 getter의 사용 여부나, 테스트 네이밍 컨벤션에 대해 생각해볼 수 있어서 좋았다.

 

 

 

 

인간적인 배움..

나의 눈물샘을 자극하는 사건이 하나 있었다.

 

피어 리뷰를 나름대로 열심히 남긴 덕에, 많은 분들께서 나의 PR에 찾아와 리뷰를 남겨주셨다.

7분이나 남겨주셨다.. 최고최고

그중 특히 기억나는 리뷰가 있는데..

나를 '고수'라고 칭해주신 어떤 분의 코멘트였다.

 

올해 초, 개발 공부를 처음 시작하고나서

지금까지 단 한 번도 스스로 '잘한다'는 생각을 가져본 적이 없었다.

 

적지 않은 나이에, 나름대로 성취한 것을 다 버리고 새로운 분야에 도전했다.

그만큼 조급했고, 남들과 비교하며 부족한 점에만 집중해왔던 것 같다.

지난 7월에 네이버 블로그에 적었던 글의 일부.

개발 생태계에 입문하고, 계속해서 열등감을 느끼던 나의 모습이 기록되어 있다.

 

근데 저 리뷰 코멘트 한 마디를 보고,

'누군가는 나를 인정해주는구나'라는 생각에 자신감을 많이 얻을 수 있었다.

지나온 날들에 대한 보상을 받는 기분도 들었다.

 

돌이켜보면, 해야 할 일에 집중하기 바빠서 해내온 일들을 흘려보내는 경우가 많았던 것 같다.

가끔은 이렇게 이뤄낸 것도 돌아보며 자신감을 얻을 줄 아는 사람이 되겠다고 다짐했다.

 

그리고 나도 누군가에게 좋은 영향을 줄 수 있도록, 리뷰를 열심히 달겠다고 다짐했다.

이번 주에도 10개의 피어 리뷰를 아주.. 정성스럽게 달아보려 한다..

 

 


이번 주도 무사히.. 행복하다..

 

마지막으로, 이번 한 주도 밀도 높은 성장을 경험하게 해주신 많은 분들께 감사드린다고 말씀드리고 싶다.

아직은 막연하지만, 단단한 철학을 가진 개발자가 된 미래의 모습을 자꾸 그려보게 되는 행복한 한 주였다.

 

한 가지 안타까운 것이..

주차가 거듭될 수록, 지원자들의 PR 수가 떨어지고 있다는 것이다.

 

미션 난이도가 쉽지 않고, 시간 투자도 어느정도 해야하니..

사실 나도 학교, 알바를 병행하며 벅찰 때도 있었지만,

그래도 다른 프로젝트 개발을 미리미리 해둔 덕에, 나름대로 시간과 여유를 확보해둘 수 있었다.

 

하지만 일을 하고 계시거나, 다른 이유로 많이 바쁜 사람들은 미션이 정말 어려울 수도 있겠다는 생각을 했다.

그럼에도, 많은 사람들이 끝까지 함께 하며

많은 것을 함께 배우고 성장하면 좋겠다는 바람이 있다.

왜냐면 내가 성장하는 이 시간이 너무 좋아서.. (맛있는 건 먹어보라고 하고 싶은 것 처럼..)

 

아무쪼록 모두들,

무탈하면서도 크게 성장하는 마지막 주차가 되시길 기원합니다!

 

읽어주신 모든 분들께 감사드립니다.

 

 

 

 

 

 

 

 

 

반응형
반응형

 

비전공자 && 자바 어린이의 백엔드 프리코스 회고

 

 

 

 

 

1주차에 이어 2주차에도 많은 것을 배우고 느꼈다.

그도 그럴 것이 있는 시간 없는 시간 모으고 모아 열심히 몰입하고 있다.

 

그에 비해 얻은 것들을 곱씹을 시간은 적었기에,

기억이 휘발되기 전에 회고를 적어보려 한다.

 

프리코스 1주차 후기 👇👇

https://woojin.tistory.com/60

 

프리코스 1주차 회고 - 더도 말고 덜도 말고 1주차만 같아라~ (우아한테크코스 5기 백엔드 프리코

우테코 프리코스에 그야말로 '몰입'하고 있는 요즘이다. 합격하고 싶은 마음이야 두말할 것도 없지만, 합격 여부를 떠나 이 시간을 통해 올바르게 성장할 수 있다는 확신이 있다. 그래서 아주 마

woojin.tistory.com

 

 


기술적인 배움

 

메서드 분리

함수를 분리하는 것이 이번 주차의 요구사항 중 하나였다.

메서드를 분리하는 버릇은 원래도 (조금) 있었는데,

이번에는 메서드를 분리하는 것이, 어떤 효과를 불러오는지에 집중해보기로 했다.

 

- 코드의 재사용성 증가

작게 분리된 메서드는 다른 곳에서 재사용될 수 있다는 것을 발견했다.

남의 예시 코드가 아닌, 나의 코드에서 직접 발견한 것이라 훨씬 와닿았다.

 

여기서 고민되는 것이 있었는데,

새로운 유틸리티 클래스를 만들어, 서로 다른 클래스 내에서 반복되는 코드를 옮겨야 하나?

라는 것이었다.

 

코드의 반복을 줄일 수 있겠지만,

유틸리티 클래스가 객체지향적 관점에서 어떤 책임을 하는지가 애매했고

많은 클래스가 유틸리티 클래스에 의존하는 구조 또한 좋은 구조인지가 궁금했다.

(-> 관련 내용을 담은 커뮤니티 아고라 링크!(클릭))

 

 

- 코드의 가독성 증가

메서드가 작아질수록 네이밍이 수월했고, 가독성 증가로 이어졌다.

생각해보니, 메서드 규모가 클수록 여러가지 일을 하고 있을 확률이 높으니 네이밍이 어려운 것은 당연했다.

 

 

- 객체지향적인 설계

메서드를 분리하려고 노력하다보니, 자연스럽게 객체에 메시지를 보내게 되었다.

상태를 직접 가져와서 지지고 볶는 것이 아니라, 메시지를 보내고 그 응답을 사용하게 된 것이다.

 

 

 

함수별 테스트

함수별 테스트 또한, 이번 주차 요구사항 중 하나였다.

테스트 코드에 대한 경험이 많이 없어 두려웠지만, 일단 부딪혀보며 배우기로 마음을 먹었다.

 

- 유닛테스트와 통합테스트

미션 기본 파일에 주어진 코드를 보며, 기본적인 테스트 기능을 공부했다.

그리고 바로 테스트 코드를 구현하려했는데, 몇 시간이 지나도 구현이 되지 않았다.

알고 보니, 나는 '통합 테스트'를 구현하고 있던 것이었다..

 

테스트의 정의와 종류를 공부하면서, '유닛테스트'가 뭔지 알게 되었고,

작은 단위부터 테스트하며 테스트에 대해서 조금씩 배워나갈 수 있었다.

 

 

- 어노테이션 활용

BeforeEach를 사용해 각 테스트가 의존하지 않도록 구현할 수 있었다.

Nested로 테스트의 계층 구조를 설계할 수 있었으며,

DisplayName로 테스트 결과의 가독성을 높일 수 있었다.

 

 

- TDD의 첫 적용

테스트 코드를 작성하니, 기능 단위로 성취감을 느끼고

구현에 문제가 없는지 그때그때 확인할 수 있어서 너무 좋았다.

하지만 테스트 코드를 먼저 작성하는 TDD 방식은 너무 아득하게 느껴졌다.

 

미션 구현 중반부 쯤에서는 기본적인 테스트 코드 활용에 자신감이 붙었고,

테스트 코드를 먼저 작성해보자고 마음을 먹었다.

 

개념만 알고 있던 TDD를 직접 적용해보니,

먼저 작성한 테스트 코드가 문제 해결의 나침반이 되어준다는 느낌을 받았다.

 

하지만 해당 메서드에 대해 테스트 케이스를 완벽하게 구현할 수 있는 게 아니라면,

확실히 어렵겠다는 생각을 했다.

 

테스트 코드의 실력을 늘리면서, 차차 익숙해져보는 것을 목표로 해야겠다.

 

 

테스트 코드를 공부하면서,

한 번 잘 짜놓은 테스트 코드가 디버깅 시, 리팩토링 시 얼마나 많은 단계를 줄여주는 지 체감할 수 있었다.

이제 테스트 없는 개발은 불가능하다.. 초록 불빛에 중독되어 버렸기 때문..

보기만 해도 기분이 너무 좋네요..

 

 

가장 익숙한 언어가 된 자바

출처 : 데브경수(https://www.instagram.com/waterglasstoon/)

자바의 존재를 처음 알게된 것은 위의 짤이었다.

파이썬으로 개발 공부를 시작한 나는,

이유도 잘 모르고 여러 사람들의 농담 섞인 말에 휘둘려

자바가 꼰대 같고, 딱딱하고, 재미가 없을 거라는 편견을 가지게 되었다..

 

그래서 자바를 처음 공부했을 때는 다른 언어에 비해 두려웠다!

 

그런데 지금은..

불과 2주만에 자바는 나에게 가장 익숙한 언어가 되었다.

체계적으로 공부를 시작한 첫 언어이기 때문도 있는 것 같고..

 

이제는 어떤 문제를 해결하려고 생각하면,

자바 언어로 추상화된 객체를 먼저 구상하게 되고,

자료형과 메서드도 떠오른다.

 

이제 자바 없는 나를 떠올릴 수 없다(?)

자바를 꽉 자바야겠다. ㅋ

 

 

프리코스 커뮤니티

언급하지 않을 수 없다.. 정말 많은 도움을 얻고 있기 때문.

얼굴 한 번 본 적 없는 동료들과 함께 걸어가고 있는 기분이다.

 

- 피어 리뷰

이번 미션을 마치고는 피어 리뷰에 집중해보고 싶었다.

리뷰 경험이 거의 없는데다, 사실 남의 코드를 읽고 공부해본 경험도 많이 없다.

남의 코드를 읽는 것이 어색하다.

그래서 경험을 쌓기 위해서라도 피어 리뷰에 집중해보고 싶었다.

 

9~10명 정도의 피어 분들께 리뷰를 남긴 것으로 기억하는데,

리뷰가 거듭될수록 코드를 읽는 실력이 올라감이 느껴졌으며,

처음에는 보이지 않던 부분들이 보이기 시작했다.

 

피어 리뷰는 도움을 주면서, 동시에 나도 도움을 구해가는

정말 좋은 시간이었다.

 

 

- 북클럽 가입

지원자 한 분께서 기획해주신 북클럽에 가입했다.

읽고 있는 책에서 얻은 인사이트를 서로 공유하는 모임이다.

 

개발 관련 서적이 많은데, (나는 객체지향의 사실과 오해.. ㅋㅋ)

다른 분들은 글쓰기나 좋은 개발자가 되는 방법에 대한 고민이 담긴 책까지

다양한 책을 읽고 계신다.

 

북클럽까지 참여하실 정도로 우테코에 진심인 사람들과 교류할 수 있게 되어 기쁘다.

 

 

- 아고라

프리코스 커뮤니티 중 '깃허브 디스커젼'에는 아고라 카테고리가 있다.

프로그래밍 중 생각난 쟁점에 대해 공유하고,

다양한 의견을 나누는 장소이다.

 

정말 많은 것을 배우고 있다.

 

지식적인 부분도 많이 배웠지만,

참여자들이 의견을 교류할 때 갖추는 태도(예의, 설득 방식 등)도 배울 점이 많고,

어떤 쟁점들은 하나의 결론으로 모이지 않고, 다양한 의견이 존재한다는 것도 흥미로운 지점이었다.

 

 

 

 


인간적인 배움

 

지속가능한 페이스

프리코스를 시작하면서, 4주 동안 미친듯이 몰입하자고 마음을 먹었다.

사실 그 전 주부터 몰입했으니 총 5주인 셈이다.

 

그런데 이번 주는 약간의 번아웃을 겪었다.

아무리 용을 써도 머릿속이 하얘졌다.

 

생각해보니, 지난 2주 반 동안 한 순간도 쉬지 않았다..

다음 할 일을 위한 잠깐의 쉬는 시간 외에는, '쉬는 시간'이라고 규정된 시간 자체가 존재하지 않았던 것이다.

 

내가 좋아하는 러닝에서,

기록을 위해 가장 중요한 것은 '지속가능한 페이스'를 유지하는 것이다.

하지만 나는 10km를 달려야 함에도, 1km 밖에 가지 못 할 페이스로 전력질주를 하고 있었다.

잠시 모든 것을 내려 놓고, 잠깐의 휴식을 가졌다.

금방 회복했고 다시 몰입할 수 있었다.

 

4주는 짧지 않고, 남은 2주도 결코 짧은 시간이 아니라고 생각한다.

하루, 이틀만 바라 보고 내내 밤을 새기 보다는 (물론 4주차에는 그럴 예정 ㅋㅋ)

2주라는 기간이 최대의 퍼포먼스를 가질 수 있도록 노력해야겠다.

그리고 그것이 10개월이라는 긴 시간 동안 몰입하기 위한 연습이 되어줄 거라는 기대감도 든다.

 

 

요구사항에 집중하자! - 나만의 페이스

아 그리고 꼭 기록하고 싶은 것이 있는데,

요구사항에 집중하자는 것이다!

 

이번 코치들의 수다 타임(코수타)에서

남들이 말하는 어려운 키워드에 신경쓰지 말고

요구사항에 집중하라는 말씀을 해주셨다.

 

나도 모르게 TDD, 객체지향 생활체조 등..

남들이 얘기하는 키워드들을 따라가려고 애썼던 것 같다.

마치 공원에서 러닝할 때, 내 옆을 지나가는 고수를 따라가려고 스퍼트를 내듯이..

그럼 2~300m도 가지 못해 지치고 만다는 것을 안다.

 

나는 자바를 거의 처음 공부하는 자린이고,

객체지향이나 자료구조 수업도 들어보지 못한 비전공자라는 사실을 인정하자.

미션의 요구사항에 집중해서 프로그램이 의도하는 방향대로 성장하는 것을 목표로 하겠다!

는 다짐이 너무 중요한 것 같아 기록해둔다.

 

저 초록색 숫자가 뭐라고.. 이리 기분 좋은지..

 

 

 

마지막으로 미션 제출 소감에도 적었지만,

이번 한 주도 지원자들의 성장을 위해 힘써주신 많은 분들께 감사의 인사를 전하고 싶다.

덕분에 프로그래밍이 더 재밌어지고 있음에 너무 감사하다.

 

 

 

 

 

 

 

 

 

 

 

반응형
반응형

 

 

우테코 프리코스에 그야말로 '몰입'하고 있는 요즘이다.

 

합격하고 싶은 마음이야 두말할 것도 없지만,

합격 여부를 떠나 이 시간을 통해 올바르게 성장할 수 있다는 확신이 있다.

그래서 아주 마음 편히 몰입하고 있다.

 

많은 지식을 머릿 속에 집어 넣고 있고, 많은 영감을 얻고 있다.

하지만 아쉽게도, 사유할 시간이 길지 않아 많은 것들을 흘려보내고 있다.

 

이번 우테코 프리코스는, 주차 별로 미션을 제출하면서 '소감'도 적어야 한다.

코치님들께서 설계하신 의도대로 운영되는지를 확인하기 위함도 있겠지만,

머릿 속에 들어온 지식, 과정에서 느낀 여러가지 것들을 한 번 씩 되짚어보라는 의미도 있을 것이라고 생각한다.

 

어쨌든 소감을 적어서 제출한 김에,

살을 조금 붙여서 미래의 나를 위한 회고를 적어보고자 한다.

아주 편~한 마음으로..

(사실 합격해서 이런 실력의 사람도 붙었구나.. 라는 메시지도 주고 싶은 마음이 간절하다.)

 

 

 


여태 자바를 공부했던 경험은

- 위키독스 '점프 투 자바' 1회독

- 인프런 스프링 무료 강의 따라하기

두 가지가 전부였다.

 

객체지향 개념도 아티클 몇 개를 찾아보고 타입스크립트, Nest.js 코드에서 임의로 적용해본 경험이 다였다.

완벽하게는 아니지만, 타입스크립트로 메서드를 분리하려고 노력해봤던 경험도 있었다.

 

 

그런 배경으로 시작해, 일주일간 어떤 것을 공부하고 어떤 것을 느꼈는지 적어보겠다!

 

 

 

자바 복습

그마저도 다 까먹은 자바 문법을 떠올리기 위해 점프 투 자바를 다시 1회독했다.

내용이 풍부하진 않지만, 빠르게 문법을 익히고 객체지향 개념을 겉핥기하기에 아주 좋았다.

다만 오래 함께할 기본서 한 개의 필요성도 느꼈다.

 

 

객체지향 공부

전공자라면 으레 듣는 객체지향 프로그래밍과 같은 과목을 수강하거나, 따로 공부해본 경험이 없었다.

구글링으로 아티클 몇 개 읽어본 어설픈 지식이 전부였다.

 

1주차 미션에는 객체지향 관련 규칙이 없었지만,

자바가 워낙 객체지향에 초점을 맞춘 언어이고, 앞으로의 미션에서 필요할 것이라고 생각해 객체지향을 공부했다.

 

객체지향의 사실과 오해 라는 책을 읽으면서 인터넷 아티클로 객체지향 개념(상속, 캡슐화, 추상화), SOLID 원칙 등을 찾아보는 식으로 공부했다.

 

객체지향의 사실과 오해 라는 책은 정말 좋았다.. 객체지향의 필요성, 각 개념에 대한 이해에 진짜 많은 도움이 되었다.

아직 책을 읽는 중이고, 각 개념에 대해 코드로 설명하지는 못할 것 같다.

프리코스를 진행하면서 꾸준히 공부해, 4주 후에는 객체지향을 마스터하겠다는 각오를 다진다.

 

 

프리코스 문제

1주차 프리코스는 7개의 문제를 해결하는 형식이었다.

각 문제들은 코딩테스트 형식을 띄고 있었다.

 

나는 코딩테스트 경험은 없고, 유튜브 강의로 공부하고 문제 조금 풀어본 경험만 있었다. (백준 실버4 수준)

 

알고리즘 지식이 부족해서 정확하지는 않을텐데,

아마 어려운 알고리즘을 사용하는 문제는 없었던 것 같다. (브루트 포스 정도..?)

 

다만 구현 로직 자체가 (나에게는) 엄청나게 까다로웠다.

특히 6, 7번을 처음 훑어봤을 때는, 일주일 안에 풀 수 있을까하는 걱정이 마음에 툭 얹혀버렸다 ㅋㅋ

 

하지만.. 하루종일 붙잡고 씨름하다보니

문제가 풀리긴 풀렸다!

 

자료구조에 대해서 지식이 부족하다 보니, 비효율적인 코드를 짠 것 같았다.

(사실 비효율적인지 판단하기도 쉽지 않았다.)

 

그래도 자바로 처음 '프로그래밍'을 해보았고,

내가 정말 어렵다고 생각한 기능을 어찌저찌 잘 구현해냈다는 것이 너무 기뻤다.

 

그리고 정말 신기했던 것이, 객체지향을 이론으로 공부하던 것들이 머리에 남아

코드를 짜는 내내 그것을 고려하게 만들었다는 것이다.

다만 이것이 객체지향의 여러 원칙들을 만족하는지 확인하기가 어렵다.

 

다가올 2주차부터, 1주차의 코드에 대해 토론하는 커뮤니티가 열린다.

그곳에서 다른 사람들은 코드를 어떻게 객체지향적으로 구현했는지 확인하고 싶은 마음이 크다!

 

 

기술적으로 배운 것들

1) 객체지향을 이론이 아닌 코드로 처음 적용

자바 문법만 공부할 때는, private, public이 어떤 의미인지 하나도 이해가 안 됐었다.

그런데 객체지향을 공부하면서 코드를 구현하다보니, 자연스럽게 그 의미가 파악이 되었다.

변하지 않는 멤버 변수에 private final static을 사용하면서 은닉화, 캡슐화 개념도 이해할 수 있었다.

 

2) 정규식 처음 사용
제한 사항을 예외 처리할 때, 정규식을 사용해서 간단한 로직으로 구현했다.

정규식을 처음 사용해봤는데,

글자수 제한, 한글만 가능, 영어 대소문자, 일부 특수문자 허용, 이메일 도메인 필수 등

다양한 제한 사항들을 하나의 문자열로 검증할 수 있는 강력함이 너무 신기했다.


3) List, Set, Map 객체에 대한 이해

List, Set, Map이 어떤 용도로 사용되는지는 알고 있었지만,

ListArrayList의 차이, 
좌변에 상위 타입으로서 선언해야 의존관계 역전이 일어나지 않는다는 것 등을 처음 알게 되었다.

 

관련해서 공부한 내용을 아티클 시리즈로 작성했다. (링크👇👇)

 

인터페이스와 구현체 - 무조건 이해되는 List와 ArrayList의 차이(1)

10분만 이 글에 투자해주시면 List, ArrayList, 인터페이스, 구현체 이해시켜드리겠습니다.. (지적은 언제나 대환영입니다.) 본 아티클 시리즈를 정독하면, 아래 의문에 답을 얻을 수 있습니다. 1. 인

woojin.tistory.com

 

ArrayList를 List로 선언하는 이유(업캐스팅) - 무조건 이해되는 List와 ArrayList의 차이(2)

10분만 이 글에 투자해주세요. ArrayList를 List로 선언하는 이유를 이해시켜드리겠습니다. 본 아티클 시리즈를 정독하면, 아래 의문에 답을 얻을 수 있다. 1. 인터페이스와 구현체가 무엇인가? (List

woojin.tistory.com

 

Set과 HashSet, Map과 HashMap의 차이 - 무조건 이해되는 List와 ArrayList의 차이(3)

(지적은 언제나 대환영입니다.) 본 아티클 시리즈를 정독하면, 아래 의문에 답을 얻을 수 있습니다. 1. 인터페이스와 구현체가 무엇인가? (List와 ArrayList의 차이) (클릭🔗) 2. ArrayList가 아닌 List 타

woojin.tistory.com

 

추상클래스란? 아니, 추상이란? - 무조건 이해되는 List와 ArrayList의 차이(4)

추상이 도대체 뭔 소린지 모르겠는 코린이 && 자린이 && 비전공자(== 나) 여러분께 바칩니다.. (지적은 언제나 대환영입니다.) 본 아티클 시리즈를 정독하면, 아래 의문에 답을 얻을 수 있습니다. 1.

woojin.tistory.com

 

 

4) 가변 문자열을 StringBuilder 타입으로 처리
문자열을 수정해야 되는 문제가 있었다.

처음에는 String → List<String> → String 의 순서로 변환해서 가변 문자열을 처리했는데,
List<String>에서 너무 많은 String 객체를 생성해야 하는 문제가 있었다.


후에 StringBuilder 타입을 활용할 수 있다는 것을 알게 되면서,

해당 문제 코드를 리팩토링하며 적용해 보았다.

전보다 훨씬 짧고 간결한 코드로 구현이 가능했다.

형변환 과정을 거치지 않아도 되고, 많은 String 객체를 구현할 필요도 없었다.

 

5. 이름과 점수를 가지고 있는 객체의 리스트 구현

이번 주차 미션을 진행하면서, 가장 뿌듯했던 순간이었다.

 

대략 [(이름, 점수), (이름, 점수)] 형식의 리스트가 필요했다.

처음에는 List<List<Object>> 타입으로 구현했는데, 값을 꺼낼 때마다 int나 String으로 캐스팅해 주어야 하는 문제가 있었다.

정렬할 때 sorted(Comparator.comparing()) 을 사용했는데, 그 안에 들어가는 코드도 무척 복잡했다.

 

관련 내용을 검색하면서, (이름, 점수)를 하나의 클래스로 묶는 방법에 대해 알게 되었다.

정확히는 이름, 점수를 클래스 변수로 갖는 새로운 클래스를 구현했다.

형변환의 문제는 당연히 사라졌고, 값을 꺼내거나 변경할 때 해당 클래스의 메서드를 사용하여 객체지향적으로 구현할 수 있었다.


6) 깃 + 코드 설계
기존에는 주로 혼자서 보는 용도로 커밋을 기록했는데,
이번 프리코스 1주차에는 협업 상황을 가정하고, 기능 단위 별로 커밋을 나눠보았다.

확실히 스스로 PR로 코드를 리뷰할 때 보기가 수월해졌다.

다음 주차에 커뮤니티를 통해 1주차 코드에 대해 리뷰를 받아볼 예정인데, 그때 빛을 발하지 않을까 생각하고 있다.

(근데 커밋을 너무 상세하게 나눠서, 다른 사람들은 어떻게 나눴는지 너무 궁금하다.)


또 기존에는 다짜고짜 개발부터 시작했었는데, 기능 설계를 먼저 하고 개발을 진행하는 방식을 연습해보았다.

처음에는 까다롭고 감을 잡기가 어려웠지만, 구현을 하면 할수록 설계도가 있어 올바른 방향으로 계속 구현할 수 있었다.

 

 

아쉬웠던 점, 부족한 부분

1) 자료구조와 자바 언어에 대한 깊은 지식

여러 언어를 돌면서 공부하다가, 자바를 처음 깊게 공부하고 있다. 공부할수록 자바에 대한 편견(꼰대같은 언어 등..)이 깨지고 그 매력을 알아가고 있다. 자바 생태계에 일원으로 안전하게 정착하고 싶다.

 

2) 객체지향에 대한 이해

객체지향의 개념에 대해서 하나하나 깨달아가는 과정이었다. 하지만 확실하게 이것이 객체지향적인 구현이다! 라고 정의하고 구현하지는 못하고 있다. 프리코스 기간 내내 객체지향을 열심히 공부해야겠다고 다시 다짐한다.

 

 

커뮤니티

이번 우테코 프리코스는 슬랙깃허브를 통해 커뮤니티를 운영한다. 깃허브 커뮤니티는 2주차부터, 1주차 미션 코드에 대해서 진행되기 때문에, 1주차에는 슬랙만 운영되었다.

그런데, 정말 많은 사람들이 자발적으로 정보를 공유하고 서로의 성장을 응원하고 있었다.

어느 필드에서 이렇게 경쟁자끼리 서로의 성장을 응원하고 도움을 나눌 수 있을까 싶었다

정확히는 경쟁보다는 상생, 같이 성장한다는 생각이 더 지배적인 것 같다.

지식 공유의 가치를 아는 사람들과 잘 설계된 미션을 함께 공부하는 시간이 너무 소중하게 다가왔다.

 

 

우테코 너무 가고 싶다..

입에 발린 소리일까봐 미션 소감에는 적지 않았는데,

정말 내가 꿈꾸던 교육 방식이 그대로 현실이 된 느낌이었다..

 

어려서부터 고민 없이, 소통 없이 암기하는 교육 방식이 너무 맞지 않았다.

때문에, 중고등학교 시절에는 책과 인터넷 강의로 독학을 했다.

대학에 와서도 이어지는 주입식 교육이 버거웠고,

다양한 분야를 돌면서 혼자서 공부해왔다.

 

주도적으로 공부하는 것은 늘 즐거웠으나,

치명적인 문제가 있었다.

 

좋은 환경을 조성하기가 어렵다는 것이다.

 

스스로 동기를 부여할 수 있고,

스스로 찾아보고 이해할 수 있어도,

가끔 잘못된 방향으로 나아갈 때 잡아줄 존재가 없고

과정을 함께 이겨낼 든든한 동료도 없다는 것이 늘 힘들었다.

 

 

하지만 고작 프리코스 1주차만 경험했음에도,

많은 고민이 해소되는 기분이 들었다.

 

학습의 방향, 목적지가 주어진다.

하지만 두 발로 걸어갈 지, 네 발로 기어갈 지, 자전거를 타고 갈 지는 스스로 정해야 한다.

과정에서 어느 방법이 효율적일지 같이 고민하고, 힘들 때 서로에게 기댈 동료가 있다.

 

만약 우테코 본 과정에 합격해서

크루원들과 대면하고 가까워져서 의지할 수 있는 관계가 된다면,

20년을 공부하면서 느꼈던 갈증이 해소될 수 있겠다는 생각을 했다.

 

 

 

너무 뿌듯했던 순간..

 

 

마지막으로, 많은 사람들이 이런 좋은 경험을 할 수 있게 힘써주신

많은 코치님들께 진심으로 경의를 표합니다..

남은 주차도 많이 배우고 성장하겠습니다.

 

 

다음 주도, 더도 말고 덜도 말고 이번 주차만 같이

많은 것을 배우고 느끼는 한 주로 만들 것이다.

 

회고 끝~!

 

 

 

 

 

 

반응형

+ Recent posts