집짓기 대신 개발

Unit Test를 진행하다 보면 다양한 문제에 봉착하게 되는데 가장 해결하기 힘든 문제 중 하나가 외부 DB와의 연결이 아닌가 싶습니다. 우리는 CI를 통해 배포를 수행하며 자동 테스트를 하는데 외부 DB와 연결하는데 애로사항이 생기기 마련이기 때문입니다. 개발 DB나 운영 DB나 마찬가지로 우리는 보안상 문제로 외부에서 접속을 못하도록 내부망에서만 접속이 가능하게 설정합니다. 이때 문제는 빌드를 수행할 환경이 내부망에 없다면 우리는 자동 테스트 과정에서 DB접속 문제를 해결해야 합니다. 이때 우리는 Mocking을 이용해 Repository를 새로 주입하는 등 여러 대안을 사용하지만 Entity가 많아 지고 데이터가 쌓이다 보면 극악의 생산성을 보여주기 시작합니다. 그래서 이런 문제를 해결하기 위해 ..

Spring boot를 쓰면서 API Document를 팀내에 전파할 방법을 고민중에 Asciidoctor를 이용한 방법이 있어 도입하게 됐습니다. 간단한 도입 방법과 사용법을 정리해보려 합니다. 스웨거를 사용할 수 도 있지만 스웨거의 경우 어노테이션으로 코드 전체를 오염시켜야하는 치명적인 단점이 존재하여 선택하지 않았습니다. Rest API Doc은 MvcTest를 이용하여 작성하기 때문에 기존 코드를 오염시키지도 않고 테스트를 강제하여 정확한 결과를 표현할 수 있다는 장점도 있습니다. 하지만 기본적인 문서작업과 정리해줄 문서 포맷을 작성해야하는 점이 있어 완벽한 자동화라고 말하기에는 부족하지 않나라는 생각도 들었습니다. (아직 사용이 미숙하여 그렇게 느낄 수도 있습니다!) apply plugin: "..

악마는 디테일에 있다는 말은 협상 격언등에서 사용되는 용어로 본래 뜻은 문제점이나 불가사의한 요소가 세부사항 속에 숨어있다는 의미의 속담입니다. 저는 이 말을 매우 좋아합니다. 우리는 개발할 때 모든 설계 구조에 대한 이유를 설명할 수 있도록 노력해야합니다. 끊임없이 고민하고 본질에 대해 파악할 수 있도록 노력해야 성장할 수 있다는 것을 많이 느끼는 것 같습니다. 길지 않은 개발 경력의 초반 프리랜서 활동을 하면서 다양한 외주를 받고 나름 일이라는 걸 하면서 스스로 꽤 잘하는 개발자다라고 착각했던 적이 있습니다. 당시에 클라이언트가 말하는 대부분의 기능을 구현하는데 문제가 없었고 그 과정에서 스스로 우물로 들어가지 않았나 생각을 많이합니다. 물론 그 기간 동안 엄청 열심히 개발을 하긴 했습니다. (fea..

1편에 이어 React에서 MVVM패턴을 사용하는 방법을 이어 진행하겠습니다. 1편 마지막에 Service 단에 Counter를 직접 들고 있는 형태의 구조가 나왔는데 실제로는 Repository를 이용해 모델 데이터를 관리하게 됩니다. 모델 데이터의 저장과 불러오기를 Repository를 통해 사용하며 Repository는 실제 API를 통해 데이터를 가져오는데도 역할을 하게 됩니다. 하지만 많은 실제 API를 통해 받아오는 데이터는 불규칙하며 페이지 별로 상이하기 때문에 DTO에 맞춘 여러 변형 객체를 여러개 소장하고 있어야 합니다. (GraphQL을 활용한다면 완전한 Repository를 구성할 수 있지 않을까라는 생각도 되네요) 1. Repository import Counter from "./c..

항상 개발 중심 조직에서 일을 하다가 완전 비개발 직군과 함께 스프린트를 꾸리면서 JIRA사용에 여러 애로사항을 겪었습니다. 그래서 이 기회에 명확한 JIRA 사용법 및 워크플로우 용어들을 정리하게 되었습니다. 모든 툴이 그렇지만 각 팀의 사정과 환경에 맞게 수정해 사용해야 한다는 점을 유의해야 합니다. 그럼 제가 우리팀에서 만든 JIRA라 쓰고 스크럼이라 읽는 사용법 정리를 시작하겠습니다. 스크럼에는 에픽 - 스토리 - 작업 - 버그 등 다양한 용어의 이슈(Task)들이 있습니다. 이런 용어의 혼동은 스크럼을 초기에 도입하는데 큰 방해요소중 하나입니다. 이는 "아니, 버그면 버그, 기능이면 기능이라 쓰면되지 에픽은 뭐고 스토리는 뭐다냐?" 라는 의문점이 가장 먼저 들게 하는 요소입니다. 물론 저도 처음..

팀을 초기에 세팅할때 유닛 테스트 관련 컨벤션을 꾸리는데 여러 고민에 빠지게 됩니다.. 유닛테스트의 범위와 규모 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에서 자동으로 만들어주는 매핑 메소드를 생성하기 어렵거나 복잡한 상황에서 쿼리를 작성하고..