본문 바로가기

전체 글250

[Effective Kotlin] 아이템 32. 생성자 대신 팩토리 함수를 사용하라 자바를 공부하며 가장 의미 있게 읽은 책은 [이펙티브 자바]이다. 자바를 만든 개발자가 직접 집필한 책이므로, 자바를 자바답게 사용하는 방법이 아주 명확하게 설명되어 있다. 가장 첫 챕터인 '생성자 대신 팩토리 메소드를 사용하라'라는 아이템을 굉장히 의미 있게 읽게 되었고, 그 내용을 코드를 작성할 때 애용했었다. 코틀린도 자바의 이점을 그대로 가져간 언어이므로, 비슷하게 적용 되는 부분이 있을지를 생각해 봤다. 회사에 들어가서 코틀린을 배우고 코드를 작성하면서, 가장 눈에 띄었던 부분이 dto 객체를 매핑하는 부분이었고, 팩토리 메서드를 사용하면 어떨까라는 생각을 했다. 코틀린을 사용하는 분들과 구글링을 통해 자바와 동일하게 팩토리 메서드를 많이들 사용한다는 정보를 얻었고, 그대로 적용했었다. 이펙티브.. 2023. 1. 29.

[Effective kotlin] 아이템 27. 변화로부터 코드를 보호하려면 추상화를 사용하라 자바를 공부하며 객체지향을 제대로 공부하기 시작했고, 객체지향의 4대 특성 중 '추상화'의 참된 의미를 알기까지 시간이 걸렸다. 결론은 많이 공부하고 생각하며 확장하고 적용해 봐야 그 의미를 비로소 이해하리라 생각한다. 상수 const val NAME_PREFIX = "prefix" fun getName() : String = NAME_PREFIX + this.name 가장 간단한 추상화 방법이다. 본 코드에서 String 리터럴 값을 따로 빼서 상수화를 시키면 이해도 쉬울 뿐 아니라. 변경하기도 훨씬 수월하다. 리터럴 값에 의미 있는 이름을 붙일 수 있고, 변경이 쉽다. 함수 특정 행위를 함수로 선언하면, 재사용이 가능하다. 코틀린에서는 간단히 확장 함수를 만들어서 여러 곳에서 재사용할 수 있어, 추상.. 2023. 1. 29.

