우아한테크코스5기

강연에서 들었던 말 중 기억에 남는 것들을 정리해 보았다! 중간에 내가 느낀 점은 이탤릭체로 적어 놓았다! 💋 자존감 기둥 세우기 자존감 기둥은 여러 가지로 세워 놓아야 한다. 하나만 세워두게 되면 갑자기 무너질 수가 있다. 자존감 기둥은 글쓰기, 커뮤니티 참여, 운동, 멘토링, 전 동료와의 대화, 독서가 될 수 있다. 커뮤니티 참여 회사에 가면 내가 제일 못하는 사람일 수도 있는데, 다른 커뮤니티에 가면 내가 도움이 되는 사람일 수도 있다. 이럴 때는 더 못하는 회사에 가서 내가 더 잘하는 사람이 되느냐, 그대로 가면서 잘하는 사람들 옆에 붙어있느냐 두 가지 선택이 있다. 글쓰기 개인적인 감정 쓰레기통 같은 일기를 많이 썼다. 멘토링 선배 개발자들을 많이 만나면서 고민을 이야기하고, 선배들은 어떻게 해..

레벨1 마지막날에 인터뷰를 진행했다. 7명의 크루와 브리 코치가 한 팀이 되어 진행했고, 각각 돌아가면서 인터뷰어(질문하는 사람), 인터뷰이(질문을 받는 사람), 옵저버가 되었다. 나는 내가 작성한 레벨 로그를 바탕으로 질문을 받았다. 20분의 인터뷰를 마치고, 10분 간 인터뷰이를 제외한 다른 사람들이 피드백을 작성하고 발표하는 시간을 가졌다. 이번 회고를 통해 내가 받았던 피드백을 정리해보고, 레벨2 인터뷰를 위해서 9주 간의 레벨2 기간동안 어떤 방향으로 학습을 보완해야 하는지에 대해서 계획을 세워볼 수 있으면 좋을 것 같다. 💋 학습 측면에서 받았던 질문과 나의 대답 모든 질문들이 기억에 남지는 않으므로, 기억에 남았던 질문만 모아봤다. ✔ TDD Q. TDD를 사용하는 이유? 나의 대답) 처음 ..

이전에 진행했던 자동차 경주 미션에서 더 발전된 형태로, 이 미션을 웹으로 옮기는 미션을 진행했다. 순수 자바만을 사용한 콘솔 애플리케이션의 자동차 경주 미션: https://github.com/eunkeeee/java-racingcar GitHub - eunkeeee/java-racingcar: 자동차 경주 게임 미션 저장소 자동차 경주 게임 미션 저장소. Contribute to eunkeeee/java-racingcar development by creating an account on GitHub. github.com 그치만 사다리타기로 내 페어 베로의 코드를 사용해서 웹에 올리기로 했다. 스프링을 처음 접하게 되어 굉장히 혼란스러운 이틀이었다...! 처음으로 공식문서도 열심히 읽어보고, 지식을 ..

우테코 레벨1 막바지에 한달 생활기를 작성했었다. 그리고 백엔드 크루 뿐만 아니라 안드로이드, 프론트엔드 크루들과 함께 서로의 코드를 리뷰했다. 이 링크에 들어가면 내가 받은 리뷰를 볼 수 있다. 또 우리 팀 내에서 토너먼트로 올릴 글을 투표를 했다. 그중 1위를 해서 토너먼트에 올라갔다! (일종의 조별리그) 바로바로 그 글... 아래에는 원문이 있다! 인트로 다들 시간이 빠르게 지나갔다고 하지만, 나에게 시간은 나름 정속으로 갔다. 특히나 계속 기록하는 습관이 있다 보니, 매일 일기를 최고 네 줄씩 작성하는데, 한 달 전과 정말 많이 발전했다는 생각이 든다. 집에서 설렁설렁 개발 공부하던 때와는 달리 매일 일정한 시간에 공부하다 보니, 주변 환경이 왜 중요하다 하는지 알 수 있었다. 중요도 선정중.....

이번 리뷰어였던 디디는 예외 메세지에 대한 피드백을 몇 개 달아주었다. 달아주면서도 예외 처리에 대한 부분은 아직 감이 잘 오지 않을 것이라고 말해주긴 했지만 이번에 알게된 몇 가지를 정리해 보았다. 💋 예외 처리는 조심스럽게... 내가 받은 리뷰이다. RuntimeException 전체를 한번에 잡아서 message를 출력해주는건 어플리케이션의 취약점을 노출할 수 있는 포인트가 될 수 있어요. 예를들면 SQL 관련된 Exception의 메세지를 그대로 view에 보여줘서 사용자가 데이터베이스의 constraint 예외 메세지를 받을수도 있거든요. catch문을 좀 더 세분화 해서 잡아서 원하는 동작을 하도록 하는것도 일종의 방법일 수 있습니다. 혹은 예외메세지를 view로 보여주지 않고 공통된 메세지가..

