우테코 지원서를 쓰고 2주차 미션까지 마무리한 오늘.. 쉽지 않았습니당..
1주차 미션때 알고리즘 7문제부터 ( 단순하게 푸는 느낌은 아니었습니다.. ), 숫자야구 프로젝트까지 2주차까지 순수 자바로만 구현하면서 느끼거나 배웠던 점들을 적어보겠습니다
2주차까지 받았던 목표 및 피드백들을 정리하고 느낀점을 적어볼까합니당..
함수 분리와 함수별로 테스트를 작성하는 것을 목표로 받았는데 구현하는데 정말 많은 일이 있었죠..
피드백
1. 컨벤션을 지켜라👌
네이밍을 얼마나 고민해봤니?,
구현 순서도 코딩 컨벤션이다
클래스는 상수, 멤버 변수, 생성자, 메서드 순으로 작성한다.
이 방법이 맞는지는 모르겠습니다. 상수를 먼저 작성한다는 것이 이미 무슨 예외나 어떤 조건을 쓸지 다 알고 시작한다는 건가? 설계를 그렇게 완벽하게 하고 가라는 건가? 맞는말이면서 참 이상적인 조건이라 지키기는 어려웠지만 이런 기준을 가지고 지키려고 의식적인 연습을 하는것이 중요하다는 뜻이 아닐까요?
변수 이름에 자료형은 사용하지 않는다
이번에 네이밍할때 inputList, outputSet 이런 네이밍을썼는데 반성해야겠습니다..ㅠㅠ
네이밍은 늘 넘넘 어려워.. 이거 누가 자동으로 다 써줬으면 좋겠다..
값을 하드 코딩하지 않는다
문자열, 숫자 등의 값을 하드 코딩하지 마라. 상수(static final)를 만들고 이름을 부여해 이 변수의 역할이 무엇인지 의도를 드러내라. 구글에서 "java 상수"와 같은 키워드로 검색해 상수 구현 방법을 학습하고 적용해 본다.
static final String INTEGER_EXIT_MESSAGE = "하지마라 그거"; 이런식으로 상수를 뽑아서 사용했습니다. 예외처리 던질때 의식적으로 연습했던게 여기서 쓰이더라구요 ㅎ
2. 함수의 분리
SRP를 준수했니?
함수가 한 가지 기능을 하는지 확인하는 기준을 세운다
만약 여러 함수에서 중복되어 사용되는 코드가 있다면 함수 분리를 고민해 본다. 또한, 함수의 길이를 15라인을 넘어가지 않도록 구현하며 함수를 분리하는 의식적인 연습을 할 수 있다.
나는 이걸 if, for같은 indent level이 3을 넘어가면 한번 더 고민했던 것 같습니다.
함수로 extract할 수 있지 않았을까? 조건문은 뽑아낼 수 있지 않았을까?
한 함수가 한 가지 기능만 담당하게 한다
함수 길이가 길어진다면 한 함수에서 여러 일을 하려고 하는 경우일 가능성이 높다. 아래와 같이 한 함수에서 안내 문구 출력, 사용자 입력, 유효값 검증 등 여러 일을 하고 있다면 이를 적절하게 분리한다.
3. 살아있는 문서화
죽은 문서를 만들지 마라!
기능 목록을 재검토한다
너무 세세한 부분까지 정리하기보다 구현해야 할 기능 목록을 정리하는 데 집중한다. 정상적인 경우도 중요하지만, 예외적인 상황도 기능 목록에 정리하고, 특히 예외 상황은 시작 단계에서 모두 찾기 힘들기 때문에 기능을 구현하면서 계속해서 추가해 나간다.
- 계속 수정되는 MD를 잘 반영하자 라는 뜻입니당
README.md를 상세히 작성한다
미션 저장소의 README.md는 소스코드에 앞서 해당 프로젝트가 어떠한 프로젝트인지 마크다운으로 작성하여 소개하는 문서입니다. 그러니까 잘 써라
기능 목록을 업데이트한다
README.md 파일에 작성하는 기능 목록은 기능 구현을 하면서 변경될 수 있다. 시작할 때 모든 기능 목록을 완벽하게 정리해야 한다는 부담을 가지기보다 기능을 구현하면서 문서를 계속 업데이트한다. 죽은 문서가 아니라 살아있는 문서를 만들기 위해 노력한다.
4. 테스트
너의 테스트는 철학이 담겨있니? 생각은 하고 짠거니?
테스트를 작성하는 이유에 대해 본인의 경험을 토대로 정리해본다
단지 기능을 점검하기 위한 목적으로 테스트를 작성하는 것은 아니다. 테스트를 작성하는 과정을 통해서 나의 코드에 대해 빠르게 피드백을 받을 수 있을 뿐만 아니라 학습 도구(학습테스트를 통해 JUnit 학습하기.pdf)로도 활용할 수 있다. 이런 경험을 통해 테스트에 대해 어떤 유용함을 느꼈는지 알아본다.
- 테스트 작성하는 것이 미숙했는데 실제로 여러 테스트들을 작동해보면서 변동하는
처음부터 큰 단위의 테스트를 만들지 않는다
테스트의 중요한 목적 중 하나는 내가 작성하는 코드에 대해 빠르게 피드백을 받는 것이다. 시작부터 큰 단위의 테스트를 만들게 된다면 작성한 코드에 대한 피드백을 받기까지 많은 시간이 걸린다. 그래서 문제를 작게 나누고, 그 중 핵심 기능에 가까운 부분부터 작게 테스트를 만들어 나간다.
- 작은 단위부터 테스트 해라 라는 뜻인데, 맞는 말이지만 이게 메소드 단위로 테스트 하라는 뜻은 아니라고 생각합니다. 어떤 조건문 하나를 테스트할 수도 있는거고 어떤 명령어 하나만 테스트할 수도 있는거니까?
- 저는 테스트는 크게 기능단위 순서로 설계를 해야 한다고 생각하는데 여기서 말하는 기능은 크게 음식 메뉴 조회 이런 기능을 테스트 할 순서를 정해서 그걸 구현하기 위해 필요한 작은 단위의 테스트를 짜보라는 뜻이 아닐까요?
느낀점.
이번에 아침에 일찍 일어나서 운동을 하고 하루를 시작하는 목표를 세워서 실행해보면서 무언가 하지 못했다는 것은 핑계에 불과하다는 사실을 다시 느꼈습니다.
하고 있는 일이 많다보니까 모두 동시에 하기는 참 어려웠습니다. 그래도 마감시간이 1주일이라서 꼭 지킨다는 생각으로 임했습니다.
개발
- 이번에는 팩토리 메소드 패턴을 숫자야구에 접목하면서 의존성을 줄이고 응집도를 높이는 설계를 실제로 해보면서, 좀더 OOP적인 설계란 무엇일지 체감했습니다. 그러다 보니 제가 진행했던 프로젝트를 전부 뒤집어서 다시 만들고 싶더군요!!
늘 옆에 설계요정이 있어서 너 이따구로 짜는게 맞어? 이게 SOLID를 준수했어? 잔소리를 해주는 요정이 있다고 생각하고 코드를 짜야합니다. 모든 코드는 의도가 있어야 한다는 뜻이죠! (제 생각생강..) 저도 주변에 코드리뷰 해주면서 설계요정 역할을 하고 있는데 제 주변에도 설계요정이 많았으면 좋겠습니다
남은 3~4주차 프리코스 마감치고 또 회고때리러 오겠습니다!
조만간 11월 25일에 진행되는 Naver PartnerShip 행사에서 발표를 맡게 됐는데 설계의 재미를 그 날 잘 이야기 해보고 싶습니다! 다음 포스팅때 영양가있는 내용으로 찾아올게요 빠셍!
