본문 바로가기

분류 전체보기264

Open API Spefication 활용하기 - 1편 ( Overview ) 안녕하세요. 오늘부는 Open API Specification에 대해서 알아보고 Client와 Server의 API를 일치시키는 자동화 과정에 대해서 알아보도록 하겠습니다. 이번 시간에는 기본적으로 OPen API Spescification이란 무엇이며 어떻게 구성되어있으며 어떻게 사용할 수 있을지에 대해서 알아보며, 이후 시간에는 yaml 파일을 분석해보도록 하겠습니다. 그리고 나서 실습으로 OpenAPI Specification Tool을 이용하여 클라이언트 소스를 생성해보기도 하고 서버코드를 기반으로 OpenAPI Specification을 작성해보도기도 하겠습니다. OpenAPI Specification 이란 OpenAPI Specification은 HTTP API의 인터페이스를 정의하는 문서입니.. 2022. 9. 2.
Event Sourcing 맛보기 - 이론편 안녕하세요 오늘은 이전 시간에 CQRS에 대해서 알아보는 시간에 이어서 Event Sourcing에 대해서 알아보는 시간을 가져보도록 하겠습니다.Event Sourcing 이란 ?이벤트 소싱이란 application의 모든 상태를 일으키는 이벤트를 순서에 맞게 저장하여 status를 만들어내는 방법입니다. 먼저 말씀 드리면 사실 일반적인 경우에 필요하진 않습니다. 아니, 대부분의 경우에는 이렇게 구현할 필요하가 없습니다. 하지만 필요한 경우가 있고 장점도 충분히 가지고 있습니다. 설계할 때 몰라서 고려하지 않는 것 보다는 알아두면 좋은 설계 테크닉 정도로 생각하시면 좋을것 같습니다.먼저 일반적으로 어플리케이션에서 데이터 모델을 저장하는 방법은 현재 상태를 저장하는 방법을 이용합니다. 여기에는 NoSQL,.. 2022. 8. 22.
[ScyllaDB] ScyllaDB를 사용하기에 앞서 기본 이론에 대해서 맛보기 - NoSQL과 ScyllaDB 안녕하세요 ! 1달 정도 회사일에 집중하느라 블로그를 소홀히했습니다. 다시 조금씩 차분하게 글을 써보려고합니다. 최근에 NoSQL에 대해서 공부를 하고 있습니다. 그 중에서도 여러분들과 공유할 포스팅은 ScyllaDB의 기본에 대해서 알아보는 시간을 한번 가져보도록 하겠습니다. 오늘 포스팅하는 내용은 대부분 Scylla University의 강의를 요약입니다. Scylla DB에 관심있으신 분들은 위 링크의 내용을 참고하시 더 좋고 많은 내용을 확인하실 수 있습니다. NoSQL ScyllaDB는 NoSQL의 한 종류입니다. 따라서 ScyllaDB를 알아보기전에 NoSQL에 대해서 간단히 먼저 알아보도록 하겠습니다. NoSQL이란 주로 Not Only SQL의 약자라고 표현하고 있습니다. NoSQL 책에 .. 2022. 8. 10.
[기타] 가독성(readable) 좋은 코드와 인지 부하(recognite load)에 대한 고찰 안녕하세요. 오늘은 가독성 좋은 코드란 어떤 코드인가에 대해 우연히 책을 읽다 공감가는 글을 발견 하였고 스스로의 생각을 정리해보면 좋겠다라는 생각을 가지게 되었습니다. 오늘은 제가 생각하는 가독성 좋은 코드는 어떤 코드인가에 대해서 한번 포스팅하려고 합니다. 코드 작성과 가독성 좋은 코드 코드를 작성할 때 가독성(readability)을 신경쓰면서 작성하는 것은 당연한 이야기 입니다. 가독성 좋은 코드란 그 코드를 읽었을 때 이해하기 쉬운 코드를 뜻합니다. 가독성 좋은 코드를 위한 팁과 내용들은 대표적으로 클린코드라는 책이 있고 또한 조금만 검색해도 가독성을 높이기 위한 많은 자료들이 나옵니다. 실제로 프로젝트를 진행하다보면 새롭게 처음부터 작성하는 경우도 있지만 대부분의 경우 기존의 코드를 수정하거나.. 2022. 6. 28.
CQRS(Command and Query Responsibility Segregation) 맛보기 - 실습편 안녕하세요. 이전 포스팅에서 우리는 CQRS는 어떤것이고 어떤 장점과 단점을 가지고 있는지 함께 보는 시간을 가져보았습니다. 오늘은 CQRS를 한번 실습해보는 시간을 가져보도록 하겠습니다.이전 시간에 CQRS를 설명할 때 두가지 모델뿐만 아니라 CQRS를 지속적으로 이어주기 위한 사이드적인 매커니즘들이 필요하다고 말씀드렸었습니다. 그러한 부분을 함께 보도록 하겠습니다.1편 : CQRS(Command and Query Responsibility Segregation) 맛보기 - 이론편환경오늘 포스팅에서 사용할 환경은 아래와 같습니다. write DB의 DataSource는 MongoDB를 이용합니다. 그리고 Read 모델의 Repository는 Redis 라고 명시해 두었지만 실습이기 때문에 빠른 구현을 .. 2022. 6. 25.
CQRS(Command and Query Responsibility Segregation) 맛보기 - 이론편 안녕하세요. 오늘은 CQRS 패턴이란 무엇이고 어떻게 구현하며 이 패턴으로 시스템을 개발하였을 때 어떠한 장점과 단점을 가지는지에 대해서 알아보는 시간을 가져보도록 하겠습니다.DDD와 CQRSCQRS란 무엇인가에 대해서 이야기 하기전에 앞서서 우리는 먼저 DDD에 대해서 이야기를 할 필요가 있습니다.간단히게 DDD에 대해서 설명하고 넘어가도록 하겠습니다. DDD는 Domain Driven Design의 약자로 어플리케이션을 비즈니스 Domain별로 나누어 설계 및 개발을 진행하는 개발 방법론입니다. 여기서 Domain은 비즈니스를 말합니다. 그리고 DDD에서는 비즈니스 중심으로 개발하면서 비즈니스에 매핑되는 도메인 모델을 가지게 되는데 이는 비즈니스 자체를 추상화한 설계도로써 도메인 서비스의 중심으로 동.. 2022. 6. 16.
[kotlin] 코틀린 차곡차곡 - 17. require와 check 안녕하세요. 오늘은 오랫만에 코틀린 차곡차곡 시리즈로 찾아왔습니다. 오늘 여러분들께 공유 드릴 내용은 코틀린에서 validation에 대해서 이미 정해져 있는 코드들에 대한 내용입니다. 기존의 validation asis 메서드를 원하는 바로 정확하게 실행시키기 위해서는 실제 본연의 메서드 로직을 실행시키기전에 validation으로 input으로 들어오는 파라미터의 값이나 사용하는 상태 적절한지에 대한 판단이 필요합니다. 이러한 validation은 보통 아래의 2가지로 나눌 수 있습니다. 파라미터 값 자체에 대한 validation 파라미터 값에 의한 기존 Entity를 비롯한 도메인이 가지고 있는 상태에 대한 validation 이러한 valitaion을 구현한다고 하면 기존에는 아래의 코드처럼 일.. 2022. 6. 5.
[kotlin] 레거시(legacy) 코드 리팩토링하기 3편 - 리팩토링 진행하기 1편 : 레거시(legacy) 코드 리팩토링하기 1편 - 테스트 코드를 작성해야하는 이유 2편 : 레거시(legacy) 코드 리팩토링하기 2편 - 리팩토링 진행하기 안녕하세요. 레거시를 리팩토링하는 3번째 시간입니다. 오늘은 이전 포스팅에서 만들어둔 라인커버리지 100%의 테스트코드에 대한 신뢰를 바탕으로 코드가 좋은 가독성을 가지는 방향으로 리펙토링을 실제로 진행해보고자 합니다. 환경 환경은 이전 시간과 마찬가지로 아래와 같습니다. 기본적인 테스트 프레임워크는 JUnit5를 사용하며 mockking을 위해서 Unit 테스트 라이브러리인 mockk를 추가로 사용합니다. // JUnit5 testImplementation("org.springframework.boot:spring-boot-starter-t.. 2022. 5. 16.
[intellij] http를 통해서 E2E(local, server) 테스트를 진행해봅시다 안녕하세요. 많은 분들이 postman을 이용하여 local 테스트를 진행하는 것으로 알고 있습니다. 그런데 사실 intellij 내부에서도 local 테스트를 지원한다는 사실을 알고 있으셨나요? http 파일을 이용하면 intellij에서 local 테스트와 같은 E2E 테스트를 진행할 수 있는데요. 이는 개발이 정상적으로 이루어졌는지 확인하는데 큰 도움이 됩니다. intellij에서 개발하고 intellij에서 테스트 할 수 있다는 것은 좀 더 편하게 개발을 할 수 있다는 뜻인데요. 오늘은 이렇게 개발을 좀 더 생산성 있게 진행하기 위해서 intellij에서 제공하는 http 파일을 이용하여 local 테스트를 진행해보도록 하겠습니다.http 파일 생성가장 먼저 http 파일을 생성해 보도록 하겠습니.. 2022. 5. 5.
[kotlin] 레거시(legacy) 코드 리팩토링하기 2편 - 라인커버리지 100% 달성하기 안녕하세요. 오늘은 [kotlin] 레거시(legacy) 코드 리팩토링하기 1편에 이어서 테스트를 통해 실제로 라인커버리지를 100% 달성해보는 포스팅을 진행해보고자 합니다. 이전 편은 테스트 코드를 작성해야 하는 이유에 대해서 설명했습니다. 관심있으신 분들은 한번 보시는것을 추천드립니다. 환경 이번 포스팅과 다음 포스팅에 진행되는 test 환경에는 JUnit5와 코틀린 mock에 주로 사용하는 mockk 라이브러리를 이용하였습니다. build.gradle.kts의 implementation는 아래와 같이 선언하였습니다. // JUnit5 testImplementation("org.springframework.boot:spring-boot-starter-test") { exclude(group = "or.. 2022. 4. 23.
[React] Backend 개발자가 admin을 만들기 위해 하는 react 정리 1편 - component와 props, 그리고 props.children 안녕하세요. 오늘은 React로 admin 개발을 하면서 공부했던 React를 사용하기 위해서 배웠던 내용을 정리하려고 합니다. 같은 방법에 대해서 고민하셨던 부분이 있으셨다면 이 포스팅으로 해결하셨으면 좋겠습니다. 아마 아주 기초적인 부분들이 주를 이룰것으로 보이기때문에.. 적절히 걸러서 보시는게 좋을 수 있습니다. :)오늘 정리할 내용은 react에서 component들 사이에 데이터 전달의 기본이 되는 props와 event에 대해서입니다.component(컴포넌트)와 데이터 전달React에서 Component는 UI를 이루는 HTML을 반환하는 작은 단위입니다. Component는 한번 만들면 원하는 곳에서 재사용하는 것이 가능합니다. Java에서의 class 또는 메서드라고 생각하시면됩니다. c.. 2022. 4. 22.
[kotlin] 레거시(legacy) 코드 리팩토링하기 1편 - 테스트 코드를 작성해야하는 이유 안녕하세요. 서비스의 시간이 오래되면 레거시 코드에 대해 고민이 생기기 마련입니다. 특히 이제는 퇴사한 사람이 남기고간 장황하고 이유를 알 수 없는 코드에 수정이 필요하게 되면 덜컥 겁이나기 시작합니다. 그런 코드들은 생성된 시간이 오래되면 오래될수록 공포감도 커지고 건들고 싶지 않아집니다. 하지만 그렇다고 수정을 안할수도 없습니다. 무작정 수정하게되면 실수 등에 의해서 잘 되던게 오히려 잘못 동작할수도 있습니다. 때문에 우리는 수정하기에 앞서 어느정도 안전장치를 만들어둘 필요가 있습니다. 그것이 바로 테스트 코드를 작성하는 것입니다. 오늘은 레거시 코드에 테스트 코드를 작성하고 커버리지를 올리는 방법에 대해서 알아보는 시간을 가져보도록 하겠습니다. 레거시 코드에 유닛 테스트 코드를 추가하면서 얻을 수 .. 2022. 4. 16.

티스토리툴바