⭐ 레벨1 인터뷰를 준비하며 드디어 약 두 달 간의 우테코 레벨1 생활을 마치고, 오늘 이리내, 오잉, 제나와 만나서 인터뷰를 준비하고 있다. 그동안 학습한 내용들을 바탕으로, 짧게 키워드를 정리해 보았다. 키워드에 대해 질문하고 싶은 것이 있다면 댓글로 남겨주세요! 💋 자동차 경주 미션 ✔ 페어 프로그래밍 페어 프로그래밍은 페어와 함께 설계와 구현의 모든 과정을 진행하는 방식이다. 페어 프로그래밍을 통해 생산성이 향상되는 경우가 많다고 한다. ✔ 단위 테스트 단위테스트는 테스트 가능한 가장 작은 소프트웨어를 실행하여 예상대로 동작하는지 확인하는 것이다. ✔ 네이밍의 중요성 네이밍은 너무 짧아도 좋지 않다. 정확하게 역할을 설명하는 이름을 지어주는 것이 좋다. 이름을 통해서 의도를 드러내는 것이 좋다. ..

💋 TDD에 대한 생각 TDD를 처음 적용해서 설계를 할 때는 굉장히 어려웠다. TDD의 아이러니 중 하나는 테스트 기술이 아니라는 점이다. TDD는 분석 기술이며, 설계 기술이기도 하다. - 켄트벡, Test Driven Development by Example 중 특히 처음에는 이 말이 너무너무 어려웠다. 나에게 TDD는 테스트 코드를 먼저 짜는 것 뿐이었다. TDD가 설계 기술이라는 것을 인지하지 못한 채, 테스트 코드부터 짜기 위해서는 내가 테스트하고 싶은 메서드의 시그니처(파라미터, 반환값의 타입)는 반드시 알아야 했다. 굉장히 작게 어떤 메서드를 테스트한다는 생각만 가지고 있어서 오히려 더 설계를 방해했던 것 같기도 하다. 하지만 지금 느끼는 TDD는 다르다. 우선, 설계부터가 중요하다. 한 ..

💋 단위 테스트에 대한 생각 내가 단위 테스트를 작성하는 이유는 무엇인가? 단위 테스트를 작성하면 마음이 편안하기 때문이다. 리팩터링을 할 때에도 어떤 부분에서 문제가 될 지에 대해 걱정하지 않고 코드를 수정할 수 있다. 세부 구현에 대해 코드 품질을 높일 때 특히 효과적이라고 생각했다. 하지만 이번 체스 미션 중에 단위 테스트를 빗겨가는 케이스를 두 번이나 생각해내지 못했고, 테스트 코드의 맹점은 완벽하지 않은 테스트가 신뢰될 때라는 것을 깨달았다. 앞으로는 조금 덜 맹신하면서 테스트 코드를 작성할 필요가 있을 것 같다. 항상 놓치는 케이스가 없는지 신경쓰면서 작성해야겠다. 내가 작성한 좋은 단위 테스트는 어떠한 부분에서 좋은 단위 테스트라 느꼈는가? 단위 테스트 첫 강의 때도 언급했었지만, 나는 프로..

우테코의 미션은 계속 누적된다. 첫주차부터 했던 페어 프로그래밍, 단위 테스트, TDD 모두 누적해서 미션을 구현했다. 💋 상태 패턴 사용 피드백2 강의를 듣기까지 구현을 못했는데, 그래서 이미 상태 패턴을 사용하는 방법을 강의에서 봐 버렸다. 그냥 본 김에 네오를 따라 상태 패턴을 사용해봤다. 장단점을 좀 느꼈는데, 현재까지 내가 느낀 것은 아래 내가 코드리뷰에 남겼던 이야기대로다. 상태 패턴에 대해서 한 번 포스팅 해야겠다! 💋 클래스, 메서드의 abstract, final 제어자를 잘 활용하자 이번 미션에서 상속을 자주 활용하다 보니 제어자 abstract, final에 대해 제대로 이해할 수 있었다. 앞으로 모든 클래스를 abstract나 final 둘 중 하나로 만들기로 다짐했다! 💋 쉽게 계산..