같이 일하고 싶은 개발자

최종 프로젝트가 진행된지 어느덧 3/5 정도가 지났다. 이 기간동안 정말 많은 일들이 있었고, 많은 감정들을 느끼게 되었다. 그런 내가 보고 듣고 느낀 감정들을 회고하고, 글로써 표현함으로써 내 감정에 더욱 솔직해지고, 내가 더 성장하기 위해 글을 남긴다. 정말 많은 고민을 하게 된 한 주였다.. 내 감정에 솔직해져보자.. 나는 성장하고 싶은 사람이다. 그래서 욕심이 많다. 물욕이 많은게 아니라 더 성장하고 싶은 욕심이 많다. 그래서 항상 나의 성장에 포커스가 맞춰져있다. 어떻게하면 내가 더 성장할 수있을까? 결국 내가 성장하려면 한걸음 더 나아가야한다고 생각하고, 고민의 스펙트럼과 계속해서 더 나은 방향으로 고민하고, 나아갈 수 있도록 의견을 제시해야한다고 생..

사건의 발단은 이랬다. 내가 조건에 맞춰 queydsl을 이용해서 원하는 데이터를 DTO로 뽑아서 조회하고싶었다. DTO로 뽑아오는 도중 많은 오류를 만났었고, 어떤 오류인지, 어떻게 해결하는지 직접 검색하고 찾아보면서 문제를 해결해 나가고 있다. 그러던 와중에 문득 데이터를 어떻게 뽑아오지? 라는 생각을 했다. 예를들어서 post 와 recommend 라는 테이블들이 각각 있으면 이들은 1:M // M:1 (양방향) 관계를 맺고 있다. 내가 원하는 것은 각각의 post에 맞춰서 recommend를 count 해오는 것이였는데, 어떻게 이를 count 해올 수 있을까? 라는 생각이 들었다. 먼저 where 조건절에 post.id.eq(recommend.post.id) 이렇게 조건을 주니 내가 원하는 데이..

최종 프로젝트가 시작한지 어느 덧 1일정도 지나가고있다. 오랜만에 서비스를 A-Z까지 기획하고, 설계하며 여러 고민들 속에 최고의 결과물을 도출해내기 위한 이 과정이 너무나도 재밌다. 개발도 개발 나름이지만 기획도 매우 재밌다. 옛날부터 뭔가 나는 누군가를 대상으로 이벤트 기획하고, 기획한 행사를 주도해서 이끌거나, 항상 집단을 리드하고자 하는 성향이 강했다. 이러한 성향덕에 적게는 몇 백 많게는 천 명 단위의 집단도 이끌어보며 이 속에서 좋은 추억과 경험을 간직하고, 또 내 나 자신이 스스로 성장할 수 있도록 많은 환경들을 만들어 냈다. 각자의 속도와 배경 지식들은 능력은 다 제각각이다. 나도 맨처음 누군가 잘 따라오지 못하고, 방황하거나, 엊나가면 "왜 저사람은 그럴까?" 라는 생..

최근에는 어떻게하면 검색효율을 높일 수 있을까?에 관한 고민과 동적 쿼리에 관한 고민속에서 얻은 해답 중 하나인 Query dsl을 학습했다. 매일매일 이렇게 TIL로 남기기에 애매하다고 생각해서 학습을 끝내고 복습하는 과정에서 정리를 진행하고, TIL을 작성해야겠다고 생각했기에 요 최근엔 TIL이 밀렸었다. 매일매일 학습한 내용을 뭔가 글로써 남기기 어려워졌다. 이렇게 생각한 이유는 과거에 모르던 부분이 많아서 매일매일 학습한 내용을 정리하며 TIL을 작성하거나 블로그에 글을 써내려갔었는데, 이제는 그래도 어느정도 아는 부분이 생기다보니 블로그에 포스팅 하는 빈도수가 줄었다. 그렇다고 해서 공부에 부실하는 것이 아닌, git에는 매일매일 commit 하도록 노력하고 있으며 Commit Message를 ..

본 내용은 infrearn 김영한 님의 query dsl 강의를 수강 후 정리한 글입니다. 코드 위주의 설명보다는 해당 강의를 보고 얻게된 지식이나 인사이트와 관련된 글입니다. 또한 Query dsl에 관한 저의 느낀점과 학습한 점을 정리한 것이라 Query dsl 사용 관련 내용을 담고 있지는 않습니다.. 목차 Query dsl 들어가기 내가 학습한 Query dsl ( 의존성만 등록해봅시다 ) Query dsl 마무리 Query dsl 들어가기 네? query dsl이요? 그게 뭔가요? querydsl을 알게 된 것은 작년 이맘 때쯤이였다.. 졸업작품 프로젝트를 시작하고, 어떻게 데이터를 검색할까에 관한 물음의 답이 바로 Query dsl이였다. 기술적 의사결정을 내린 후 본격적으로 query dsl..

