Im-D 재정비 기간을 가지기로 했다. OS 스터디를 계속 하고 있지만, 특히 최근들어 꾸준히 진행되지 않았다. 지금 생각해보면 꼭 하고 싶다면 날짜나 시간을 바꿔서라도 할 수 있었을텐데 전체적인 에너지가 많이 떨어진 느낌이다. 뭐가 됐든 환기가 필요한 시점인것 같다. 다른 친구들도 관련 얘기를 계속 하긴했지만, 나는 OS를 믿고 외면했던 것 같다. 재정비 기간을 갖고 새로운 원동력을 잘 찾아봐야한다. 그래도 다행인점은 그룹 자체에 애정이 남아있는 것 같다는 점이다. 솔직히 어떻게 이어질지 잘 모르겠다. 그래도 고비를 잘 넘기면 새롭게 나갈 수 있을거라 믿어봐야겠다.
객체와 관계 사이가 안 맞는 것을 impedance mismatch라고 한다. 전기쪽 용어에서 따왔다고 하는데, 자세하게 가면 수식의 향연이라 수학 까막눈인 나는 읽을 수가 없다. 쉽게 얘기하면 스피커와 앰프를 물릴때 저항(임피던스)을 고려해서 물려야 하는 것과 같은 현상이라 한다.
노을은 주말동안 HTTP 학습을 해왔다고 한다. 재밌는 내용이 꽤 있었는데, post도 캐싱이 가능하다고 한다. 이외에도 몇 가지 요소들이 있었는데, 확실히 잘 정제된 강의를 보는게 좋은 것 같긴하다.
나는 객체지향의 사실과 오해를 다시 읽기 시작했다. 면접을 보며 객체지향을 좋아한다고 말했고 얼핏 아는 것 처럼 보이지만, 핵심을 꿰뚫지는 못하고 있다는 느낌을 많이 받았다. 특히 간단하게 설명하는 것이 힘들었다.
다시 책을 보니 예전에 했던 생각들이 많이 떠올라 메모를 해뒀다. 블로그를 왜 써야 하는지 다시 한 번 느낀다. 남을 위한 블로그가 아니라 나를 위한 블로그가 우선이라 생각하고 해보자.
오늘 얘기를 해보니 각자 공부한 내용을 서로에게 발표해보는 것도 좋을 것 같다는 생각이 들었다. 이번주는 각자 발표준비?를 하는 것을 목표로 잡았다.
코드 리뷰를 하다 트랜잭션을 처리하는 다른 방법이 있지 않을까 해서 좀 더 고민해봤다. 가장 쉬운 방법은 트랜잭션으로 묶을 클래스를 만들고 콜백으로 테스트를 넣어준다. 지금 해놓은 것과 유사한 방식이다.
또 다른 방법은 트랜잭션을 직접 호출하는 것이다. entitymanager에서 트랜잭션을 직접 불러오는 것은 제대로 동작하지 않았다. PersistanceContext로 주입해서 그런 것 같은데 책을 우선 읽어보고 잘 안나오면 테스트를 해봐야 겠다. 검색으로는 못 찾겠다. 아무튼 스프링의 트랜잭션 매니저를 호출해주면 된다. 시작하면서 열어주면 될 것 같지만, BeforeEach의 동작은 순서가 보장되지 않아 문제가 될 수 있다. 콜백을 위한 템플릿 메소드를 만들면 되긴 한데, 어쨌든 부자연스러운 코드가 계속 생긴다.
원하는 것은 개발자가 추가적인 코드 조작 없이 테스트를 진행할 수 있도록 하는 것인데, 어떻게 하는게 좋을지 고민이 많이 필요해보인다. 얘기를 해봐야겠다.
테스트에 시간이 점점 오래걸려 걱정이라는 얘기가 있었다. 지금 5초정도 되는데 나중에는 1분정도까지 늘어날 것 같다. 그래서 테스트를 병렬로 실행시킬 수 있는 방법을 찾아봤다. 구동 자체는 어렵지 않았는데, 데이터베이스 동시성 처리가 제대로 되지 않아 문제가 생긴다. 좀 더 고민해봐야 할 문제다.
이외의 방법으로는 컨텍스트를 재활용할 수 있도록 만드는 방법이 있다. 이 점을 잘 활용해야 할 것 같다. 그리고 쿼리가 많이 느려지게되면 최적화도 고려해봐야 할 것 같다. https://devhood.tistory.com/249 https://okayjava.tistory.com/36
영속성 컨텍스트를 공부하고 나니 의문이 하나 생겼다. 별도의 트랜잭션 없이 스프링의 서비스에서 레포지토리 메소드를 호출하고 나면 트랜잭션이 종료된다. 그러면 영속성 컨텍스트에서 엔티티가 분리돼야 할 것 같았다. 하지만, 탐색이 잘 된다. 책을 찾아보니 OSIV가 나오는데 후반부라 그런지 너무 어렵다..ㅋㅋ 직접 실험해보기로 했다.
여러번의 삽질끝에 OSIV를 끄면 제대로 작동하지 않는 것을 확인했다. 이유는 알았으니 공부를 해보자.
풀 리퀘스트에 여러 작업 단위가 섞이면 추적이 힘들다. 커밋을 잘게 나눈 의미가 퇴색된다. 이외에도 협업에 곤란해지는 상황이 생길 수 있다. 특정 기술이나 기능이 특정 부분에만 필요한게 아니라 전역으로 사용되는 경우에 해당 기능이 어디까지 구현된건지, 어디서부터 고쳐야 하는지 파악하기 힘들어진다. 단순히 기능 추가가 된 부분이라면 그나마 낫지만, 논의 없이 충돌해결이 되거나 다른 곳 까지 영향을 미치는 기능 변경이 생긴다면 조금 곤란해진다.
이번에 비슷한 경우가 생겼는데, 내가 구현한 부분과 충돌이 나는 부분이 생겨 다른 팀원이 충돌을 해결했다. 충돌을 해결하며 동작하는 테스트를 만들었고 코드는 문제없이 잘 작동한다. 하지만, 기능이 추가되면서 내가 만든 부분에 수정이 필요했던 것이라 추가적인 테스트 코드가 필요한 상황이다. 코드 리뷰를 하며 해당 사항을 인지하고 이슈로 남겨놨지만, 만약 놓쳤다면 해당 부분에서 문제가 발생하기 전까지는 테스트 코드 추가를 하지 않았을 것이다.
pr단위를 어떤 식으로 나누어야 하는지 아직도 어렵다. 그리고 너무 잘게 잘라도 비효율적일 것이다. 하지만, 어떤 문제가 발생할 수 있을지 인지하였으니 앞으로는 이런 부분을 고려해서 개발 단위를 나누어야 할 것 같다.
드디어 동작한다. 이전 코드에 큰 문제가 있었던 것은 아닌 것 같다. gradle 버전 7을 사용할 경우 호환이 제대로 되지 않는 것이 문제였다. 현재 환경에서 제대로 구동하려면 추가적인 작업이 필요한데 일단은 문서를 띄워보는게 우선이니 버전을 6으로 낮추고 진행했다. 이제 잘 꾸미는 법을 알아볼 차례인데, 조금 겁이 난다..ㅋㅋ
처음으로 임원면접을 보게 됐다. 회사의 인재상이나 핵심 가치 등을 보며 준비를 했는데 기술면접이 훨씬 쉬웠던 것 같다.
어려웠던 점은 지금까지 있었던 경험과 나의 강점을 연결시키는 부분이었다. 지금까지 자소서를 쓸때 이런 부분을 제대로 고려하지 못했던 것 같다. 그러다보니 자소서와 일관성이 떨어지게 되는 느낌도 받았다. 그래도 이런 부분은 TIL을 되돌아보면서 도움을 크게 받았다. 취업 시즌 끝나기 전 까지는 여유가 많이 없을테니 끝나면 결산을 우선순위로 두고 꼭 해야겠다.
면접은 생각치 못한 클린코드에 관한 질문이 들어오게돼서 많이 당황했다. 그 이전에 개발 이외의 부분에서 나의 강점이 발휘된 경험이 있는지 물어본 부분도 당황하게 된 요소였다. 필요없을거라 생각했는데 삶의 전반적인 부분을 검증한다는 의미에서 물어봤던게 아닌가싶다.
기술질문은 내가 깔끔하게 답변을 못해 꼬리 질문이 온 것이니 아쉽지만 어쩔 수 없다. 크게 아쉬운 부분은 인성질문에서 준비했던만큼 보여주지 못한 것 같은 느낌이 드는 것이다. 나의 강점과 기업의 문화를 잘 연결시켜야 설득력이 있었을 것 같은데 그런 부분이 많이 부족했다. 페이스가 말려도 잘 잡고 가야하는데 가장 어려운 부분이다.
클린코드는 응집성과 결합도 코드스멜 등을 근거로 들었으면 쉽게 갈 수 있었을 것 같은데, 질문 요지를 처음부터 이해하지 못해 많이 돌아가게 됐다. 클린코드랑 객체지향은 꼭 다시 봐야겠다. 너무 부끄럽다..ㅋㅋ
사실 어제부터 아무것도 하지 못했다. 그래서 TIL도 몰아서 쓰는 중이다. 그간 스트레스를 많이 받았는데 제대로 풀지 못했던 것 같기도 하고, 긴장도 풀리면서 인텔리제이를 켤 엄두가 아예 나지를 않았다. 괜히 깃헙만 켰다 껐다 하다가 아무것도 안 했다.
이럴 때 걷기여행 같은거 다녀오면 엄청 힘이 됐던 것 같은데, 시즌이 아직 남아 여의치 않은게 너무 안타깝다. 별 수 있나, 그래도 해야지 ㅋㅋ
좀 걱정되는 부분은 이런 주기가 계속 반복되고 있는 것 같다는 점이다. 물론 처음 보는 면접들이라 완전 쏟아부어버려서 그런 것도 있지만, 그렇다고 컨디션 조절에만 힘쓰면 기회를 그냥 날려버리는 느낌이라 마냥 그럴 수도 없다.
거의 처음으로 개발 이외의 글을 쓰는 것 같은데, 개발활동에 지장이 생겨 남긴다. 혹시나 계속되면 이 글을 다시 보고 그때는 푹 쉬어버리자. 이번이 끝은 아닐거니까.
오늘은 내일 코테를 위해 컨디션을 올리기 위해서 쉬운 알고리즘 문제를 조금 풀어봤다.
그간 면접준비에 매진하느라 문제풀이를 안 하고 있었다. 그럼에도 꾸준히 했어야 하는 생각이 중간중간 보는 코테에서 느껴지긴 했지만, 그런다고 결과가 크게 달라졌을 것 같지도 않은게 조금 안타깝다. 많이 쌓여야 하는건데 그 전까지 눈에 띄는 효과가 나타나지 않으니 참 힘든 작업이다.
그간 미뤄놨던 소수 구하기를 다시 해봤다. 방식은 손이 외우고 있었다. 이것 저것 찾아보고 생각해보면서 나름의 검증을 해봤는데 납득할만한 결과를 얻었다. 워낙 간단한거라 정리를 할지말지 고민하다 일단 문제 메모에 작성해놨다. 지금 생각해보니 까먹을 것 같아서 정리해두는게 나을 것 같다. 내일 써야지.
하나 더 풀었는데, 경우의 수가 트리처럼 확장되는 구조였다. 순열과 비슷하긴한데, 단순히 순열을 구하기에는 한 번에 구해야 하는 경우의 수가 너무 많다고 판단됐다. 각 분기마다 두개의 경우의 수를 저장해야 했기 때문이다.
그간 경우의 수 문제가 나오면 처음부터 접근을 하지 못해 시간을 낭비하거나 어렵게 돌아간 적이 많았다. 앞으로는 처음부터 그래프를 가정하고 풀어버리는게 나을 것 같다.
생각보다 너무 쉬웠다. 그래서 걱정된다. 쉽다고 느낀 시험은 거의 다 떨어졌었던 것 같아서 ㅋㅋ
cs문제를 빡세게 내려나 보다.
지금까지 잘 안 되던게 그레이들 문법 때문이었다. 버전이 올라가며 바뀌었나보다. 조금 미워지려고 한다...
이래저래 해서 목차 띄우기까지 성공했다. 크게 어렵진 않은데, 고민거리가 생겼다.
에러별로 주소를 다르게 지정해줘야 케이스 별로 예외를 알려줄 수 있다. 이러면 작업량이 꽤 많아질텐데 살짝 걱정이다. 마찬가지로 변화가 있는 부분은 스니펫 생성 디렉토리를 다 다르게 지정해줘야 한다.
큰 프로젝트 같은 곳들을 살펴보고 생각해봐야겠다.
Powered with by Gatsby 2.0