![]()
이어서... 오늘 한 것은 1. 리팩토링 2. TDD(구현) 였다. 사실 TDD 과정 속에 리팩토링이 있으니 동시에 진행했다고 봐도 무방하다. 오늘은 검증과 관련된 코드를 작성했는데, 생각보다 검증 부분에서 테스트하고 리팩토링 할게 많았다. 특히 enum 클래스에 검증에 필요한 값들을 옮기고, 또 테스트를 진행하며 처리하지 못한 에러들을 잡아내는 게 좀 오래 걸렸다. 가변길이 매개변수 테스트 코드에서 이렇게 공통되는 테스트는 assertExceptionTest() 메서드로 분리해서 사용하고 있었다. 자동차 이름을 하나만 넣어서 테스트할 부분이 있었고, 여러개를 넣어서 테스트 할 부분이 있었는데 동시에 진행하고 싶어서 가변길이 매개변수 를 사용했다. 이건 까먹고 있었던 건데, 어떻게 하면 매개변수의 개수를..
![]()
이어서... 오늘 한 것은 1. 옵저버 패턴 학습 2. 설계(mvc 패턴 + 옵저버 패턴) 3. 구현(TDD) 였다. 사실 처음에는 '오늘은 설계만 끝내도 좋다-' 라고 생각했다. 하나의 패턴을 새로 학습하는 데에 적지 않은 시간이 걸릴 것이라 예상했기 때문이다. 그런데 예상보다는 패턴 이해에 시간이 적게 걸려서 설계와 80% 정도까지 구현을 했다.(그래도 한 6시간은 패턴 학습에 쓴 것 같다)(그리고 새벽까지 구현을 했다...) 시간 사용 비율은 [옵저버 패턴 공부 : 설계 : 구현(TDD)] 을 [6 : 2 : 2] 정도의 비율로 시간을 쓴 것 같다. 오늘 밤에 처음 코드 작성을 시작했는데, 몇 시간 만에 80% 정도의 구현을 했다. 그 만큼 *설계에 공을 들이고 머릿속으로 끊임없이 시뮬레이션을 해서..
![]()
1주차가 끝나고... 1주차가 완전히 종료된 오늘, 00시를 기점으로 1주차 과제에 대한 제한들이 풀렸다. 그래서 모아놨던 1주차 회고들을 싹 오픈하고, 코드 리뷰할 사람을 모집했었다. 코드 리뷰 나는 총 열 아홉분과 코드 리뷰를 진행했다. 프리코스 커뮤니티에 서로 코드리뷰 할 사람을 모집하는 글을 올렸는데, 감사하게도 많은 분들이 코드 리뷰 요청을 해주셨다. | 끊임없이 날라오는 리뷰 관련 메일들... 약속이기에, 열 아홉분 모두의 코드를 가능한 꼼꼼히 보며 리뷰해드렸다. 나는 1주차 과제 때 SRP를 지키는 것을 많이 집착했는데, 그래서인지 리뷰 요청하신 분들의 코드 중 의도치 않게 한 객체가 여러 역할을 가지고 있는 것이 눈에 잘 보여서 그것 위주로 리뷰를 해 드렸다. 잘 읽히는 코드도 있었고, 그..
![]()
7일차 오늘은 많은 결과물을 내지는 않았다. 커밋은 3가지만 추가했다. 숫자를 검증하는 부분에서 '0' 을 입력하는 경우를 고려하지 못해서 관련 로직을 추가했다. 테스트 케이스를 좀 더 꼼꼼히 만들었어야 했는데, 아무래도 첫 실전 테스트 코드 작성이었다 보니 정신이 없었기도 했다. 2주차 과제부터는 경우의 수를 전부 생각해보려는 노력을 해야겠다. 체크 리스트를 만드는게 좋을지도...? 그리고 싱글톤 패턴을 적용해봤다. 싱글톤 패턴은 과제를 시작하기 전부터 알고 있던 유일한 디자인 패턴이었는데, 그 이유 때문에 써먹어보고 싶었다. | 싱글톤 패턴을 공부하고 기록해놨던 것 사실 다른 클래스에도 싱글톤 패턴을 적용할 수 있었지만, 아직은 쓰는게 더 좋은지, 좋지 않은지 상황에 대한 판단이 확실치가 않았다. ..
![]()
이어서.. 계속해서 리팩토링을 하고 있다. 솔직히 해도 해도 개선할 것이 끊이지가 않는다. 만들면 만들수록 욕심이 생긴다. 처음에는 'mvc 패턴 사용해보고 메서드 분리만 잘 해보자!' 였는데, dto, service계층, 객체지향 체조 원칙을 넘어 이제는 SOLID, 캡슐화, enum과 하드코딩까지 고민하고 있다. SOLID와 추상화, 인터페이스 사용을 이번 주 과제에 적용하기는 어려울 것 같다. 소감문과 전체 코드 해석도 작성해야 하고, 아직 그것들을 쓸만큼 이해하지 못했다. 가능하다면 2주차 과제 때 써보고 싶다..! 오늘 한 것도 정말 많다. dto 분리, 상수와 enum 사용, 자잘한 리팩토링들... 그리고 객체지향 원칙들을 지켰는지 체크하고, 최종 테스트까지 정말 많은 걸 했다. 그렇다고 힘이..
![]()
이어서.. 오늘부터는 리팩토링하는 시간이다. 리팩토링 할 것은 네이밍 결합도 낮추기 다른 뭐든 필요한 리팩토링 이다. 좋은 네이밍은 역시 어렵다. 그래도 네이밍에 대한 감을 잡아가고 있다. 최대한 리팩토링 하고 있는데, 머리가 너무 복잡할 때는 역시 쓰면서 정리하는 게 최고인 것 같다. 머릿속으로 시뮬레이션 돌리는 거에는 역시 한계가 있는 것 같다. 에러..? 테스트 코드를 실행하면 다음과 같이 게임 종료 이후에도 "숫자 야구 게임을 시작합니다." "숫자를 입력해주세요 : " 메시지가 출력되는 현상을 발견했다. 그런데 정말 신기하게도 내가 직접 Application 시작점에서 실행하면 저런 메시지가 나오지 않는다. 그리고 애초에 저 "숫자 야구 게임을 시작합니다." 는 Application 에서 객체를 ..
![]()
이어서.. 오늘은1. 테스트 코드를 메인 코드로 옮기기2. 테스트 통과를 목표로 가졌다.둘 다 완료했다. 시간이 많이 걸린 부분이 controller 의 구조에 관한 고민, 그리고 테스트에서의 에러였다.메인 코드로 옮기기ResultOfGame 로직 변경테스트 클래스를 메인 코드로 그대로 옮겼는데, 에러가 발생하지 않아서 단위 테스트를 잘 진행했구나- 라는 생각이 들어 뿌듯했다.코드를 옮기다가 새로운 고민이 생겼는데, ResultOfGame (게임 결과 결정) 클래스에서 결과가 담긴 문자열을 OutputView 에 전달하는 방식이 맞는지였다. 이것이 SRP 원칙에 위반되지 않나 고민을 했다.)그리고 더불어 controller 를 작성하다 보니 '재시작 부분을 어떻게 구현할 것인가' 라는 고민이 들었다. 사..
![]()
이어서.. 오늘은 1. 핵심 로직(플레이어-컴퓨터 숫자 비교) 작성 2. 테스트 코드 완성 을 목표로 가졌다. 결론부터 말하자면 둘 다 완료했다. 더 나아가서 작성한 테스트 코드를 실제 코드로 옮기고 있는데, 여기서 좀 난관을 겪어서 시간이 많이 지체가 됐다. test: 핵심 로직(플레이어-컴퓨터 숫자 비교 기능) 작성 어제 고민한 것이, (split() 등을 사용해서) 문자열을 한 글자씩 분리할 것인가? indent depth 를 늘리지 않으면서, 핵심 로직을 어떻게 구현할 것인가? 였다. 두 가지를 모두 충족시키는 코드가 깔끔하고 성능이 좋은 코드라고 생각했다. 그래서 고민을 많이 했다. 일단 2번 사항을 위해서는 이중 for 문 대신 볼 카운트 메서드와 스트라이크 카운트 메서드의 분리가 필요하다고 ..
![]()
이어서.. 오늘은 아래의 것들을 하기로 생각했었다. 1. 테스트 코드에서 입력값을 받을 수 없는 이슈 해결하기 2. 테스트 코드 작성 시작하기 1번은 해결했고, 2번은 진행 중이다. 테스트 코드에서도 테스트 자체에서도 참 고민할 것이 많았다. 이제 이틀차인데 새롭게 배우는게 이전보다 훨씬 많은 것 같아서 좋았다. 역시 실전에서 부딪혀 봐야 빨리 배운다. 테스트 코드에서 입력값을 받을 수 없는 이슈 해결 | [System.in과 System.out에 대한 테스트] (https://sakjung.tistory.com/33) 위 포스팅에서 많은 도움을 받았다. 알고 보니 우테코 3기 선배분의 게시글이였다. 간단하게 요약하자면, System.in은 사용자의 입력을 InputStream으로 담는다. Scanner..
![]()
시작 우테코 프리코스가 시작됐다. 2시에 유튜브 라이브로 사전설명회가 있었고, 3시 땡 하니 1주차 미션 메일이 도착했다. 그런데 왠걸, 1주차 미션이 숫자야구였다. 사실 우테코 프리코스 미션은 어느정도 이전 기수의 문제를 그대로 쓴다고는 알고 있었다. 5기때는 1주차 온보딩(기초 코딩테스트급 7문제) - 2주차 숫자야구였는데, 2주차 문제가 이번 기수 때 1주차 문제로 나온 것이다. 여기서 생각했던 것은, 1. 지원자 수가 많아서 우테코 측에서 변별력을 올린 것 같다. 2. 다행이다. 왜 다행인가? 숫자 야구를 풀어봐서 다행이 아니었다. 나는 *숫자야구는 포크만 해놓고 풀어보지는 않았다. * 그럼 왜 다행이냐면, 한 과제에만 집중할 수 있었기 때문이다. 사실 지난 기수 프리코스 문제 중 1주차 온보딩에..
![]()
역할, 책임, 협력 객체지향의 사실과 오해를 다 읽었다. OOP를 하는 개발자들에게 필수 도서라 하여, 다른 공부할 것들을 제쳐두고 이것만 먼저 읽었다. 사실 이 책은 펼쳐놓고 코드를 타이핑하고 응용하는 책은 아니다. 이 책에서 실제 코드는 단 한 파트에서만 나온다. 대부분은 줄글과 이해를 돕기 위한 삽화로 구성되어 있다. 페이지 수는 260p 밖에 안되는 책이었다. 하지만 이 책을 완독하는데 순수 시간으로 약 20시간 정도가 든 것 같다. 단순히 글을 줄줄 읽기만 했다면 빠르면 1시간에도 충분했을 건데, 이 책이 설명하는 단어와 문장과 은유를 이해하려고 몇번이고 곱씹어보고, OKKY에 질문도 하느라 많은 시간이 들었다. 완독한 다음날인 오늘, 간략하게나마 회고를 해 본다. 일단, 어려웠다. 이 책은 은..
의도를 분명히 밝혀라 좋은 이름을 지으려면 시간이 많이 걸리지만, 좋은 이름으로 절약하는 시간이 훨씬 더 많다. 이름은 대상의 존재 이유, 수행 기능, 사용 방법을 드러내야 한다. 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다. 단순히 이름만 고쳐도 함수가 하는 일을 이해하기 쉽다. 그릇된 정보를 피하라 그릇된 단서를 남기지 않는다. 널리 쓰이는 의미가 있는 단어를 사용하지 않는다. 예시 1 ) 직각삼각형의 빗변(hypotenuse)을 구현할 때 변수명 hp는 적당하지 않다. 유닉스 플랫폼을 가리키는 이름이기 때문이다. 그룹으로 묶은 의미를 사용할 때, 실제 List를 사용하지 않았다면 accountList와 같이 명명하지 않는다. 실제 List가 아니라면 프로그래머에게 그릇된 정보를 제공하는..
