녕의 학습 기록

레벨 1의 세번째 미션인 블랙잭이 끝났다. 이전 미션이 출석이었어서 그런지 이번 미션은 비교적 여유롭다고 느껴졌다.상속 vs 조합이번 블랙잭의 핵심은 딜러와 플레이어에서 발생하는 중복 로직들을 해결하는 것이었다. 주로 나온 방법들이 상속과 조합(합성과 같음)이었고, 나는 상속이 더 익숙했기 때문에 상속을 택했다. 물론 "딜러 is A 겜블러"라는 상속 관계가 적절하다고 생각해서 상속을 선택했기도 하다. 딜러와 플레이어는 모두 게임에 참가하는 겜블러라고 보았고 겜블러를 추상 클래스로 만들어 딜러와 플레이어가 상속 받게 했다. 그리고 딜러와 플레이어의 로직 차이는 초반에 공개하는 카드의 장수 차이만 존재한다고 생각해서 겜블러의 getInitialCards를 추상 메서드로 선언하였다. 이렇게 중복되는 로직은 ..

레벨 1의 두번째 미션인 출석이 끝났다. 이번 미션은 1단계에서 페어랑 함께 TDD로 구현하고, 2단계에서 혼자 처음부터 다시 TDD로 구현하는 것이 요구사항이었다. 우선 1단계는 많이 힘들었다. 그 명성과 대략적인 프로세스만 들어봤지, TDD를 직접 해보기는 처음이었기 때문이다. 페어인 젠슨도 TDD가 처음이었어서 둘이서 상당히 헤맨 기억이 있다. 무엇보다 어디서부터 어떻게 시작해야할 지가 가장 막막했었다. 예를 들어 A 객체에 대한 실패하는 테스트를 만들고 구현하자니, B 객체가 필요했다. 그래서 B 객체에 대한 실패하는 테스트를 만들고 구현하고자 하니, 또 C 객체가 필요했다. 이런 것이 몇번 반복되다 보니 젠슨이랑 나는 당황스러운 감정을 감추지 못하고 같이 웃기 바빴다. 지금 돌아보니 젠슨이랑 많..

우아한테크코스 들어와서 처음으로 진행한 미션이자, 나의 첫 페어 프로그래밍이었다. 페어는 랜덤으로 배정을 받았는데, 우연히도 같은 데일리&연극조인 듀이랑 매칭 됐다. 이미 서로에 대해서 많이 알고 있었기 때문에 비교적 편한 환경에서 1단계를 마칠 수 있었다. 사실 이전부터 페어프로그래밍이 어디에 어떻게 좋은건지 궁금했었는데, 이번 경험을 통해 깨달은 바가 있다. 우선 다른 크루와 같이 코드를 작성하다보니 내가 몰랐던, 기존의 내 코드와 다른 코드들을 접해볼 수 있어 좋았다. 그리고 무엇보다도 하나의 문제를 두고 같이 의논하며 한가지 결론을 도출하는 과정이 좋았다. 우아한테크코스에 들어오기 전, 혼자 학습하고 혼자 고민하며 결론을 짓는 것을 힘들어했던 나였기에. 이러한 점이 페어 프로그래밍의 큰 장점으로 ..

