4주차 미션 : 크리스마스 프로모션
0. 4주차 미션에 앞서
이번에도 저번 주차 미션에 대한 피드백을 가장 먼저 살펴보았다.
[3주차 공통 피드백 중]
📍 예외 상황을 모두 고려해보기 :
제시한 예외상황에서 내가 하나 놓친 것이 있어서 따로 리펙토링으로 추가할 예정이다.
📍 객체의 상태접근을 제한한다 :
필드는 private class로 구현한다.
외부에서 접근을 최소화하는 이유에 대해 찾아보기!
📍 객체는 객체스럽게 사용한다 :
비즈니스 로직을 갖춰야함.
- 예를들어
당첨 숫자가 몇개 일치하는지, 보너스 숫자가 포함되어있는지에 대한 로직은 로또 객체 내에서 해야한다.
로또에서 데이터를 꺼내지 않고 메세지를 던지도록 구조를 바꾼다.
-> 이 부분은 나도 고민했었고 피드백 대로 판단해 해결해서 다행이라고 생각했다.
📍 필드의 수는 최소로! :
총상금 및 수익률을 계산하는 부분에서 result라는 하나의 필드만으로 구현 가능하다
-> 이 부분은 내가 리팩토링을 통해 고쳐야겠다고 생각했다.
나도 총상금 구하는 부분에 필드를 엄청 많이 설정해놓았기 때문이다..!
📍 테스트코드도 코드이기에 개선해나가야한다 :
중복을 줄이는 코드로 고쳐보자
📍 테스트를 위한 코드는 구현 코드에서 분리해야한다 :
테스트만을 위한 코드는 안된다!
-> 여기서 준 예시처럼 나도 테스트를 위한 코드를 구현한 것이 있어서 아차싶은 마음으로 읽었던것같다.
나도 랜덤때문에 로또 단위테스트를 하기 어려웠는데 정확히 그 부분으 꼬집어서 예시로 설명해주어서 반가웠다.
이 부분을 참고해서 앞으로 리팩토링을 해나가면 좋을것 같다.
또 이 부분은 아직 이해가 부족하고 더 학습해야할 것 같다!
내가 고민했던 부분에 대한 피드백이 나와서 더 흥미롭게 봤던것 같고 이번 미션에 최대한 반영하려 노력했다!
1. 과제 요구 사항
기능 요구사항 간단 요약
개발팀에 의뢰를 하는 듯한 메일 형식으로 미션을 제공해주어서 재미있게 읽었다.
[할인]
1. 디데이할인 - 12/1-25까지 1000원부터 매일 100원씩 할인 금액 증가
2 .평일(일-목)할인 - 디저트 개당 2023원 할인
3. 주말(금토)할인 - 메인 개당 2023원 할인
4. 특별 할인 - 매주 일, 크리스마스 당일(=달력에 별표)에는 1000원 할인
[증정]
5. 증정 이벤트 - 할인 전 금액이 총 12만원 이상이면 샴페인 1개 증정 (샴페인 금액이 혜택 금액에 포함되어야 함)
6. 이벤트 배지 - 5천원 이상 별, 만원 이상 트리, 2만원이상 산타
[주의사항]
총주문금액 만원 이상부터 이벤트 적용
음료만 주문 불가
최대 메뉴 20개까지 주문 가능(음료 포함)
[이벤트 플래너의 역할 = 프로젝트에서의 나의 역할]
고객들이 먼저 날짜, 메뉴를 선택하면(입력받기)
-> 주문메뉴, 할인 전 총금액, 증정메뉴, 혜택 내역, 총혜택금액, 할인 후 예상 결제금액, 12월 배지를 보여줌. 끝.
추가된 요구사항 정리
제공되는 InputView, OutputView 객체를 활용해 구현한다.
🚨 저장소를 비공개로 생성하고 우테코 계정을 collaborator로 초대하기!
🚨 main 브랜치 사용
2. 미션 진행의 흐름 별 기록하고 싶은 부분
※ 새롭게 학습하고 적용한 부분에는 (<- 🆕✨) 마크
✅ 미션 분석 및 기능 명세서 작성
이번 미션도 저번주 로또처럼 2회의 사용자 입력이 필요한 경우였다. 하지만 저번과 다른 점은 입력을 한번에 받고 그 다음에 합쳐서 비즈니스 로직을 돌려야 한다는 점이었다. 그리고 비즈니스 로직이 이전과는 비교도 안될만큼 많고 복잡하다고 느꼈다. 날짜와 메뉴 모두를 고려해 로직을 꾸리는 것도 꾸리는 것이지만, "중복 혜택을 최대한 많이 적용하는 것이 목표에요~"라는 미션 메일의 말처럼 할인 혜택의 종류가 4가지에다가 증정 이벤트도 있고 배지 이벤트도 있었다. 너무 복잡해서 미션 소개 내용을 읽고 코드의 방향성을 분석하는데만 해도 하루가 걸린 것 같았다. 자세한 분석은 아래 controller 부분이나 order클래스 부분의 설명에서 제대로 하겠다.
✅ 메뉴판의 내용을 enum으로 저장하기
이번에는 새롭게 메뉴판의 내용이 주어졌다. 단순한 상수가 아닌 각각의 정보가 묶여 있는 조금 복잡한 자료라고 판단했다. 이때 열거형 상수라고 볼 수 있는 enum을 적용해보았다. 사실 자바스크립트에는 enum이라는 개념은 없다. 그렇기 때문에 enum을 흉내낸 코드인데 그럼에도 이렇게 사용한 이유는 어쨌든 상수처럼 분리해서 모든 값들을 모아두고 써야하기 때문이었고, enum이라는 이름 자체로 열거의 뜻을 담고 있어 나의 의도를 잘 드러낼 수 있다고 판단했다. 또 하나의 변수에 대한 고정값으로 사용해 자동완성으로도 에러도 줄이고 편하게 사용할 수 있었다.
더 나아가 Object.freeze의 사용으로 객체의 프로퍼티를 변경을 막아 그 속성들의 불변성을 보장해주었다.
✅ 예외 클래스 생성: 클래스 상속 (<- 🆕✨)
이전에는 예외 사항들을 하나하나 알려주지 않았었던 반면 이번에는 여러가지 예외사항을 직접 예시로 들어주며 에러메시지까지 지정해주었다. 정확하고 구체적인 요구사항이 오히려 더 편하고 반가웠다. 미쳐 내가 생각하지 못한 예외사항도 미리 말해주니 말이다. 아무튼 요구사항을 보니 하나의 입력에 같은 에러메세지를 출력한다는 것을 알 수 있었다.
이전에 내가 스스로 예외처리를 구현할 때는 예외 사항마다 다른 에러메세지를 출력해 사용자가 옳은 입력을 할 수 있도록 유도했었다. 예를들면 "문자가 아닌 숫자만 입력해주세요" 혹은 "빈칸이 있으면 안돼요" 같은 식으로 말이다. 하지만 이번에는 "유효하지 않은 날짜입니다."와 "유효하지 않은 주문입니다." 2가지 종류로 구현해달라고 되어있었다.
에러메세지 종류가 2가지밖에 없으니 상수로 만들어서 바로바로 사용하면 좋겠다! 라고 처음에 생각했었던것 같다. 하지만 로직이 더 간단해져서 그런지 다른 생각이 이것저것 나며 코드리뷰때 예외만을 다루는 파일을 만들어 그 곳에서 에러메세지를 따로 관리하는 방식을 추천 받았던 것이 떠올랐다.
자료 조사를 하고 인터넷에 검색을 하며 수십가지의 방법을 마주했고 그 중 내가 아직 사용해보지 않은 클래스 상속에 대해 공부하고 적용해보기로 했다.
원래 throw new Error()를 사용해 Error 클래스를 사용했는데 class InputDateError extends Error {}라는 에러 클래스를 상속받는 에러를 담당하는 클래스를 새로 만들었다. 따라서 예외 처리 후 에러메세지를 출력해야하는 부분에 Error대신 새로 만든 InputDateError, InputMenuError 두 클래스를 호출하기만 하면 된다! 그럼 그 클래스에서 알아서 부모(에러)의 생성자를 호출해 메세지까지 던져주게 만들었다.
✅ controller: 번호 매겨서 순서대로 프로그램 실행
프로그램의 목차의 느낌이라고 생각하니 더 와닿았다.
- 주문을 생성한다 - 사용자의 입력을 통해 Order 클래스 생성
- 할인 혜택을 적용한다
- 증정 메뉴를 준다 - 할인 혜택 총 가격에도 반영시켜야함
- 알맞은 이벤트 배지를 준다
- 결과를 출력한다
이렇게 설계하고 순서대로 어떤 클래스의 어떤 메소드를 만들어야할지 판단했다.
실제 완성 된 controller
export class ChristmasController {
async start() {
// 1. 주문 생성(날짜 및 메뉴 입력): Order 생성
const order = await InputView.readOrder();
// 2. 할인 혜택 적용
order.discount();
// 3. 증정 메뉴 주기
order.giveRewardItem();
// 4. 이벤트 배지 주기
order.giveEventBadge();
// 5. 결과 출력
const orderDto = order.makeOrderDto();
OutputView.printOrderDto(orderDto);
}
}
✅ 입력 에러 시 재실행 로직을 새로운 방식으로 적용 (<- 🆕✨)
이전에는 아예 인풋을 받는 곳에서 try-catch문을 사용 해 검증에 실패하면(=입력 에러 시) catch문으로 에러를 잡아서 던지고 재귀로 한 번 더 같은 함수를 호출해주는 방식으로 구현했었다.
// 이전 미션의 재실행 코드
async #inputWinningNumbers() {
try {
const input = await Console.readLineAsync(
MESSAGE.INPUT_WINNING_NUMBER
);
this.#inputValidator.validateWinningNumberInput(input);
return this.#inputConverter.convertToWinningNumbers(input);
} catch (error) {
//검증 실패 시 재실행하기위해
this.#printError(error);
📍 return await this.#inputWinningNumbers();
}
}이번 미션에는 아예 재실행 로직만을 분리해 함수로 만들어주었다. 훨씬 가독성도 좋고 함수의 기능을 훨씬 촘촘하게 가져갈 수 있다는 장점이 있었다. 1함수 1기능!!!
// 1. 재실행 함수 생성
async retryIfError(callback) {
while (true) {
try {
// 성공하면 그대로 리턴
return await callback();
} catch (e) {
// 실패하면 에러 찍고 다시 while문 또 돌것이다!
Console.print(`${e.message}`);
}
}
},
// 2. 사용
// 위에서 만든 재실행 함수의 인자로 콜백을 받는데
// 그 콜백 안에 재실행해야 할 함수를 넣어서 사용
async readOrder() {
Console.print(HELLO_MESSAGE);
📍 const day = await this.retryIfError(this.readDate);
📍 const menuItems = await this.retryIfError(this.readMenus);
return new Order(day, menuItems);
},✅ 고민이 많았던 가장 메인 Order 클래스!
처음에는 Order 클래스를 만들 생각을 안하고 일단 controller에서 역할 별로 함수 4,5가지를 만들어 흐름을 제어 할 생각이었다. 하지만 그러다보니 controller에 너무 많은 비즈니스 로직이 노출되고 도메인과의 경계가 모호해진것같았다.
그래서 역할 별로 묶은 함수를 순차적으로 실행하되, controller 말고 다른 곳에서 해주면 어떨까 하는 생각이 들었다. 그렇게 만든 것이 order 클래스였다. 또한 OrderDto를 생성해서 사용자가 입력한 날짜, 메뉴를 기반으로 생성한 여러 데이터들을 한번에 모아서 출력하는 outputView에 전달할 수 있게 했다. 결국 Order 클래스는 모든 데이터를 하나하나 모으고 그것 중 출력에 필요한 데이터를 dto로 만들어 넘기는 역할을 한다.
order클래스의 예상 역할을 크게 분류해서 3가지의 매서드로 쪼갰다.
- 할인을 적용해주기 (
discounter())- 증정 메뉴를 주기 (
giveRewardItem())- 이벤트 배지를 주기 (
giveEventBadge())
또 여기 Order클래스에 모~든 비즈니스 로직을 다 짤 수는 없었다. 다 짜면 거의 300줄에 가까운 파일이 될 것이고 하나의 클래스가 너무 많은 역할을 안고 있어서 코드의 가독성도 떨어지고 클래스의 전문성도 떨어진다고 생각해 좋지 않다고 판단했다.
첫번째로 할인을 적용하는 discounter()에서는 다시 할인만을 전문적으로 할 Discounter라는 객체를 만들어 로직을 위임했다. Discounter에 할인에 필요한 모든 데이터를 친절하게 같이 넘겨주었다.
두번째로 증정 메뉴와 관련된 데이터를 giveRewardItem()에서 처리했는데 간단하기 때문에 위임은 딱히 하지 않았다. 샴페인 메뉴를 rewardItem에 담고, 그만큼의 금액을 혜택 금액에도 반영을 해주는 로직이다.
세번째로 이벤트 배지에 관련된 로직은 giveEventBadge()에 담았다. 근데 이 부분도 아예 깔끔하게 EventBadge라는 클래스를 만들어서 모든 로직을 거기서 처리한 후 데이터만 갖고왔다.
또한 마지막에 order DTO를 만들 때에도 메뉴 DTO는 MenuItem에 메서드를 추가해 생성해 가져오고, 금액 관련 DTO는 PriceDeatil 클래스의 메서드에서, 혜택 관련 데이터의 DTO는 RewardDetail 클래스 메서드에서 각각 해서 가져왔다. 이렇게 각각에 위임해 각자 본인의 데이터를 직접 처리하도록 해 코드의 응집도를 높이고 가독성 좋고 간결하게 만들었다.
✅ EventBadge의 비즈니스 로직의 수정 (if -> filter)
처음 EventBadge에서 비즈니스 로직을 구현할 때 if문을 3번씩 써가면서 '혜택금액이 얼마 이상이면 이 배지 출력'을 해주었다. 그러다가 코드의 양이 너무 길어지고 반복이 많아서 어떻게하면 더 간단하게 코드를 작성할 수 있을지에 대해 생각해보았다. 그러던 중 filter해서 뽑아내면 어떨까라는 생각이 들어 수정했었다. 그 결과 15줄의 코드가 2줄로 줄어들었고 더 간단하고 가독성 좋게 코드를 수정한 것 같아서 뿌듯했다. 이 필터 부분은 나도 헷갈리지 않게 생각해야했던 부분이라 주석처리로 설명하듯 정리해두었다.
//EventBadge.js
// 순서 중요! 최소 금액보다 낮은, 가장 높은 배지로 주어져야하기 때문!
// 예를 들면,
// 혜택 금액(rewardPrice)이 4만원일때
// 최소금액들(5천,만,이만원)과 비교했을 때 전부 크다
// 그러면 전부가 필터링 되기 때문에
// 가장 위에있는 '산타'가 인덱스 0번이 되고 그것이 반환 된다.
static from(rewardPrice) {
return [
EventBadge.SANTA,EventBadge.TREE,EventBadge.STAR,EventBadge.NONE,
].filter((e) => e.minRewardPrice <= rewardPrice)[0];
}✅ MenuItem에서 정적 팩토리 메서드의 사용 (<- 🆕✨)
정적 팩토리 메서드는 객체의 생성을 담당하는 클래스 메서드 이다. of, from 등 메소드 이름을 지정하고, 생성자 호출 방식이 아닌, 메서드 호출 방식으로 객체를 생성하는 것이다. 그래서 new 없이도 사용 가능하다고 알고 있긴 했다. 여기까지가 그냥 알고만 있는 내용이고 자세히는 모르기 때문에 이번에 공부할 겸 학습하고 내 코드에 적용해보았다. 또 이전에 코드 리뷰를 하며 여기저기 많이 보였던 static을 메서드 앞에 써주는 것임을 알게 되었다.
new 를 직접적으로 사용하지 않을 뿐, 정적 팩토리 메서드라는 클래스 내에 선언되어있는 메서드를 내부의 new를 이용해 객체를 생성해 반환하는 것이다. 즉 정적 팩토리 메소드를 통해서 new를 간접적으로 사용한다고 한다.
정적 팩토리 메서드의 장점을 정리하자면 이름을 가질 수 있기에 반환될 객체의 특성을 바로 알아차릴 수 있어 코드의 가독성이 올라간다. 또 호출할 때마다 새롭게 객체를 생성할 필요가 없고 미리 생성된 객체를 반환만 하면 된다. 또한 of라는 메서드를 사용해 객체 생성 시 분기처리를 통해 하위 타입의 객체를 반환할 수 있다. 등등 여러 장점이 있었다. 또 입력 매개변수에 따라 매번 다른 객체를 반환 가능하다.
정적 팩토리 메서드 명명방식과 종류는 여러가지가 있지만 나는 from을 사용해 "하나의 매개변수를 받아 해당 타입의 인스턴스를 반환하는 형변환 메서드"를 구현했다.
나는 EventBadge와 MenuItem 클래스에 적용해보았다. 특히 MenuItem에서는 사용자의 input을 통한 객체 생성과, 혜택 금액에 따른 증정 메뉴 객체 생성 2가지의 생성 방식의 차이가 있었다. 따라서 input을 통한 객체 생성 방식을 fromInput이라는 이름의 매서드로 분리해주었다. 이 곳에서 input이라는 특정 매개변수를 받아 MenuItem이라는 객체를 생성해주었다. 개선의 여지가 있지만 매개변수에 따라 다른 객체를 반환 가능한 장점을 잘 살린 코드인것 같다고 조심스럽게 생각해보았다.
✅ given-when-then 패턴의 테스트 코드
Given-When-Then 패턴은 Test Code 스타일을 표현하는 방식을 말한다.
- Given: 테스트에서 구체화하고자 하는 행동을 시작하기 전에 테스트 상태를 설명하는 부분
- When: 구체화하고자 하는 그 행동
- Then: 어떤 특정한 행동 때문에 발생할거라고 예상되는 변화에 대한 설명
이번 테스트 코드를 짤 때는 더 이것을 지키도록 작성했다. 같은 테스트 코드를 작성해도 좀 더 논리적으로 작성하려고 노력했던것 같다.
3. 트러블 슈팅
✅ 테스트 코드가 아니었으면 놓칠 뻔 했던 오류
메뉴 아이템을 가져와 그 안에 카테고리를 찍었을 때 에러도 안났고 우테코에서 제공한 테스트코드도 통과 되었지만 잘못된 코드였다는 것을 테스트 코드를 짜며 깨달았다. 주말 할인을 적용하려했더니 자꾸 할인 금액이 예상과 다르게 0이 찍히는 것이었다. menuItem.category도 에러 없이 잘 가져와서 넘어갔는데 이것저것 콘솔에 찍어보니 menuItem.category가 undefined가 뜨고 menuItem 자체가 카테고리 명으로 찍힌다는 사실을 발견했다.
그 이유는 이 함수를 호출했던 곳에서 넘겨준 인자 때문이었는데 이렇게 아래처럼 m.categoty로, 카테고리로 만들어서 넘겨주고 있었기 떄문이었다. 처음에 코드를 짤 때 카테고리만 필요할 줄 알고 카테고리를 빼서 전달했는데, 나중에 메뉴의 수량도 필요하다는 것을 깨닫고 여러가지 수정하는 과정에서 빼먹은 것이었다. m.categoty를 그냥 m으로 수정하니 콘솔에 알맞은 데이터가 들어오게 되었다.
| 수정 전 문제였던 코드 | 수정 후 잘 찍히는 콘솔 |
|---|---|
 |  |
