이슈 선정https://github.com/spring-projects/spring-boot/issues/45306 Support CLI-option for "environment" in Buildpacks configuration · Issue #45306 · spring-projects/spring-bootContext The Spring Boot plugins for Gradle and Maven allows configuring the Buildpacks task via properties in the build.gradle or pom.xml files. Some of the properties can be specified via convenie...github.com이 이슈의 내용은 Grad..

문제 상황나는 DTO(Data Transfer Object)를 활용하여 레이어 간의 데이터를 옮기고 있었다. 도메인 객체 자체를 그대로 나르게 된다면 필요 없는 정보나 숨기고 싶은 정보까지 과도하게 노출될 수 있다. 그래서 DTO에 딱 원하는 정보만 담아서 옮기는 방식을 택했다. 데이터의 흐름은 보통 이렇다. 클라이언트의 요청 -> Request -> 컨트롤러 -> (Request를 DTO로 변환) -> 서비스 -> (DTO를 바탕으로 객체 저장/조회 등 수행) 여기서 '변환하는 작업'을 어디서, 어떻게 할지에 대한 고민이 시작되었다.1. DTO 자체에 변환 로직 넣기?DTO 안에 toEntity()나 from() 같은 메서드를 만드는 방식이다. 많이들 쓰지만 나는 이게 썩 맘에 들지 않았다. DTO는 ..

문제인식첫 궁금증은 쏙쏙 들어오는 함수형 코딩이라는 책을 읽으면서 시작되었다.Copy on Write라는 기법은 어플리케이션 레벨에서 불변성을 지키기 위해 객체를 복사하고 수정을 하는 것이라 알고 있었지만 깊은복사인줄 알았던 방법이 얕은 복사를 사용하여 적용을 한다는 것이었다!우테코 프리코스를 참가할때 불변성이라는 키워드를 지키기 위해서 VO(Value Object)를 사용하고 값이 변경될때마다 new 키워드로 새 객체를 생성해주던 나는 잘 이해가 안가서 Copy on Write를 좀더 탐구해보기로 하였다. 불변성을 지키기 위한 Copy on Write먼저 자바 코드로 예를 들어보자.public class MutableExample { public static void main(String[] a..

프리코스에서 서비스 개발로 확장하기까지프리코스 1~3주차는 TDD를 체득하기 위해 고민하고 반복했던 시간이었다. 값 객체(Value Object), 일급 컬렉션, 검증 책임 분리, 안전한 리팩터링 구조 등을 익히며 테스트가 코드 품질에 어떤 영향을 주는지 확인할 수 있었다.그 과정에서 자연스럽게 더 큰 규모의 프로젝트에 이를 적용해보고 싶다는 생각이 들었다. 그래서 4~5주차 미션을 받자마자 평소에 구상해두었던 ‘라멘 맛집 탐색 서비스 — 라오타’를 선택했다. 라멘 인증샷이 여러 플랫폼에 흩어져 있다는 문제에서 출발한 이 프로젝트는 회원, 가게, 메뉴, 인증샷, 찜, 방문 기록 등 실질적인 상호작용이 존재하고 기능 확장 가능성도 충분했다. 1~3주차에서 익힌 객체 중심 설계와 TDD를 실전에서 검증하기에..

3주차 회고 — 바쁨 속에서도 얻어간 성장의 흔적3주차는 유난히 빠르게 지나갔다. 일정은 빡빡했고 집중 시간이 부족했지만, 돌아보면 여러 도전과 선택을 통해 확실히 성장한 한 주였다. 특히 기술적인 부분뿐 아니라, 학습 태도와 협업 방식 같은 소프트 스킬의 중요성을 뚜렷하게 체감할 수 있었다.리뷰를 통해 깨달은 관점의 다양성2주차 미션의 결과물을 꽤 만족스럽게 생각하고 있었지만, 코드 리뷰가 시작되자 예상보다 많은 피드백이 들어왔다. 내가 보지 못한 허점들이 드러났고, 스스로에 대한 평가가 과연 정확했는지 되돌아보게 됐다.하지만 곧 관점을 바꾸게 됐다. 피드백은 ‘틀렸다’가 아니라 ‘다른 시각’이었다. 그래서 리뷰를 받을 때마다 내 의도와 리뷰어의 논리를 비교하고, 그 사이의 간극을 기록하며 이해하려고 ..

1주 차를 돌아보며1주 차에는 TDD를 이해하고, ‘작게 쪼개며 점진적으로 나아가는 리듬’을 몸에 익히는 데 집중했다. 문제를 세분화하고 하나씩 해결해 나가는 흐름이 내 경험과 잘 맞았고, 덕분에 TDD를 더 깊이 탐구하고 싶다는 생각이 들었다.켄트 벡의 『테스트 주도 개발』을 읽으면서 한 가지를 강하게 느꼈다. TDD는 처음부터 아키텍처를 완성해놓고 시작하는 방식이 아니라,“작동하게 만들고 → 테스트로 안정화하고 → 리팩터링으로 구조를 다듬는”흐름으로 성장하는 개발 방식이라는 점이다. 반면 나는 1주 차에 UML을 먼저 그리고 객체 관계를 설정한 뒤 테스트를 작성하는 방식을 습관처럼 사용했다. 돌이켜보면, 그건 반쪽짜리 TDD였다. 그래서 이번 2주 차에는 마음을 완전히 고쳐먹었다. 설계를 미루고, 백..