지난 1년 반동안 회사에서 레거시 시스템을 조금씩 개선하고 있다. 비즈니스 로직이 담긴 쿼리, 랜덤한 알파벳처럼 보이는 수십개의 컬럼으로 구성된 테이블들, 어디서부터 건드려야 고칠 수 있는지 한참을 들여다봐야 수정할 수 있는 복잡한 코드들.. 내가 이해한게 맞나 싶어서 팀원들에게 확인해야하기도 하고, 코드 수정에 늘 확신이 없었다. 고치고싶은 포인트들을 쉽게 건드릴 수 없는 이유들 중 하나는 ‘의존’ 문제였다. B를 수정하고 싶은데 A,C,D.. 여러군데에서 B를 사용하고 있으면 B를 수정하는 건 쉽지 않은 일이 된다. 아키텍처를 개선하는 과정에서 이 의존의 문제를 분석하는 데에 도움이 되었던 도구와 팀이 공유하는 규칙으로 만들기 위해 사용했던 도구들에 대해 간략히 정리해두려고 한다. (일부 이렇게 개선했지만, 여전히 진행중) ...
켄트 벡 의 ‘테스트 주도 개발’ 책 예제를 팀 스터디로 같이 페어프로그래밍을 하다가 1부까지만 하고 다른 책으로 넘어가게 되었다. 예전에 읽을 때도 이 책의 2부는 건너뛰고 해보지 않아서 궁금함을 안고 예제를 구현해보니 괜찮아서 영업하러 짧게 쓴다. ㅋㅋ 내가 예전에 2부를 건너뛰었던 이유 켄트 벡은 2부를 시작하며 이렇게 이야기하는데: 2부를 끝내고 나면 파이썬에 대해 개론적으로 이해하고, 자신만의 테스팅 프레임워크를 작성할 수 있게 될 것이며, 좀더 교묘한 TDD의 예를 알게 될 것이다. 그야말로 일석삼조다 ...
최근 팀원이 짜놓은 코드를 의도와 다르게 해석할뻔한 경험이 있었다. ‘이게 왜 되지’하며 바로 이해되지 않았었는데, 차근차근 다시 찾아보며 글을 남겨본다. 팀원의 코드는 api 호출을 할 때 범용적으로 사용할 수 있도록 제네릭을 사용한 메서드였다. Mockito 라이브러리의 mock() 메서드와 동일한 트릭을 썼다고 설명을 해주셔서 살펴봤다. Mockito의 mock() 에서 타입 추론 (version: mockito-core 4.9 이상, spring-boot-starter-test에선 3.1부터 포함됨) mock() 메서드는 어떻게 타입 추론을 하는걸까? 지금껏 테스트코드를 짤 때 무심코 잘 쓰기만 하고 왜 되는지는 몰랐다. 아래 코드를 보자. ...
intro spring을 늘 쓰지만 자주 접하지 않는 상황에선 설정이 헷갈릴 때가 있다. 얼마 전 한 프로젝트의 bean 설정을 확인하다가 아래 코드와 같이 List타입과 List 내부에 있는 객체 타입 (편의상 List<T> 타입과 T 타입 이라고 하겠다) 의 설정이 둘 다 있는 경우를 마주했다. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 @Bean List<Cake> availableCakes() { return List.of( lemonCake(), chocolateCake(), strawberryCake() ); } @Bean Cake chocolateCake() { return new Cake("초코"); } @Bean Cake strawberryCake() { return new Cake("딸기"); } @Bean Cake lemonCake() { return new Cake("레몬"); } List<Cake> 을 주입받아 사용하는 코드: ...
intro 지난 글 specification pattern (1) 개념과 구현 에 이어서 구체적인 여러 예시들을 통해 어떤 상황에서 이 패턴을 활용하기 좋은지 살펴보려고 한다. 그리고 패턴을 코드에 적용해보려고 할 때의 여러가지 구현방법들에 대해서도 소개할 예정이다. specification이 필요한 케이스들 1. 검증(validation) 객체가 어떤 요건을 충족시키거나 특정 목적으로 사용할 수 있는지 가늠하고자 객체를 검증할 때. 예시> 청구서 발송 application: 청구서가 체납되었을 경우 → 붉은색으로 표시한다 예약 application: 상품이 제한 수량을 초과 or 현재시각이 오후2시 이전일 때 → 예약하기 버튼을 disable한다 2. 선택 (selection) 특정한 조건을 만족하는 컬렉션 내의 객체를 선택할 때. ...
단순하게, 명시적으로 도메인 규칙을 표현하자
Json schema란? JSON Schema is a declarative language that allows you to annotate and validate JSON documents. (annotate: 주석을 달다 / validate: 검증하다) ⇒ 말그대로 JSON에 대한 스키마이며, 항목들을 설명하고 검증하는데에 사용된다. 데이터를 보내는 쪽에서는 데이터에 대한 설명, 타입에 대한 정의 등을 할 수 있고, 받는 쪽에서는 스키마를 통해 데이터를 검증해서 사용 가능하다. 쉽게 표현하면, json으로 데이터를 주고받을 때의 여러 고충(?)들을 줄이기 위해 만든 명세 라고 할 수 있을것 같다. 예를 들어 api, 메시지 큐 등으로부터 json으로 전달받은 데이터가 { id: “34”, … } 다. 이걸 어떻게 바라봐야할까? 늘 문자열인가? 혹시 잘못 보낸건 아닐까? 파싱을 String으로 받도록 했는데 어느날 Integer로 오면 어떻게 처리를 해야할까? 이런 문제들을 해결하고자 명확하게 스키마를 통해 데이터에 대한 구조를 명시적으로 약속하여 데이터의 품질을 보장할 수 있다. 이 ‘스키마를 어떻게 정의할 것인가’에 대해서 표준 명세가 있기 때문에, 표준에 따라 읽어들이고 보내는 부분을 자동화할 수 있다. 그럼 어떻게 생겼는지 살펴보자. ...
미래의 나에게 도움될까 하여 기록하는 채용하며 생각한 것들
얼마전 1년 조금 넘게 다닌 회사를 그만두겠다는 결정을 했다. 처음으로 ‘어떤 문제를 푸는지’를 보고 입사하게된 회사였다. 다녔던 어떤 회사들보다 더 회사가 풀어내고자 하는 문제에 공감했고, 가치있는 일을 했다고 생각한다. 함께 일한 팀원들도 최고였다. 이 생각은 퇴사를 하는 지금 순간에도 변함없다. 그럼에도 이런저런 요인들에 의해 회사와 나는 다른 길을 가야하는 상황이 왔다고 판단했다. 회사에서 무슨 일을 했는지나 퇴사를 왜 하게되었는지 등의 총체적인 회고보다는 그간 나에게 중요했고 경험적으로 체득한 lesson learned를 생각나는대로 정리해보려고 한다. ...
proxyman소개, 기능 사용방법 등