지난주에 풀었던 최소 환승 문제에 이어서 환승문제를 하나 더 풀었다. 시간을 많이 쏟은 만큼 어떤 유형인지 감을 어느정도 잡아서 구현이 어렵진 않았는데, 시간은 꽤 잡아먹었다. 시간이 답일듯 하다.
로그인 예외 구현을 시작했다. 예외의 형식같은걸 생각해보다 다른 서비스에서 예외처리가 된 상태로 호출을 하면 되는 것이 아닌가? 하는 생각이 들었다.
하지만 찾아보면 대부분 권장하지 않는 분위기인데 가장 큰 이유는 순환참조다. 그래서 이럴 경우 중간에 관계테이블처럼 어댑터를 하나 두면 될 것이라 생각하여 패턴을 찾아봤다. 메디에이터 패턴이 가장 비슷하긴 한데, 단순히 중간 연결의 매개채로 사용하기에는 너무 과하다. 곰곰이 생각해보니 그냥 서비스를 하나 추가해주면 되는것이 아닌가? 하는 생각도 들었다. 순환 참조가 되지 않도록 관계테이블 같은 서비스를 하나 만들어 주는 것이다. 순환 참조가 발생했으면 해당 기능에 대한 책임을 가지는 클래스가 필요하다는 뜻 아닐까?
오늘부터 리팩토링을 시작하기로 했는데, 어쩌다 보니 깃 공부를 하게 됐다. 좀 더 근본적인 이해를 하고 싶어 GitObject를 살펴봤다. 깃에는 사용자 친화적 명령어와 로우레벨 명령어가 함께 존재하는데, 로우 레벨 명령어를 이용해서 깃의 원리를 알려준다. 공식 문서인데 아주 친절하게 돼있고 번역도 잘 돼있었다. 오늘은 깃의 데이터베이스(레포지토리)와 스테이징 영역 및 인덱스 그리고 트리를 살펴봤다. 깃 내부 구조가 항상 궁금했었는데 생각보다 심플한 구조라 놀랐다. 물론 소스가 그렇게 간단하진 않겠지만, 논리가 아주 심플하고 멋지다.
블로그 전반적인 고민이 생겼다. 벨로그에는 포스팅을 하고 깃헙블로그에는 TIL을 올리는 용도로 사용해볼까 한다. 블로그 관리가 사실상 멈춘 상태라서 이대로 남에게 보여주는 것 보다는 나중에 옮기더라도 일단 가독성 있는 곳에 포스팅을 해놓는게 좋지 않을까 하는 생각이다.
카카오 기출이었던 추석 트래픽 문제 풀이를 시도했다. 시원하게 실패했는데, 감을 잡기 힘들었던 부분은 내가 생각할때 가장 심플한 방법도 O^2가 걸릴 것 같은데 더 좋은 방법을 생각해보지 못할 것 같았다. 정직한 방법은 ms단위를 초단위로 바꾸어 1000, 24시간을 초로 환산하면 24 * 3600 * 1000 의 경우의 수가 나오고 해당 반복마다 입력 데이터의 수 만큼 반복해야 한다.
결국 답지를 봤는데, 최적화를 가장 잘 하면 n log n 까지 할 수 있지만, 기본적으로 O^2까지만 접근해도 풀 수 있다고 한다. 그래서 다시 풀이를 시작해봤지만, 시간 관련 로직에서 살짝 벽을 느꼈다. 생각보다 고려해야 될 조건이 많았는데, 내일 다시 그림을 그려보며 시도해봐야겠다.
예외관련 고민은 다음으로 미뤄두고 일단 지금 당장 필요한 만큼만 작성해서 pr을 올렸다. 나쁜 고민은 아니었지만, 결국 나중에 불필요한 코드가 돼버릴 수 있다는 생각이었다. 지금 단계에서는 테스트로 리팩토링 하기 용이한 환경을 만들어주는게 더 좋을 것이라 판단했다.
제인의 pr리뷰도 했는데, Mapper의 BeforeMapping과 AfterMapping을 이용해서 매퍼에 로직을 넣는 방법을 사용했다. 좀 더 개선해볼 수 있을 것 같은데 정리해서 글로 남겨봐야겠다.
JPA의 embadable 어노테이션도 괜찮아보였는데, id가 없는 자식 테이블을 만들어주는 어노테이션같다. JPA도 빨리 시작해봐야하는데... 길게 보자
오늘은 Git Object를 마저 살펴봤다. 커밋과 Git Object가 어떻게 구현되어있는지에 대한 설명들이었다. 역시나 이해가 잘 되게 설명이 돼있었다. 이걸 바탕으로 클론코딩을 해봐도 재밌을 것 같다.
시간 관련 로직을 그림을 그려가며 정리했다. 대부분의 테스트케이스는 통과하는데, 일부 통과하지 못하는 케이스가 생겼다. 전반적으로 맞는 로직이니 경계값 같은 부분에서 문제가 있을 것 같다. 케이스를 차근차근 찾아봐야겠다.
개발 방향을 조금 더 빠른 템포로 가는게 어떠냐는 의견이 있었다. 일단 로그인은 차순위로 미뤄두고 주요한 도메인들의 조회 파트부터 시작해보기로 했다. 그런데 막상 얘기해보니 여러가지가 얽혀있어 API를 제대로 정의하기가 힘든 부분도 생겼다. 이런 어쩔 수 없는 상황에서 변화에 유연하게 대응하려면 어떻게 해야 할까. 테스트에 의존하는 방법 외에 좋은 방법이 없을지...
서버 컨텍스트 path를 빼먹어서 한참 삽질했다... 차분히 봤으면 에러 페이지로 금방 구분할 수 있었을텐데 마음이 너무 급했나보다.
테스트를 작성하다 어제 제인의 코드에서 status code 에러때문에 다른 에러를 추적하기 어려운 상황을 봤다. 주석 처리를 하는 등의 임시방편으로 디버깅해볼 수 있겠지만, 근본적으로 해결할 수 있는 방법이 있으면 더 좋지 않을까 해서 찾아봤다.
예전에 봤던 키워드가 생각안나 다시 검색해보니 softly assert라는 것이 있었다. 간단히 얘기하면 Junit의 assertAll과 같은 것이다. RestAssured에서는 지원하지 않는 것 같고, assertJ를 이용하면 사용할 수 있는 방법이 나온다.
첫째로 클래스를 호출하여 지역변수에 담아 사용하는 것이다. 단점은 코드가 지저분해지고 보일러 플레이트가 생긴다. 둘째는 람다의 바디 부분에 테스트를 구현하는건데, 이 또한 가독성이 조금 떨어지는 느낌이 들었다. 코드가 묶여있는 느낌은 좋았다. 마지막으로 처음에는 좋지 않아 보였는데 다시 생각해보니 좋아 보이는 방법이다. 아예 스태틱한 필드를 잡아놓고 가는건데, setup시점 같은 때에 초기화를 해주거나 하면 되지 않을까 하는 생각도 든다. 팀원들과 얘기해봐야겠다.
같은 기능의 이슈를 여러개 새성하니 보기가 좋지 않다. 마일스톤으로 관리하는 방법을 얘기해봤다. 다행히 제인은 긍정적인 반응이었다. 아니면 커다란 이슈 하나에 여러 이슈를 담는 것도 좋을 것 같은데 그러면 커밋과 pr을 연결시켜 관리하기가 힘들 것 같다. 더 좋은 방법도 생각해봐야겠다.
간만에 페어로 진행했다. 그런데, 내가 드라이버임에도 주도하는 느낌을 많이 받았다. 역시 노을도 비슷한 느낌을 받았다고 한다. 원인을 생각해보면 리팩토링을 정의하는 과정에서 내 생각만으로 구현 단위를 제시해서 그랬던것으로 생각했다. 구현이 복잡한데 서로 이해가 완전히 되지 않는 것 같아 일단 브랜치는 날리고 다음 주에 다시 하기로 했다. 노을도 생각을 해오고 공통되는 부분과 공통되지 않은 부분을 나눠 각자 생각이 다른 부분은 제시한 사람이 네비게이터를 하는 방식으로 하기로 얘기했다.
포스트스쿼드
MockMvc 분석
잭슨 리퀘스트 바디 파싱 분석
그런 REST로 괜찮은가
OS
AWS 강의듣기
s3 이용
sticky session
Powered with by Gatsby 2.0