[Effective Kotlin] 아이템 24. 제네릭 타입과 variance 한정자를 활용하라 자바를 공부하고 적용하면서 추상화를 하기 위해 인터페이스를 적극 활용했었고, 강타입 언어였기에 특히 타입을 잘 활용했어야 했다. 그 과정에서 제네릭을 다시 한번 공부하게 되었고, 공변, 반공변 성 등의 특징을 제네릭이 어떻게 풀어냈는지 공부했다. extend, super 등의 한정자를 사용하여 타입을 적절히 제어했었던 기억이 있다. 코틀린도 마찬가지로 제네릭의 한정자를 제공한다. 자바의 결함을 개선하면서 말이지. Out 한정자 파라미터를 공변으로 만든다. class University open class Student class FreshMan : Student() fun main(args: Array) { val b: University = University() // OK val a: Universi.. 2023. 1. 27.

[Effective Kotlin] 아이템 23. 타입 파라미터의 섀도잉을 피하라 섀도잉이란 무엇인가? class Person(val name : String) { fun addPerson(name : String) { // ... } } addPerson() 함수의 파라미터가 Person class의 프로터티 이름과 같아진다. 외부 스코프의 프로퍼티를 가리게 되는 경우를 섀도잉이라 한다. 이를 개발자가 알아차리기 힘든 경우가 생긴다. 타입 파라미터에서도 문제가 생긴다. interface Payment class KakaoPay: Payment class NaverPay: Payment class PaymentHistory { fun addPayment(payment: T) { // ... } } 이러한 경우는 PaymentHistory의 제네릭 타입과 addPayment()의 타입 .. 2023. 1. 25.

[감상문] Kotlin In Action을 읽고 현재 입사한 회사에서 백엔드 언어는 코틀린 기반이다. 코틀린에 빠르게 적응해야 했기에, 입사 전 부터 틈틈히 개념을 공부했었다. 하지만 구글과 유튜브는 정보의 난잡함과 한계, 그리고 신뢰성이 떨어진다. 확실히 언어 및 백엔드 공부는 책이 진리라는 것이 내 정론이다..ㅎㅎ 입사 첫 날 사수 분께 코틀린 관련 서적이 있는지 여쭤봤고, 감사하게도 흔쾌히 [코틀린 인 액션] 책을 빌려주셨다. 책을 들고 퇴근했고, 그 날 밤부터 바로 읽기 시작했다. 일이 많은 날, 너무 피곤한 날과 일정이 있는 날을 제외한 밤 11시에는 1시간 꼭 독서를 하고 자자는 다짐과 함께. 잘 읽히지 않을 것을 염려했지만, 다행히 이 책이 지향하고자 하는 바는 기존 자바 개발자에게 초점이 맞춰져 있는 것이 참 인상 깊었다. 책은 기존 자.. 2023. 1. 17.

일주일 간 회사 적응기 회사에 입사해서 일주일 간 온보딩 과제를 수행했다. 빠르게 훑어 보았을 때 만만치 않은 요구사항과 기간 때문에 쉽지 않을 거라는 생각을 했다. 첫 날 맥 세팅부터 정신이 어질어질했고, 배포 때만 잠깐 써오던 CLI도 날 정신 없게 했다. 5일 동안 많은 회의에 참석하게 되었고, 이번 일주일 온보딩을 확실히 끝내놔야 다음주부터 비로소 내 할일을 확실하게 할 수 있겠다는 생각이 들었다. 무조건 끝내겠다는 다짐을 했다. 코틀린 스프링 부트 프로젝트를 생성하고 스프링 시큐리티 config 및 도메인 설계까지 거진 2, 3일 소모했다. 중간에 요구사항을 다시 보게 되어 수정에 수정을 거듭했다. 많이 안다고 생각했지만, 도메인 설계는 확실히 꾸준한 연습이 필요한 것 같다. 본격적으로 비즈니스 로직을 작성하고 API.. 2023. 1. 8.

새로운 시작 자취를 시작했다. 이번 주는 이사 때문에 정신이 없었다. 어제 겨우 이사를 마치고 필요한 용품들을 구매한 후 겨우 정리 및 안정이 되었다. 나중에 회사를 다니게 될 경우, 유일하게 방해받지 않고 공부하며 업무를 볼 수 있는 공간이 필요했기에 이사를 생각했었다. 입사하게 되어 꾸준한 수입으로 스스로 자취 비용을 충당할 수 있게 되었고, 바로 실행으로 옮겼다. 시작은 미약하지만 목표하는 삶을 그리며 주거 공간의 확장을 꾸준히 이뤄나갈 것이다. 신입 백엔드 개발자의 빠른 적응을 위해 짬짬이 새로 쓰게 될 언어인 코틀린 개념을 공부하고 있다. 확실히 아직은 낯설다. 해서 코틀린 스프링 환경에서 DB 연동도 해보고 아주아주 간단한 api 프로젝트를 만들어봤다. 하지만 인터넷으로만 보는 건 한계가 있는 것 같다. .. 2023. 1. 1.

[회고] 2022년을 마치며 어제 왔던 2022년이 벌써 끝나 간다. 엊그제 같았다. 2022년 1월 1일. 2021년 12월 31과 2022년 1월 1일 아마도 수업이 끝나고 스터디를 진행했을 것이다. 늘 해오던 대로 스터디가 끝나고 집가서 정리 코딩을 하며 지인들께 카톡 새해 인사를 드리고 잠을 잤던 기억이 있다. 24살과 25살의 경계, 반 오십이 되었다는 사실이 그렇게 기쁘지도 슬프지도 않았다. 크게 의미 부여할 여유가 없었을 것이리라. 2022년, 난 무엇을 이루고자 했는지 오로지 개발에만 집중했던 2022년이다. 냉정하지만, 친구들에게 투자하는 시간조차 아까웠다. 약속을 많이 못 나가서 친구들이 서운해하거나 감정이 상했을지도 모르겠다. 하지만 종종 Burned 상태가 되면, 사람 만나길 좋아하는 내가 친구를 찾긴 했지만... 2022. 12. 29.

[@DataJpaTest] h2 인메모리 db를 이용한 테스트 설정 방법 서론 테스트 코드를 작성하는 것은 매우 중요하다고 익히 들었고, 필수적인 영역이기 때문에 이에 항상 만전을 기하고 있다. 모든 케이스를 테스트할 이유는 없기 때문에, 크게 경우를 나누어 필요하다고 생각하는 부분만 시나리오, 통합, 단위 테스트를 나누어 진행하는 것이 효율적이라고 들었다. 배포를 계속 해오면서 jar 파일을 빌드하는 도중 테스트를 제외하는 것은 무의미하다고 판단했기 때문에, 모든 테스트를 어떤 환경에서든 돌아 갈 수 있게 고민을 했던 기억이 있다. 이렇게 하나하나 완성도 있게 쌓아나가는 공부를 하는 것이 속도는 느리지만, 유의미한 발전 과정이라 느낀다. 이번에 대규모 리팩토링을 실시하면서 코드 수정 및 구조가 크게 개편되었고, 테스트 코드도 변경 사항이 많이 생겨서 다 수정했다. persi.. 2022. 12. 21.

[리팩토링] 도메인 모델 중심 Clean Architecture 로의 리팩토링 프로젝트를 수도 없이 리팩토링했다. 보다 더 객체지향적인 코드를 작성하기 위한, 유지 보수가 쉬운 코드를 작성하기 위한, 더 작은 객체를 위한 코드를 계속해서 고민하고 구조를 변경했다. 지난 달부터 해서 소프트 웨어 아키텍처에 관해서 관심이 생겼다. 클린 코드를 추구하다 보니 자연스럽게 설계적 고민으로 귀결되었다. 원티드 백엔드 챌린지를 하며 알게된 클린 아키텍처, 도메인 주도 설계 철저 입문, 도메인 주도 설계로 시작하는 마이크로 서비스를 읽어가며, 내가 구성해오던 소프트웨어 설계의 큰 전환점을 맞이하게 되었다. 단순히 예제 프로젝트만을 만드는게 아닌 본 프로젝트에 이를 적용시켜보기로 결정했다. MSA 는 오버 엔지니어링이라 판단했고, 모노리스 구조이지만 최대한 도메인 별 분리가 된 상위 바운디드 컨텍.. 2022. 12. 12.

[감상문] <도메인 주도 설계로 시작하는 마이크로 서비스 개발> 을 읽고 도메인 주도 설계 철저 입문과 같이 구매한 책이다. DDD 와 MSA 라니 제목이 매우 흥미로웠고, 분산 환경에서 정석적인 아키텍처 설계 및 코드 작성법을 배우고 싶었기 때문에 읽게 되었다. 첫 장은 아마존의 비즈니스 민첩성의 비밀 내용을 설명하며 아마존 만의 빠른 배포 속도의 노하우와, 현재 가장 대중화된 인프라인 클라우드 서비스 내에서 어울리는 애플리케이션의 조건을 설명한다. 그리고 자연스럽게 마이크로 서비스의 소개로 이어진다. 마이크로 서비스 아키텍처는 기존 모노리스 아키텍처와 다르게 설계에 각별히 신경을 써야 한다. 상대적으로 유지보수를 더 쉽게 할 수 있는 구조이지만, 데이터 정합성 문제가 가장 큰 이슈이기 때문이다. 그를 보완하기 위한 수많은 패턴들을 소개했다. 애플리케이션 레벨에서도 정합성을.. 2022. 12. 9.

[감상문] 도메인 주도 설계 철저 입문을 읽고 나서 이 책을 읽은 이유는 참 웃프다. 사야 할 책을 착각했다.. ㅎㅎ 착각하고 잘못 구매한 책이다. 당근러에게 구매한 책이라 환불은 어렵고 다시 물어보기 귀찮아서 그냥 읽기로 했다. 코드가 C# 언어로 작성되어 있고, 저자도 일본 사람이라서 안 읽힐 것 같았다. 대충 보다가 안 읽히면 당근에 판매하려고 했었다. 다행히 C#을 좀 해서 그런지 (예제 코드가 그렇게 어렵지 않았다) 그럭저럭 이해해가며 완독했다. 도메인 주도 설계니 계층형 아키텍처, 클린 아키텍처니 설명하는 개념들은 다 오가다가 배우고 봐왔던 코드 구성이 짬짬이 있었다. 그땐 그렇게 써야 되나 보다 하고 앵무새처럼 외워서 썼던 기억이 있다. 프로젝트를 시작하며 이해가 뒷받침되지 못한 틀을 깨고 그냥 정석대로 코드 작성을 했었.. 2022. 11. 27.

[이슈] Pageable test 관련 에러 💡문제 API Controller를 테스트 하는데 잘 성공하던 테스트가 계속 실패한다. org.springframework.web.util.NestedServletException: Request processing failed; nested exception is java.lang.IllegalStateException: No primary or single unique constructor found for interface org.springframework.data.domain.Pageable 테스트 코드 mockMvc.perform(get("/api/v2/users") .param("page", String.valueOf(page))) .andExpect(status().isOk()) .andE.. 2022. 11. 23.

[회고] 클린 아키텍처 책 스터디 및 미니 프로젝트를 마치며 최근 신입 개발자로의 여정을 시작하기 위해 채용 연계형 인턴십, 신입 공채를 보고 확인하며 서류 지원을 하고 있다. 여전히 할 일은 산더미지만, 조금 더 시간을 효율적으로 써가며 발전하고 싶기에 읽고 싶었던 책을 가지고 스터디를 하면 어떨까라는 생각을 했었다. 마침 같은 여정 길에 올라있는 친구가 떠올랐고, 제안을 수락하여 만들면서 배우는 클린 아키텍처라는 책을 가지고 2주 간의 스터디를 마쳤다. 이 책을 읽고 소프트웨어의 설계적 고민에 한층 더 깊이 빠지게 됨과 동시에 새로운 세상으로의 발을 디딘 느낌이 들었다. 설계 내용은 평소에 가장 많이 고민했던 부분인지라 책이 이해가 잘 되었었고, 애매했던 부분을 2회독, 다른 관점으로 읽어보려 3 회독하며 완독을 했다. 주관적이지만 개발 공부를 하며 드는 생각.. 2022. 11. 20.

[만들면서 배우는 클린 아키텍처] Chapter10. 아키텍처 경계 강제하기 10. 아키텍처 경계 강제하기 1. 경계와 의존성 아키텍처의 경계와 '경계를 강제한다는 것'의 의미를 알아보자. 아키텍처의 경계를 강제한다는 것은 의존성이 올바른 방향을 향하도록 강제하는 것. 가장 안쪽 계층 도메인 엔티티 도메인 엔티티에 접근하는 애플리케이션 계층 유스케이스 구현 어댑터 인커밍 포트를 통해 서비스 접근 서비스 아웃고잉 포트를 통해 어댑터 접근 설정 계층 어댑터 & 서비스 객체 생성용 팩터리 포함 의존성 주입 매커니즘 제공 의존성은 항상 안쪽으로 향해야 한다. 2. 접근 제한자 package-private 제한자의 중요성 패키지를 통해 클래스들을 응집된 모듈로서 만들어준다. 패키지 바깥 서는 접근 불가. 모듈 진입용 클래스만 따로 public으로 만들면 된다. 경계간 외부로.. 2022. 11. 15.

이전 1 ··· 3 4 5 6 7 8 9 ··· 17 다음

티스토리툴바