본문 바로가기

전체 글

 (50)
Fetch Join 배경프로젝트 피드백을 받으면서, 튜터분들이 항상 질문하던게 있다. '그렇게 하면 성능이 많이 떨어질 것 같습니다.. 혹시 N+1 문제 고려를 해보셨을까요?', 'DB에서 쿼리를 날려서 가져올 때마다 계산을 진행하게 되면 성능이 많이 저하될것 같은데 다른 방법 혹시 생각해보신거 있을까요?' 등등.. 항상 성능에 관한 것들이 대부분이었던 것 같습니다. 그만큼 현업에서는 성능에 초점을 맞추고 있다는 거겠죠? (물론 비즈니스 로직을 잘 만든다는 가정하에...) 저는 아직까지 비즈니스 로직을 잘 구현하지는 못합니다만..(도메인도 많이 다뤄보질 않았구요 ㅎㅎ) 앞으로는 비즈니스 로직을 구현 하면서 성능 문제도 어느정도 고려를 해봐야 겠다는 생각이 들었습니다. 그중 가장 크게 생각나는 것이 바로 DB와 App간의 소..
Block vs Non-Block & Sync vs Async 배경오늘도 우아한테크의 테코톡을 보며 내용을 정리해 보는 시간을 가져보겠습니다. Sync vs Async? 동기와 비동기를 말하는 것 같은데 이 부분은 평소에 관심이 좀 있던 부분이었으나 Block vs Non-Block은 어떤 것인지 살펴보도록 하겠습니다. 내용Block vs Non-Block먼저 block에 대해서 이야기 해보겠습니다. blocking이란 자신의 작업을 진행하다가 다른 주체의 작업이 시작되면 다른 작업이 끝날 때까지 기다렸다 시작하는 것을 말합니다.  non-blocking이란 다른 주체의 작업에 관련없이 작업을 하는 것입니다. blocking과 non-blocking의 가장 큰 핵심은 다른 주체가 작업할 때 자신의 제어권이 있는지 없는지로 판단한다고 합니다.  Sync vs Asyn..
Thread Pool 배경우아한테크의 테코톡을 보고 배운 내용들을 간단하게 정리해 볼까 합니다.  내용Program  / Process / Thread 스레드를 사용하면서 하나의 프로세스 안에 두 가지 이상의 작업을 병렬 처리 가능(CPU Core가 여러개일 경우) 그러면 단순히 thread를 무한히 늘리면서 작업을 할 수 있을까요? 하나의 요청에 대해서 하나의 thread를 생성하게 된다면 어떻게 될까요? thread는 생성 비용이 크기 때문에 점차 늘어날 수록 메모리를 많이 사용하게 되면서 서버 응답시간이 늘어나게 됩니다. 특히 Java의 경우 One-to-One Threading-Model로 thread를 생성하게 됩니다. process의 처리속도보다 빠르게 요청이 들어오게 된다면 thread가 무한히 생성되게 될 겁니..
static method(정적 메서드) 배경정보처리기사 실기를 공부할 때 외우기에 바빴던 디자인 패턴... 실제 프로젝트에서 어떻게 쓰일까 생각만 하고 있었는데, 진행했던 프로젝트의 피드백을 받으면서 response dto 클래스들을 반환할 때 생서자를 이용하는 대신 static method를 활용해 보는것도 생각해 보라는 의견을 주셨습니다. static method 명명규칙으로 함수명을 만들게 되면, 함수 명만 보고도 어떤 기능을 하는지 유추할 수 있기 때문에 좋을 것같다... 라고 하셨는데 처음엔 이해가 잘 가지 않았습니다. 무슨 말일까...? 싶었지만 같이 보내주신 블로그 글을 보면서 '아 이럴 때 사용했었고 이런 의미였구나!'라고 느꼈습니다. 내용참고한 블로그의 글은 아래쪽에 적어놓도록 하겠습니다. 정말 잘 정리되어 있으니 다른 글들도..
Request, Response Logging 배경프로젝트를 진행하면서 테스트 코드에 익숙치 않다보니 App 실행 후 postman을 활용해 작성한 API와 비즈니스 로직을 테스트 하는 경우가 많았습니다. 테스트 코드 작성이 중요하다는걸 알면서도 제 실력 부족으로 납기를 제대로 못 맞출 것 같은 느낌이 들어서 자꾸 어느정도 코드를 완성하고 App으로 실행하게 되네요.. 실력 부족은 차차 매꾸는걸로 하고... 일단 맨날 local에서 postman으로 테스트를 하다가 github action으로 ec2에 직접 올려서 배포 환경에서 테스트를 팀원들과 진행하게 되었습니다. 일과시간 중에는 상관이 없지만 일과 시간이 끝나고 각자 따로 작업해서 자동으로 ec2에 배포가 될 때, 서버에 문제가 생기는 경우가 발생하기도 했습니다. 일단 늦은 밤 팀원들에게 메시지..
Swagger 적용해보기 배경지난번에 살짝 swagger에 대해 언급하긴 했었는데 제가 했던 프로젝트에 직접 적용해 보았습니다. 시간이 좀 걸리더라도, 다른 기능들을 좀 더 개발을 하는 것보다도 이 작업을 택했던 이유는 앞으로 저는 협업이 훨씬 많아질 것이기 때문이죠. 이전에 회사를 다닐 때에도 나 혼자 일을 잘하는 것도 좋지만, 서로 협업 할 때는 내가 나아가는 방향과 진척도를 상대에게 얼마나 잘 전달하느냐에 따라서 능률이 정말 많이 차이난다는 것을 느꼈습니다.내용swagger 선택 이유는 다음과 같습니다.1. 프로젝트를 모르는 개발자가 쉽게 이해할 수 있도록 한다.2. UI를 통해 이해가 쉽다.3. 직접 API를 날려볼 수 있다.장점만 있는건 아닙니다. 단점으로는- 소스 코드가 매우 지저분해집니다. custom을 통해 특정 ..
Java의 제네릭 이용 배경코딩을 다시 하게 되면서 제 실력이 어느 정도인지 알게 되는 것 같습니다. (아직 제대로 할줄도 모르지만요 ㅎㅎ..)지금 하고있는 프로젝트는 이전에 강의를 보면서 만들어 놓았던 것을 대부분 참고해서 만들어 갔다고 해도 과언이 아닐겁니다. 정신이 없는 상태로 하던 나날 중 개발자 친구와 술한잔을 하게 됐습니다. 이런 저런 이야기를 하던 도중 신입에게 가장 중요한건 기본. 지금 바로 옆에 사람이 와서 왜 이렇게 코드를 짜냐고 물어도 자신있게 대답할 수 있는 것이 중요하다고 조언해주었습니다. 다음날, 저는 제가 짠 코드를 좀 보면서 되짚어보았습니다. 무슨 목적으로 내가 이렇게 만든걸까? 명세서에 있던 고객의 요구사항이 이런 기능이 맞을까?... 이러한 생각들이 반복되면서 중복되는 값이 많은 dto들 대체 ..
Swagger를 이용한 Spring Boot API 명세작업(1) 배경비전공자로서 이전에 명세작업이 왜 중요한가 궁금했었을 때, 직접  작성하고 프로젝트를 하니 정말 차이가 크다고 느꼈다는 것을 이야기 했었습니다.왜 개발자분들이 프로젝트 시작 전 세팅에 시간이 가장 많이 걸릴까를 조금이나마 이해한 부분이었죠. 기초를 잘 닦아놓으면 그 뒤는 자연스럽게 이어지거든요. 하지만 길잡이를 꼭 API 문서만 놓고 갈 필요는 없을 것 같습니다. 물론 아주 큰 대형 프로젝트라면 명세서만 따라야겠지만, 소규모의 프로젝트에서는 API로 큰 틀을 바로 잡아놓고 직접 코드를 만들어가면서 수정해야 할 부분이 많겠죠. 내용API가 작업 중간중간 변하게 되면 명세서를 계속해서 작업해야 하는 일이 발생하게 될겁니다.저는 백엔드 개발자로서 나중에 회사에 들어가면 프론트엔드 분들과 함께 일하게 될텐데..

티스토리툴바