전체 글

이전 포스트에서 Flyway를 사용해 프로덕션 DB의 마이그레이션 버전 관리를 했던 경험을 기록했다. 로컬 환경에서 마이그레이션 버전 관리가 필요할까? 프로덕션 서버의 DB 관리 시 빛을 발할 Flyway이지만, 동작을 보장하기 위해 로컬 환경의 DB와 개발 서버의 DB에서도 똑같이 적용할 필요가 있다. 개발 서버의 DB에도 데이터는 들어가기 쉽다. 프로덕션 서버라고 생각하고 올바른 데이터의 CRUD만을 최대한 다루면 유효한 데이터만을 개발 DB에 담고 개발 DB의 버전 관리 또한 유의미하게 할 수 있다. 그렇다면 로컬 환경의 DB는 어떨까? 개발자들이 각자 개발하는 만큼 기능이나 스키마의 추가나 삭제, 변경 등이 각자의 컴퓨터에서 무분별하게 이루어질 것이다. 버전 관리가 유의미하진 않지만, Flyway..

웹 애플리케이션 프로젝트에서 DB 마이그레이션을 위해 사용했던 Flyway에 대해 정리해보겠다. Flyway Flyway는 오픈소스 DB 마이그레이션 툴이다. 핵심적으로 무엇을 도와주냐면, DB 스키마에 대한 변경을 추적하고 업데이트나 롤백을 쉽게 진행하도록 애플리케이션의 DB 스키마 버전 관리를 도와준다. 자바/스프링 프로젝트를 위한 툴이 아닌 다른 언어로 된 애플리케이션을 사용할 때도 쓸 수 있고, CLI나 API 등을 지원하기도 하고 데스크탑 애플리케이션도 존재한다. 왜 변경사항을 추적할까? 로컬 디바이스, 우리의 컴퓨터에서 개발을 할 때는 변경의 추적이 상관없을 수도 있다. 내가 개발해서 내가 사용한다면 그 안의 데이터를 내가 직접 관리하고, 그 관리가 중요하지 않을 수도 있지 않은가? 하지만 변..

다른 글에서 소개했던 것처럼, 스프링 부트의 application.yaml을 이용해 Properties를 관리하는 방법은 다양한 애너테이션을 이용한 여러가지 방법이 있다. 그 중에서 내가 생각하기에 가장 객체지향스러운 방법을 오늘 포스트에서 다뤄보려 한다. @ConfigurationProperties의 단점 @ConfigurationProperties는 YAML의 계층형을 따라서 자동으로 카멜 케이스의 필드와 매칭되는 설정 값을 찾아 매핑을 진행한다. 스프링 프레임워크가 아닌 스프링 부트에서 지원을 하는 애너테이션이니 주의가 필요하다. 문자열을 이용한 하드코딩이 아니기 때문에 @Value보단 더 선호되는 애너테이션이라고 생각이 드는데, setter 메서드가 반드시 필요하다는 것이 아쉽다. 불변으로 생성할..

DB의 정보라던지 JWT의 내용이라던지 소스코드 외부적으로 값을 세팅해 줄 필요가 있을 경우 /resources 디렉토리 아래 .properties 혹은 .yaml에서 값을 읽어올 수 있다. 스프링 부트는 기본적으로 DB를 사용할 일이 있으면 application.yaml에서 DB 연결을 위한 값을 자동으로 설정한다. 이처럼 프레임워크의 흐름에 필요한 값을 넣기 위해 사용하는 경우도 있고, 개발자가 자체적으로 값을 소스코드 외부적으로 받아오도록 할 때 이러한 Properties들을 설정할 수 있는 방법은 여러가지가 있다.왜 Properties가 필요한가?우선 소스코드 외부적으로 왜 값을 넣어줄 필요가 있을지 생각을 해보자. 웹 서비스를 만들 땐 DB의 정보가 필요하다. 만약 팀원이 여러명 있다면, 각자의..

