멀티모듈은 정말 자유자재로 필요에 의해 만들어지는 것을 볼 수 있다. 이번 글에서는 어떤 상황에서 module 분리를 고려해야하는지에 대해 고민한 것을 짧게 공유하고자 한다. 어떤 상황에서 module 분리를 고려해야 할까? 모듈은 패키지보다 더 큰 개념으로, 패키지에서 분리의 필요성을 느낄 경우에 module로의 분리가 필요하다. 그렇다면 패키지에서 분리, 구분의 필요성을 느끼는 경우가 무엇이 있을까? 1. 참조 불가 수준의 코드 분리 2. 실행의 분리 찾아보고 고민해봤을 때 이 두가지가 있다고 느껴졌다. 1의 경우에는 Layer 별로 모듈을 구분하며, 레이어의 룰들을 모듈에 잘 녹여서 참조의 흐름을 일관성있게 가져갈 수 있다. 그리고, dependency도 레이어에 맞는 것들만 가져갈 수 있다는 것이..

최근에 한 지역을 먹어버린 학원의 원장 선생님과 대화를 할 기회가 있었다.  나는 메타인지에 관심이 많기 때문에 메타인지와 학업 성취도에 정말 큰 영향이 있는가?"에 대한 질문을 먼저 했다. 그에 대한 답으로 메타인지는 시간을 굉장히 효율적으로 사용할 수 있게 해준다. 그래서 똑같이 열심히 한다면 메타인지가 잘 되는 친구들이 더 좋은 학업 성취도를 가져간다고 했다.  그리고 나는 공부 잘하는 애들의 특징을 물어봤다. 공부 잘하는 애들의 특징은 공부에 때려박는 시간부터가 다르다고 한다. 그 시간 자체가 다른 지름길들이 아무런 의미가 없게 한다고 한다.  나도 요새 느끼는 중이다. 어떻게 하면 효율적이지를 고민하면서 1년을 보냈지만, 이 시기에 중요한 것은 어떻게 하면 훨씬 많은 시간을 사용하지? 라는 고민..

테스트 코드를 작성하다보면, Fixture를 어떻게 만들지 고민할 때가 많다고 느껴진다. 크게는 모듈을 분리하는 것부터, 작게는 메서드 안에서 직접 객체를 생성하는 거 까지 할 수 있는 방법이 너무 많다. 그리고 Fixture Monkey와 같은 랜덤 데이터로 객체를 생성해주는 라이브러리가 있다. 이번 글에서는 Fixtiure Monkey라는 네이버에서 지원하는 라이브러리를 쓸지 말지에 대해서 이야기 해보도록 하겠다. Fixture Monkey가 뭘까? Fixture Monkey를 한줄로 정리하면, 제어가능한 임의의 테스트 객체를 생성하는 가장 쉬운 방법이다. Fixture Monkey 기능 1. 간편하게 랜덤하고 복잡한 제약조건을 가지는 객체 생성 Jqwik기반으로 JSR-303, JSR-380 ann..

오늘 개금에서 화명으로 택시를 타고오면서 택시 운전사로 연에 일억 천 버는 사람을 만났다. 1990년대 초부터 택시 운전을 하시면서 자식 셋을 부족함 없이 키우신 것에 대해서 자부심을 가지고 계셨다. 어떻게? 개인택시를 하시고, 밤이랑 밤 아닌 시간으로 2번 나눠서 일하신다. 밤에는 10만원 할당량을 채우고, 낮에는 20만원 할당량을 채운다고 한다. 그러면 하루에 30만원, 대략 한달에 30일 매일하면 900만원이다. 그리고 이 일을 12개월 동안하면 약 일억천팔백이 나온다. 이렇게 말하면 쉬워보일수도 있는데, 습관이 들지 않은 사람이 하면 과로사 할수도 있다. 그리고 택시기사의 실질 수입은 194만1000원으로, 평균과 비교해봐도 매우 높은 수치이다. 여기서 핵심은 젊을 때 일하는 습관을 만들어 놓으신..