Keep (이번 프로젝트에서 좋았던 점을 통해 앞으로 유지(Keep) 할 사항) 2명씩 팀을 매칭해서 분업하는 구조 속에서 얻는 지식의 스펙트럼 고정된 사고를 깨버림으로서, 다시 한번 놓인 부분을 점검할 수 있었다. 항상 긍정적인 마인드셋, 그 속에서 얻는 최강의 시너지! 코드 리뷰 코드 윗미 기능을 활용한 개발 방식 항상 열린 질문과 답변 이번 프로젝트에서는 팀원들을 지도하고, 프로젝트의 방향성을 정하며, 평소에 내가 놓치고 있었던 부분이나, 고정적인 사고의 틀을 벗어나고 유연한 코드를 작성할 수있도록 도와준 미니 프로젝트라 생각한다. 메서드를 구현하는데, 계속 고정관념에 사로잡혀서 어떻게 이를 해결하면 좋을까?에서 멈춰있던 내 사고를 깨버리는 사건도 있었고, 어떤 코드에 관해 생각하는 바가 다르니 서..

심화 프로젝트 - KPT 회고 KEEP 다같이 API를 직접 작동시켜 QA를 진행함 의미있는 commit message와 Git 전략의 사용 시작 단계에서 API 문서 작성을 하여 개발 단계에서 참고하면서 개발 할 수 있었던 점 일정에 맞춰 계획한 코드를 모두 구현 한 점 상호 피드백을 통해 더 나은, 더 클린한 코드를 작성하도록 노력 domain별로 폴더를 구성한 점 PROBLEM 정해놓은 구현목표 이외의 도전해보지 않았음 맡은 기능에만 충실하여 다른 팀원들의 코드를 아직 완벽하게 다 이해하지 못한 점 의미있는 데이터에 관한 생각 어떻게하면 더 clean하게 code를 작성할 수 있을까? 테스트 코드를 작성하여 테스트 못해본 점 TRY 테스트 코드 작성 해볼 것 데이터를 더욱 효율적으로, 그리고 의미있..

FACTS(사실, 객관) : 이번 일주일 동안 있었던 일, 내가 한 일 query dsl 학습 및 심화 프로젝트 진행 심화프로젝트를 빠르게 완성시키고 추가 구현사항 혼자 만들어 보면서 해당 로직을 검증 test case 만들어서 모든 경우의 수 생각해보기... FEELINGS(느낌, 주관) : 나의 감정적인 반응, 느낌 집중하자, 빨리 query dsl이랑 이것저것 공부해서 시간을 효율적으로 써야겠다 FINDINGS(배운 것) : 그 상황으로부터 내가 배운 것, 얻은 것 query dsl 로직 한 메소드는 하나의 책임만 해야 한다 FUTURE(미래) : 배운 것을 미래에는 어떻게 적용할 지 1. query dsl 적용해보기 - 사용할 것

들어가기 스웨거 적용해보기 마무리 들어가기 처음으로 스웨거라는 라이브러리를 적용해보았다. 스웨거는 API를 자동으로 문서화 해주는 기능으로, 사용자가 직접 test 까지 해볼 수 있는 장점이 있다. 스웨거? Rest Apu를 문서화 혹은 빌드 등을 위해 사용하는 OpenAPI 사양을 중심으로 구축된 오픈 소스 도구 세트 https://swagger.io/ API Documentation & Design Tools for Teams | Swagger swagger.io 기존에 진행했던 프로젝트들에선 postman과 직접 노가다?를 통해 API 명세서를 작성했었는데, 이를 사용함으로서 더욱 깔끔하고 편하게 작업을 진행할 수 있었다. 이로서 생산성을 높일수 있는 장점이 있었다. 스웨거 적용해보기 먼저 첫번째로..

새로운 어노테이션을 알게 되었다. @DynamicInsert : insert 시 null인 필드를 제외한다 @DynamicUpdate ; update 시 null인 필드를 제외한다 해당 어노테이션을 Entity에 사용하고 쿼리문을 확인해보면 DynamicInsert 는 컬럼의 지정된 default 값을 적용시킨다. 기존에 @Query 파라미터를 이용해 데이터를 조회하고, 삭제 등 여러 기능에서 만들어서 사용했었는데, 어쩌다 이야기를 하다보니 NativeQuery라는 키워드가 언급되서 찾아보게 되었다. Native Query란 SQL을 직접 정의해서 사용하는 방식이다. 아! @Query 파라미터를 이용해서 쿼리를 직접 작성하는 방식이 네이티브 쿼리구나!