지난 포스트에서 다루었 듯이 책임이란 "변경의 이유"이다. 하지만 단일 책임 원칙을 고려하면서 어떠한 애플리케이션을 구현하다 보면 책임에 대해 고민에 빠지게 된다. 변경의 이유는 절대적으로 정해져 있는 것이 아니기 때문이다. 책임 == 기능 ?단일 책임 원칙, 혹은 SRP에 대해서 리서치를 하면 다양한 예시들을 접할 수 있다. 하지만 많은 예시들의 클래스에선 하나의 메서드만을 가지고 단일 책임 원칙을 설명하는 경우가 많다. 객체가 한 가지의 기능 만을 가졌을 때 단일 책임 원칙을 논하기는 매우 쉽기 때문이다. 그래서 그러한 예시들과 단일 책임 원칙에 대한 설명을 보다 보면 이해가 되는 듯 싶다. 하지만 실제로 단일 책임 원칙을 고려하며 설계를 하거나 구현을 하게 되면 무언가 헷갈리게 된다. 홀로 공부하며..

소프트웨어를 처음 공부하기 시작하고 나서 가장 어려웠고 지금도 어려운 부분이 SOLID이다. SOLID를 공부해야겠다 생각하고 처음 접하게 되는 것이 SOLID의 S인 Single Responsibility Principle, 단일 책임 원칙이다. 이리 저리 구글링을 해보며 단일 책임 원칙에 대해 공부하고 이해했다 싶더라도, 막상 적용해보려니 어려움을 많이 느꼈다. 그렇게 시행착오를 겪으며 나만의 결론에 어느정도 도달하게 되었다. 물론 아직 부족하지만, 내 생각들을 정리하며 복습해보려 한다!🚀 책임이란 무엇일까?SOLID라는 다섯가지 원칙은 객체지향의 절대적인 원칙이 아니다. Clean Code의 저자인 로버트 마틴이 객체지향의 원칙으로서 권장하고 이제는 주류로 자리잡은 원칙이 SOLID이다. 로버트 ..

Java로 Web Application을 만들려면 꼭 필요한게 Maven, Gradle 같은 빌드 툴이다. IntelliJ나 Spring Initializr 같은 곳에서 Maven 혹은 Gradle 같은 빌드툴을 선택하기만 하면 알아서 세팅해준다 😃그래서 그것에 대한 감사함은 진정하게는 없었다 히히 😏빌드툴을 쓰는 이유는 귀찮은 빌드들을 다 해주기 때문인데, 빌드툴을 무의식적으로 쓰다가 갑자기 든 생각이 있다. 빌드는 얼마나 귀찮길래 이런게 생긴걸까? 간단하게나마 직접 빌드를 체험해보고 싶은 마음에 인터넷을 뒤져 해보게됐다.소스 코드USER@DESKTOP-R5TAR1M MINGW64 ~/Desktop/공부/Java/HelloWorld$ rmdir -p src/main/java/com/buildexc/..

Java의 본질에 대해 정리하고 복습할 겸 기록해보겠다. 어디까지나 학습 기록과 중간 중간 생긴 내 호기심에 대한 나의 하찮은 견해이다😥Java우선 Java는 잘 알려져 있다시피 썬 마이크로시스템즈 (Sun Microsystems) 라는 회사에서 제임스 고슬링(James Gosling)이라는 사람을 주축으로 만들어졌다.썬에 대해 잠깐 말해보자면, Stanford University Network의 약자다. 스탠포드 대학 동문들끼리 설립한 회사다. 지금은 오라클에 인수합병된지 햇수로만 14년이고, 썬이 주력하던 일들 중 오라클에 남아있는건 Java 말고는 거의 안 남아있는 것 같다. MySQL도 있지만 이도 썬이 인수했었던 것이니...썬의 주력사업은 주로 소프트웨어가 아닌 하드웨어 쪽이었다. SPARC라..