이번에 멀티 모듈을 설정하면서 gradle에 처음으로 bootJar와 Jar 설정을 건드려봤다. 깨달은 점은 의존 당할 모듈에서는 jar 설정만 true로 하여서, plain-jar가 생성되게 하고, 최상단에서 Application 파일을 가지고 있고. 실행될 모듈은 bootjar만 필요로 한다는 것이었다. 이번 블로그에서는 bootJar와 jar의 차이, jar 파일과 plain-jar 파일의 차이를 다룬다. bootJar와 Jar 설정에 대한 결과 설정에 대한 결과를 알아보기 전 설정 방법을 간단하게 알아보자면, 아래와 같은 설정을 적용하고 싶은 모듈의 gradle 파일에 넣으면 된다. bootJar { enabled = false // bootJar 설정을 false로 한 것입니다. } jar { ..

스프링 시큐리티는 쉬운 인증 인가 구현과 보안을 구현해주는 프레임워크라고 널리 알려져있다. 그러나 나는 항상 개발을 하면서 스프링 시큐리티에 대한 반감이 있었다. 그래서 이번엔 그 반감의 원인을 파악해보고, 과연 스프링 시큐리티를 사용하는 것이 올바른 생각인지 확인해보겠다. 나는 왜 반감이 있는가? 반감의 이유를 한줄로 정리하자면, 스프링 시큐리티가 해주는게 없다고 생각해서이다. 내가 스프링 시큐리티가 해주는게 없다고 느낀 이유는 JWT 인증 방식만 사용해왔기 때문이다. 스프링 시큐리티와 JWT를 사용해서 인증 인가를 구현하고자 한다면, 정말 스프링 시큐리티가 해주는게 없다고 느껴진다. 직접 JWT 필터를 구현해서, 약 12개나 되는 필터 사이에 끼워서 사용한다. 이 과정에서 스프링 시큐리티에 대한 팀원..

친구중에 프론트엔드 개발로 당근에 갔다온 친구와 많다면 많은 대화를 나눴다. 나는 백엔드고 그 친구는 프론트엔드라서 약간의 간극이 있겠지만, 나에게 너무 좋은 기회였고, 상당히 많은 인사이트를 얻었다고 느껴진다. 대화를 하면서 느낀 신입에게 요구되는 것 1. 자신의 생각 흐름을 서술할 수 있는 능력 2. 기술에 대해 깊이 알고 있음과 깊게 생각할 수 있는 능력 이거 두개라고 느껴졌다. 그 친구와 협업의 관점에서 이야기를 많이 나눴는데, 결국 2가지 다 코드리뷰와 큰 연관성이 있다. 코드 리뷰는 주니어 개발자의 관점에서, 시니어 개발자의 시간을 뺐는 활동이다. 그렇기 때문에 주니어 개발자는 시니어 개발자가 최대한 빠르게, 쉽게 코드리뷰를 할 수 있게 도와야 한다. 그렇기 때문에 자신이 어떤 생각으로 코드를..

요즘 개발을 하면서, 코드 리뷰가 완벽하지 않다는 것을 항상 느끼고 있다. 간단한 코드 컨벤션부터, Security Hotstop까지 많은 부분을 놓치고, 그 코드가 프로덕션 환경으로 나가는 경우가 종종 발생한다. 그래서 기술로 그러한 문제들을 해결하고자 나온게 코드 정적 분석 도구들이다. 이번 시간에는 현재 내가 처한 상황에서, 대표적인 무료 도구인 SonarCloud와 Qodana를 비교한 후 어떤 도구를 사용할지, 혹은 그냥 사용하지 않을지, 혹은 다 사용할지 고민하는 글을 작성해보고자 한다. 현재 나는 어떤 상황인가? 1. 프로젝트를 2개 진행하고 있다. 하나는 2년동안 서비스 중이고, 다른 하나는 이제 막 시작에서, MVP를 거의 완성하고, 프론트엔드랑 빠르게 소통하며, 코드리뷰 없이 DTO를 ..