문제 상황서비스 레이어의 단위 테스트를 위해 TestRepository 코드를 작성하던 중 save() 내부에서 파라미터로 받은 엔티티의 id를 설정해주어야 했다. 하지만 id 필드의 접근 제어자는 private이고, setter를 열어두지 않았기 때문에 TestRepository에서 id값을 설정할 수가 없었다.public class GroupTestRepository implements GroupRepository { private Map storage = new HashMap(); private long sequence = 0L; @Override public Group save(Group group) { if (group.getId() != null) { ..

지난 12월 27일은 우테코 7기 최종 발표날이었다. 말로는 기대 안한다고 하면서도 잔뜩 긴장한 채 3시가 되기만을 기다렸다.일부러 2시쯤 집을 나와 1시간 거리에 있는 카페로 향하였고, 카페에 앉아 노트북을 켜니 3시가 되었다. 슬슬 오픈채팅방에 합격 메일이 왔다는 소식이 여럿 들려왔지만 내게는 아직 메일이 오지 않았다. 새로고침을 계속 해봐도 메일이 오지 않아 합격 메일만 빨리 보내주는구나... 하고 절망하던 중.메일이 도착했고 될대로 되라하고 바로 클릭해봤다. "합격"......................!!!!!!!!!!그렇게 기쁜 마음에 카페에서 혼자 격하게 들썩였다. 그리고 자기소개서부터 최종 발표까지 2달간 스트레스를 받으며 고생했던게 생각나 급 울컥했지만 끝내 눈물은 나오지 않았다. 친구..

문제 상황 JpaRepsitory의 구현체인 GroupJpaRepository에 직접 의존하고 있는 GroupService를 단위 테스트하고자 한다.@Service@Transactional(readOnly = true)@RequiredArgsConstructorpublic class GroupService {    private final GroupJpaRepository groupJpaRepository; ...} 시도한 것 1. 실제 db를 사용해 통합 테스트 / 외부 Mocking 라이브러리 사용테스트하고자 하는 대상이 repository 구현체에 의존하고 있기 때문에 실제 repository 구현체를 사용하고 데이터베이스와 연동해 통합 테스트를 하거나, Mockito와 같은 외부 라이브러리를 사용..

1차 합격지난 12월 9일, 우테코 7기의 1차 결과 발표가 있었다. 1차는 자기소개서 및 프리코스를 기반으로 추려진다. 우테코가 너무나도 간절하게 하고 싶어 자기소개서와 프리코스에 최선을 다한 나였기에 내심 기대를 많이 하고 있었다. 발표는 3시였는데 정말 더럽게 시간이 가지 않아 카페에서 그림판에 부적을 만들기도 했다. 그러다가 3시가 되었고, 머지않아 네이버 앱에 우테코 1차 결과 메일 알림이 왔다.너무 떨려서 한 3분동안은 확인하지 못하다가 에라 모르겠다 하고 클릭을 했고.눈에 들어온 '합격'이라는 단어에 순간의 기쁨을 참지 못하고 카페에서 소리를 지를 뻔 했다. 너무 기뻐서 주변인 2명 정도에게 전화를 해 이 소식을 알리고 난 후에야 매우 큰일났음을 깨달았다.프리코스가 끝나고 1차 결과가 나오기..

1주차에 대한 피드백 중 한가지는 'Git으로 관리할 자원을 고려하라'였다. 예를 들면 자바의 .class 파일은 git으로 관리할 필요가 없다.자바 코드만 있으면 .class 파일을 생성할 수 있기 때문이다. 나는 평소 개발할 때 어떤 파일을 git으로 관리할지는 .gitignore로 관리했었다.주로 민감한 파일이 github에 올라가지 않게끔 자동으로 생성된 .gitinore파일에 추가하는 방식이었다.그러나 자동으로 생성된 .gitignore에 대해서는 궁금증을 가지고 알아본 적이 없었다. 1주차 피드백이기도 하고, 알아두면 나중에 관련한 문제가 생겼을 때 도움이 될 거 같아 알아보았다. 우선 기존의 .gitignore파일이다 HELP.md.gradlebuild/!gradle/wrapper/gradl..

1주차의 공통 피드백에는 다음 링크와 함께 커밋 메세지를 의미있게 작성하라는 내용이 있었다.https://meetup.nhncloud.com/posts/106 링크 속 내용을 쭉 정독하고 가장 고민 된 부분은그래서 제목을 명령조로 사용할 것인가?였다. 영어 기준으로 좋은 커밋 메세지는 제목을 명령조로 작성한다고 한다.예를 들어 A메서드를 변경했으면 -> Change A method 이렇게 말이다. 근데 한국어로 작성하면 커밋 메세지의 제목이 'A메서드를 변경하라' 가 되어버린다.작성하면서도 이게 맞나하는 생각과 함께 나도 영어로 커밋 메세지를 작성해야하나 싶기도 했다.하지만 커밋 메세지를 작성하는 사람과 읽는 사람 모두가 한국인일 것이기 때문에 한국어를 사용하기로 했다. 그렇다면, 한국어로 커밋 메세지의..

백준에서 자바11로 StringBuilder의 isEmpty()를 사용하다 컴파일 에러를 마주침 isEmpty()는 CharSequence 인터페이스의 메서드로, 자바 15 이상부터 지원한다. 따라서 자바11에서는 isEmpty()대신 length()를 사용해 길이가 0인지를 비교해야한다. 실제로 isEmpty 메서드도 length가 0인지를 확인하는 방식으로 구현된다.