테스트 코드가 없었다면 발견하지 못할 에러였을 것이고 어디가 에러였을지 감히 추측하지도 못했을 것 같다. 아니면 영원히 몰랐을 수 있었다고 생각하니 정신이 번쩍 들었다. 프로그램이 작동이 잘 되는 것 같다고 완성된 것이 아니고 로직마다 하나하나 테스트 코드를 짜며 잘못된 코드를 계속 수정해나가서 에러를 모두 잡았을 떄가 진짜 완성인것같다. 테스트 코드의 중요성을 다시한번 느꼈다.
4. ♻️ 리팩토링
(1) 필드의 수 줄이기
지난 피드백에서 필드의 수를 줄이라는 말이 있었는데 구현이 끝나고 보니 내 필드의 수가 너무 많다고 느껴져 리팩토링을 하기로 했다.
// 이전 코드
constructor(
dDayDiscountPrice = 0,
starDayDiscountPrice = 0,
weekdayDiscountPrice = 0,
weekendDiscountPrice = 0,
giftEventPrice = 0,
totalRewardPrice = 0,
) {
this.#dDayDiscountPrice = dDayDiscountPrice;
this.#starDayDiscountPrice = starDayDiscountPrice;
this.#weekdayDiscountPrice = weekdayDiscountPrice;
this.#weekendDiscountPrice = weekendDiscountPrice;
this.#giftEventPrice = giftEventPrice;
this.#totalRewardPrice = totalRewardPrice;
}RewardDetail이라는 클래스 안에서 할인 혜택들을 관리했기때문에 여러가지 할인 필드가 너무 많았다. 그러다보니 getter를 통해 데이터를 꺼내오기도 하기 때문에 코드의 수가 너무 길어지고 지저분해지는 느낌이었다.
그래서 5가지 할인과 총 혜택금액을 속성으로 갖는 객체 하나를 만들어 모든 혜택 관련 데이터를 그 객체 안에서 관리하면 좋을 것 같다고 생각했다.
//바뀐 코드
constructor() {
this.#discountPrice = {
dDay: 0,
starDay: 0,
weekday: 0,
weekend: 0,
giftEvent: 0,
totalRewardPrice: 0,
};
}이처럼 6개의 필드에서 1개의 필드로 줄일 수 있었고. 이 객체의 key를 통해 값들을 필요한 부분에 가져와서 편리하게 쓸 수 있었다.
그 결과 거의 150줄 가까이 코드의 수를 줄일 수 있었다! 불필요한 필드와 getter를 남발하지 않고 코드를 짜서 코드의 완성도 또한 올라갔다고 생각했다.
5. 4주간의 마무리 후기
| 성공적인 테스트 코드 | 마지막 4주차 제출완료! |
|---|---|
 |  |
