집짓기 대신 개발

팀을 초기에 세팅할때 유닛 테스트 관련 컨벤션을 꾸리는데 여러 고민에 빠지게 됩니다.. 유닛테스트의 범위와 규모 TDD를 중심으로 할 것인가? 일반 유닛테스트와 통합테스트만을 중심으로 개발할 것인가? 여러 고민을 하게 됩니다. 해당 글은 이런 고민 속에서 테스트 커버리지를 어떤 방식으로 확인 하는지에 대한 글입니다. JaCoco를 활용하여 간단하게 테스트 커버리지를 확인하는 방법을 알아보고 이를 통해 팀의 컨벤션을 확보하는데 도움이 되길 빕니다! 우선 JaCoco에 대해 간략히 소개드리면 Java기반 언어를 분석하여 테스트 코드가 커버하는 코드 블락을 확인 후 커버리지 퍼센트를 도출해 주는 도구입니다. 물론 그외에 다양한 기능을 제공하기 때문에 해당 글을 보고 찾아보시면 많은 도움을 받을 수 있습니다. ..

개발바닥 유튜브를 보던 중 [React 불만 大 발설] 영상을 보고 내가 생각하는 React Best Practice를 정리해보면 좋겠다고 생각했습니다. (영상링크 * https://www.youtube.com/watch?v=1V6mQom0paI) 기본적으로 해당 영상에서 말씀하시는 내용 중 OOP가 FE에서 필요한 개념인가? 없으면 어떻게 짜는가? 라는게 영상 내용의 주요 주제 중 하나입니다. 위의 내용들을 제 경험에 투영하여 작성하려하며, 온전히 제 경험에서 나온 내용이라 정답은 아니라는 점을 유의해 주시길 바랍니다. 해당 Practice는 Typescript를 기본으로 하기 때문에 Javascript프로젝트에 도입하기에는 한계가 있을 수 있는 점 유의해 주세요! 해당 Practice에서 사용한 주요..

어떠한 서비스, 프로덕트를 만들 때 가장 고민해야 할 문제가 어떤 게 있을까? 하나의 제품을 만들 때 실제 개발자, 디자이너, 기획자 등 다양한 분야의 다양한 사람들과 협업을 진행하게 된다. 이러한 협업 관계 속에서 우리는 정확한 문제를 찾아야 하고 상대를 설득할 필요가 있다. 이러한 설득 과정에서 상대와 내가 서로 다른 지향점을 보고 있다면 트러블로 발전하게 되고 결국 좋지 못한 결과를 가져오는 경우를 종종 봤다. 나도 이런 문제를 격은 적이 있으며 앞으로도 계속 격게 될 문제라고 생각한다. 하지만 이런 문제들은 결국 제품에 대한 Context를 완전히 다르게 잡고 있기에 발생하는 문제이다. 하나의 팀은 하나의 맥락을 가지고 문제를 찾고 해결해야 한다. Context(맥락) 이란? 내가 말하는 맥락은 ..

혼자서 공부할 겸 프로젝트를 하나 진행하려고 고민하던 중 그래도 나름 괜찮은 아이디어가 떠올라 시작하게 됐습니다. 프로젝트를 진행하면서 진행과정을 블로그에 정리하고 경험을 공유하고자 합니다. 첫번째 글로는 프로젝트의 백엔드 기술스택 선정과 그 이유에 대해 정리해보았습니다. 백엔드 기술스택의 언어로는 코틀린으로 선정했습니다. 이유는 최근에 자바를 이용한 프로젝트를 많이 진행했는데 다양한 편의 기능과 functional + OOP의 장점들을 모두 취할 수 있기 때문에 선정했습니다. 최근 자바에 대항한 JVM언어 중 원탑이 아닐까 생각합니다. 물론 자바와 거의 100% 호환하기 때문에 거기에서 오는 심리적 안정감도 존재했습니다. 레퍼런스에 대한 고민과 문제가 생겼을 때 자바를 이용한 일부 코드를 작성할 수도 ..

Spring 프로젝트를 진행하면서 Query DSL을 언제 도입할지에 대해 고민하던 중 좋은 타이밍이라 생각하여 도입했습니다. 내가 QueryDSL을 도입한 이유와 타이밍에 대해서 간략하게 정리하여 경험을 공유하고 합니다. QueryDSL은 프로젝트 초기에 바로 도입하여 사용하는걸 권장하지만 현재 회사의 프로젝트를 시작하면서 최소한의 툴을 사용하면서 정말 필요할때 도입하고자 목표를 잡았었습니다. 본론으로 들어가기 전에 QueryDSL에 대해 간략하게 소개하고자 합니다. QueryDSL이란? QueryDSL은 Query 빌더로 조금 더 정확하게는 Jpa의 JPQL을 만들어주는 빌더입니다. 보통 Jpa Repository에서 자동으로 만들어주는 매핑 메소드를 생성하기 어렵거나 복잡한 상황에서 쿼리를 작성하고..