Back to the Basics

이전 포스팅 [TEST] 테스트 원칙에 대하여 - 소프트웨어 테스트의 7원칙과 FIRST원칙  에서는 효과적인 테스트 코드 작성을 위해 참고할만한 원칙들을 알아보았다.  이 두 가지 원칙을 요약해 보았다.1. 테스트의 가장 큰 목적은 문제점을 찾는 것이다. 이를 위해 문제가 될 수 있는 다양한 케이스에 대해 수행되어야 한다.2. 모든 것을 테스트하는 것은 불가능하므로 중요한 부분(비즈니스!)에 집중되어야 한다. 3. 테스트는 구현이 아닌 명확한 결과로 성공 여부를 판단할 수 있어야 한다(True or False)4. 테스트는 빠르고 독립적이며, 실행할 때마다 동일한 결과는 제공해야 한다5. 테스트코드는 코드작성과 동시에 또는 그전에 설계되는 것이 이상적이다이번 포스팅에서는 이런 원칙들을 기반으로 테스트코..

이전 회사에서도 테스트 코드 작성에 대한 명확한 지침이 없었다. 그래서 주로 기존에 작성된 테스트 코드들을 참고하며 비슷한 방식으로 작성했다.테스트 코드를 작성하면서 종종 '이 테스트가 과연 의미가 있을까?' 하는 의구심이 들기도 했다. 특히 새로운 기능을 추가하거나 리팩토링을 할 때마다 테스트 코드를 상당 부분 수정해야 하는 경우도 많았다. 이런 비효율로 인해 업무가 많을 때는 테스트 코드 작성을 미루거나 건너뛰기도 했다. 이런 패턴이 반복되다 보니 '내가 테스트를 제대로 작성하고 있는 걸까?' 하는 의구심이 들었다.물론 테스트 코드의 가치는 충분히 이해하고 있다. 기능을 변경했을 때 버그 여부를 빠르게 확인할 수 있고, 테스트를 통해 비즈니스 로직을 더 잘 이해할 수 있다. 개발 과정에서 버그를 조..

자체 서비스에서 주소 검색 서버를 개발하는 프로젝트를 진행했던 적이 있다. 주소 데이터베이스 구축부터 검색 서버까지 개발하는 프로젝트였다. 서드 파티를 사용하면 되지, 왜 자체 주소 검색 서비스를 만드는가에 대한 의문도 있겠지만 이는 도메인 특성상 주소나 영역에 대해서 서드파티로는 한계가 있던 부분이 많았기 때문이었다.이때 사용했던 postgresql의 full text search에 대해 조사했던 것을 다시 정리해 보았다. (나중에는 postgresql > elasticsearch로 개발하였다.)내용이 조금 많기에 순차적으로 포스팅할 예정이다. 이번 포스팅에서는 Full text search에 사용되는 기본 개념을 소개하고 다음 포스팅에서는 정확한 주소 검색을 위해 고민했던 방법에 대해서 정리해 보려고..

개요Spring이나 NestJS 같은 프레임워크에서는 클래스들 간의 종속성을 IoC 컨테이너에 의해 주입받는다. (IoC 컨테이너와 종속성 주입에 대한 개념은 아래에서 간단히 설명) 이를 통해 클래스들이 필요한 기능을 직접 생성하지 않고 외부에서 주입받음으로써 객체 간 결합도를 낮출 수 있다.그럼 이런 기능은 어떻게 구현이 될까? Java Spring이나 NestJs모두 런타임에 메타데이터를 활용하여 객체의 생성과 종속성 관리를 수행한다. Nestjs는 reflect-metadata 라는 라이브러리를 사용하고 Spring은 Java의 리플랙션 API를 사용한다. (이것이 무엇인지는 아래 간략하게 정리하였다)메타데이터를 어떻게 활용하는지 확인하고 IoC DI에 대해 조금 더 깊이 있는 이해를 위해 직접 구..

가볍게 내가 개발자가 된 계기를 적어 보자면..기계공학과 전공으로 공대를 졸업하고 전공에 맞게 항공기를 설계 및 개발하는 엔지니어로 경력을 시작했다. 그러다 어떤 계기로 (길어서 생략) 개발 공부를 하게 되었고 "나의 길은 이거다!"싶은 순간이 와서 아예 퇴사를 해 버리고 개발 공부를 시작, 운 좋게 꽤 인지도 있는 회사의 백엔드 개발자로 일하게 되었다. 이곳이 개발자로서 경력을 시작하게 된 첫 회사였다.첫 회사에 들어와서 어느 것을 먼저 해야 하는지 우왕좌왕했던 기억이 있다. 비전공자로 들어온 나로서는 사실 모르는게 많았다. 회의에 들어가면 이런저런 용어들이 마구마구 나오는데 이게 무슨 말인지, 이런 것까지 질문을 해도 될지, 회의 중간중간 기초적인 부분까지 물어봐도 되는 것인지 등등 많은 고민을 하며..

서론 .. 주저리주저리이번에 진행하는 프로젝트에서 full text search를 하기위해 Elastic Search를 적용하게 되었다.(여담이지만 개발공부를 할 때에는 MySQL, 회사에 들어와서는 PostgreSQL등 관계형 DB들만 사용해봤는데 No SQL을 직접 사용해 볼 기회가 와서 좋다)full text search를 해야하는 이유는 바로 통합검색을 하기 위함이었다.기존에 사용하던 방식은 postgreSQL 에서 통합검색을 하는 방식이었는데 자유분방한 사용자 입력에 대해 부분검색을 구현하는데 한계가 있어 결국 elasticSearch를 사용하기로 하였다.참고로 full text search란 DB 내에서 특정 키워드나 문서와 일치하는 텍스트를 찾는 검색 방법이다. 일반 검색과 다른점은 일반 검..

Page 는 데이터베이스에서 데이터를 읽어오는 하나의 단위이다. SELECT query를 할 때 내가 원하는 행만 disk에서 가져오는 것이 아니라 page라는 단위로 disk에서 캐싱을 한다. 지금까지는 Database를 단순히 사용하기만 했었다. 하지만 느린 쿼리는 결국 문제를 발생시켰고 쿼리 최적화에 대해 고민을 하다보니 Index의 원리에 대해 알아야 했다. 그러다보니 Database에서 파일을 저장하고 관리하는 방법에 대해 알아야 하는 필요성이 생겼다. 그래서 이번 블로그에는 데이터베이스 페이지의 개념, 디스크에 읽기 및 쓰기 방법, 디스크에 저장되는 방법, Postgres에서 페이지 레이아웃에 대하여 정리해보았다. [목차] Page란? Database에서 읽고 쓰기 과정 Page에 들어가는 ..

일요일 오후 저녁 피크 타임에 우리 팀이 관리하고 있던 서버가 죽어버리는 이슈가 있었다. 소 잃고 외양간 고치는 격으로 rate limit을 뒤늦게 구축하게 되었다. 당시 발생했던 상황들과 rate limit을 구축하면서 공부했던 부분에 대해서 기록을 하기 위해 이번 포스팅의 주제로 Rate limit으로 산정하였다. 먼저 이번 포스팅에서 1.Rate limit이 필요한 이유를 경험담을 담아 이야기 해보고 다음 포스팀에서 "Rate limit의 여러 종류들(알고리즘)"에 대해 알아본다. 그리고 그다음 포스팀에서 1. rest api에서의 rate limit과 graphel에서의 rate limit의 차이점에 대해 정리해 보고 2. 직접 구현을 해본 것에 대해 정리해 보려고 한다. 몇 차례에 걸친 꾀나 시..