4주차때는 내 레파지토리의 총 코드라인이 2000줄에 가깝게 작성됐다. 매주 늘어나는 코드라인을 보니 더 많은 것을 적용해보았구나 하는 생각이 든다.
4주동안 어찌저찌 잘 돌아가는 프로그램을 만들었지만, 사람들이 흔히 말하는 '잘 돌아가는 쓰레기'가 내 코드인 것 같아서 너무 아쉽고 스트레스때문에 4주동안 잠도 잘 못잤다.. 코드를 작성하는 동안 너무 고민을 많이했던 것 같아서 꿈에서도 계속 코드만 짰던 것 같다 🥲 그리고 구현 후에도 계속 리팩토링을 했던 것 같다. 그만큼 4주동안 '몰입' 그 자체였다. 처음 우테코에서 그렇게 강조하는 몰입이 뭔지 어렴풋이 깨달았다.
내가 알고 있는 것들로 열심히 하는 것도 중요하지만 새로운 것을 학습하고 그것을 코드에 적용하는 그 과정을 경험해보는게 더 중요하다고 생각한다. 그런 면에서 이번 4주차, 4번의 과제들은 정말 글로 적을 수 없을만큼 많은 것을 얻어가는 과정이었다.
1주차 때는 함수형만 쓰다가 처음 클래스를 사용해 본 모든 경험이 소중했다.
2주차 때는 MVC 패턴을 처음 적용해보고, readme 작성의 중요성을 깨닫고, 테스트 코드의 첫 적용 그리고 테스트 통과의 짜릿함도 느꼈다. 또 JS Doc의 첫 사용, getter와 일급 컬렉션의 첫 사용 등등 많은 경험이 소중했다.
3주차 때는 새롭게 배운 모든것들을 제대로 적용해보고 특히 클래스 분리 연습을 제대로 해본 경험, 그리고 가장 많은 에러를 마주해 그것을 해쳐나간 경험 등 가장 많은 것을 얻어가는 주 였다. (그만큼 회고록도 가장 길었다 🥺)
이번 4주차 또한 정적 팩토리 메서드, enum, 클래스 상속 등을 처음 학습하고 적용해보는 경험을 가졌다. 사실 구현할게 너무 복잡하고 어렵고 시간도 너무 부족해서 옛날처럼 간단하게 와다다 구현하고 끝! 하고싶은 마음도 들었다. 하지만 차근차근 배운 것을 정리하며 적용하는 긴 시간들이 나를 더 성장시켰다고 생각한다.
우테코에 합격하지 못하더라도 (합격하면 정말 좋겠지만!!!!!) 4주간의 경험을 통해 어떤 학습을 더 해나가야할지, 어떤게 부족했는지 깨닫게 되었기 때문에 앞으로 학습할 길을 찾은 것 같다. 우물 안에서 내가 해본 것들만 반복하기 일쑤였는데 여러 사람들을 만나고 그들의 고민에 대해 경험도 하며 시야도 더 넓어진 것 같다.
개발자라는 직업을 장기간 끌고가기 위해서는 배움에 대한 의지가 중요하다고 머리로는 알고 있었는데 그것을 행동으로 처음 느끼게 해준 것이 우테코가 아닐까 한다. 말로는 배움이 재밌다, 호기심이 많다고 하지만 실제로 장애물을 만나게 되면 방어적으로 내가 원래 했던 방식으로 돌아가기 마련이다. 나도 초반에는 그런 마음이 들었다. 하지만 우테코 과제를 통해 쉽게 가자는 나와의 싸움을 한번 이기고, 시간이 오래 걸리고 부족해 보이더라도 하나라도 더 학습해 적용해보자는 목표로 임했던 것 같다. 이런 경험이 '개발자 준비생🤣'으로서 한번의 좋은 터닝 포인트가 되었다고 생각한다.
지금은 4주간 맛보기로 경험했지만 앞으로 우테코에 들어가게 된다면 무궁무진한 경험을 해보게 될 것이고 그만큼 성장할 내가 보여서 너무 기대가 된다. 아직 많은 준비가 되어있는 개발자가 아니라서 걱정이 앞서지만 그만큼 학습 욕구가 넘치고, 욕심이 많다는 것을 이렇게 증명해내면 합격할 수도 있지 않을까 작은 기대를 해본다..!
다음에는 합격 후기로 다시 오길 🙏🏻
