집짓기 대신 개발

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)들이 있습니다. 이런 용어의 혼동은 스크럼을 초기에 도입하는데 큰 방해요소중 하나입니다. 이는 "아니, 버그면 버그, 기능이면 기능이라 쓰면되지 에픽은 뭐고 스토리는 뭐다냐?" 라는 의문점이 가장 먼저 들게 하는 요소입니다. 물론 저도 처음..