문제가 잘 풀리지 않았다. 올 상반기에 있었던 카카오 인턴 문제였는데, 그때도 제대로 풀이하지 못했던 것 같다.
단순 링크드 리스트가 아닌 노드를 이용해서 시간을 줄이고 노드를 보관해야 한다.
ListIterator를 이용할 수도 있을 것 같은데, 다시 시도해봐야겠다.
이진수 게임의 예외 사항도 찾았는데, 보수를 구한 뒤 빼는게 최단 거리일 경우가 예외 상황이었다.
CRLF가 처리됐는데도 테스트가 제대로 돌아가지 않았다. 리눅스에서 제대로 동작을 하지 않는 것 같은데, 내 환경에서는 더 이상 테스트가 불가능했다.
다시 WSL과 인텔리제이를 연결시켰는데, 여전히 불편한 점이 조금 있다.
리눅스로 테스트를 돌려보니 대충 무슨 문제인지 파악이 가능해졌다. 내일 고쳐야겠다.
REST Docs pr이 거의 머지돼서 리팩토링을 하려 했다. 그런데 단순히 스니펫을 옮겨 놓는 것은 그냥 노가다 작업이고, 새로운 스니펫을 추가할때도 손이 많이 간다.
고민을 해보다가 리플렉션을 이용하기로 했다. 처음에는 private 필드때문에 Introspect를 사용하려 했으나, 설명을 추가하는게 애매해졌다. 어노테이션으로 이를 표현하기로 했고, 리플렉션을 직접 이용하도록 했다.
구현 재료 테스트는 다 끝났고, 내일 마저 구현하면 될 것 같다.
잘 만들어지면 라이브러리로 만들어 공개해봐도 좋을 것 같다.
CRLF를 다 수정했다. 특이점은.. wsl에서 junit으로 돌리려면 junit 런쳐가 디펜던시에 있어야 한다. 그레이들이 아닌 별도의 외부 jar도 인식하는지 확인해봤는데 된다. 인텔리제이에 프로젝트의 글로벌 라이브러리를 메이븐에서 받아오는 기능도 있었다. 이용하니 잘 된다. 공략 글을 써볼 수 있겠다. ㅋㅋ
어제 만드려고 했던 유틸은 완성했다. 리팩토링 과정에서 고민이 조금 있었는데, 일단 원본을 올리고 이후에 피드백 받는 식으로 하기로 했다.
고민이 되는 부분은 계층구조로 만들지 아니면 특정 기능을 담은 유틸을 만들지였다. 이유는 클래스의 책임에 합당한지 딱 잘라서 말하기가 애매하다. 억지로 유틸을 만드는거라 그럴 수도 있을 것 같다.
하지만 만약 유틸로 뺀다 해도 계층 구조는 유지하는게 좋을 것 같다. 애초에 나눈 이유가 서로 영향을 받지 않도록 격리시키는 느낌이 강하기 때문이다. 좀 더 고민해봐야겠다.
노을은 몸이 좋지 않아 쉬었다. 무거운 작업을 하기에는 애매해서 테스트 자동화만 잡았다. 이 정도 까지는 이제 쉽게 할 수 있는 것 같다. 이 프로젝트에 쓰이지는 않겠지만, 배포 관련해서 조금 더 공부할 타이밍이 온 것 같다. 아니면 정적 분석 도구를 파는 것도 괜찮을 것 같다.
오늘은 문서를 좀 정리했다. 회의록을 넘겨가면서 주제에 따라 분류를 하는 작업을 했는데, 아리까리한 부분도 있고 잊었더 부분도 있었다. 정리했다하기에는 민망하고 절반정도 나눴는데, 분류가 완료되면 정리하면서 질의를 해봐야겠다.
프로젝트 이탈자가 늘었다. 어느정도 예상했던 부분이라 멘탈에 타격은 없었는데, 다른 분들이 걱정됐다. 다행히도 큰 균열이 가지는 않은 것 같고, 새롭게 정비를 하는 시간을 가졌다.
예전부터 문제라고 생각했었던 개발 주기에 대한 얘기가 나왔다. 기획이 늘어지면서 스플린트 타임이 따로 정해져 있지 않다 보니, 개발도 자연스래 늘어졌다.
개발할 기능을 정하고 기간을 정한뒤 개발하고 쉬는 시즌제로 가기로 했다. 말이 시즌이지 사실 이게 맞다. 그 동안 폭포수와 애자일 그 사이 어딘가에서 굴러가고 있었다.
다행히도 이런 발의를 해주신 분이 계셨다. 이 것도 정치라 하면 정치라 할 수 있는데, 개발도 사람이 하는 일이다 보니 개발자가 개발만 잘 해서 되는게 아니라는 것을 또 한 번 느낀다. 나도 여유가 없어서 바로 생각을 하진 않았었는데, 미리 준비를 하고 계셨나보다. 팀을 유지시키는 것도 목표 중 하나인데, 이런 부분에서 너무 안일하게 생각했던 것 같아 반성을 하게 된다.
어찌됐건 환기를 잘 시켜주셔서 일단은 마무리가 잘 된 듯 하다. 아예 개발자 풀을 채워놓고 시즌마다 개발할사람을 모집하는 것도 괜찮을 것 같다. 힘든 부분 중 하나가 일과와 양립할 수 있는 지속 가능한 프로젝트를 만드는 것인데, 사람들에게 조금 여유를 줄 수 있지 않을까 싶다. 프로세스와 개발 틀만 정해지면 새로 시작하는 사람에게 온보딩만 해주면 될테니 좋아보인다. 당장 할 수 있는건 아니지만, 목표가 생기면 좋은 점이 있으니, 다음 주에 얘기해봐야겠다.
간만에 글을 썼다. 그나마 다행인 점은 한 달에 글 하나는 쓰고 있었다..ㅋㅋ 초안이 잡혀있어서 쓰기 수월했다. 내일은 Validation 관련해서 써볼까 한다. 사실 오늘 두개 완성하고 싶었지만, 일정은 항상 두 배 걸리니까 딱 맞는 것 같다 ㅎㅎ
RequestBuilder에 대해 대략 작성해봤다. 아무래도 StatusLine에 대한 작업이 선행돼야 할 것 같다. 현재 구조에서 Header 안에 StatusLine을 넣어놨기 때문에 빌더로 표현하기가 번거롭기 때문이다. 어거지로 할 수 있긴 하지만 문제점을 알기에 다른걸 먼저 하기로 결정했다. 코드를 살펴보면서 RequestMessage에 대한 생각도 해봤는데, 꼭 필요한가에 대한 것이었다. GetRequest같은 식으로 표현해도 지금 구조에서는 크게 차이가 없을 것 같았기 때문이다.
추가로 문제되는 부분은 GET에 Body를 어떻게 표현하느냐인데 나중에 서버 옵션으로 지정할 수 있도록 해주면 되지 않을까 싶다. 그리고 해당 부분은 데이터가 application/json 과 같은 컨텐츠 타입으로 오는 경우이기 때문에 이런 부분도 생각해봐야 할 것 같다.
REST Docs에 예외 표현을 하던 것을 쓰고 있다. 다시 돌아보니 복습이 된다. 오늘 안에 쓰고 싶었는데 마무리하지는 못 했다. 내일 마무리 해봐야겠다.
StatusLine 작업에 앞서 StartLine으로 이름을 바꿔줬다. 속이 시원하다.
어제 리뷰했던 부분 중에 잘못 생각한게 있어서 노을과 얘기했다. 잘 생각하고 리뷰 달자
ParameterizedTest에 대해 짧은 토론도 했다. 이게 오히려 가독성이 안 좋아 assertAll로 테스트 케이스를 표현해뒀기 때문이다.
개인적으로 assertAll은 테스트 케이스를 나누는 것 보다 하나의 테스트에 여러개의 검증이 필요할 경우 확인하는 용도라 생각해서 많이 당황스러웠던 것 같다.
어찌됐건 핵심은 하나의 테스트에 테스트 케이스도 하나여야 명확하다는 것이었다. ParameterziedTest도 보기에는 하나의 테스트에 여러개의 테스트 케이스 같아 보이지만, 사실은 여러개의 테스트를 만들어주는 것이기에 좋다고 생각했다.
어려운 주제인 것 같은데 시간나면 좀 더 찾아봐야 겠다.
어제 쓰던 글을 마무리했다. 썸네일에 대해서 고민하다가 아예 썸네일 생성기를 만들어버린 사람을 봤다. 익숙한 썸네일들이 이걸로 만든거였구나 하는 생각이 빡 들었다.
불편한 점은 색깔 지정을 직접 할 수가 없다는 점... 그리고 url로 파일을 넣으려고 하니 잘 되지 않았다. 그래서 그냥 페인트닷넷으로 템플릿을 만들어버렸다.
안그래도 요새 일렉트론이나 리엑트 네이티브를 공부해볼까 하고 있는데, 혼자서 만들어볼만한지 생각좀 해봐야겠다.
Powered with by Gatsby 2.0