전체 글
-
엔터프라이즈 애플리케이션 아키텍처 패턴 1 - 계층 구조책책책 책을 읽읍시다/프로그래밍 2023. 3. 12. 01:31
저자 : 마틴 파울러 옮긴이 : 최민석 들어가며 흔히 접하는 디자인 패턴이 프로젝트의 수많은 코드 중 특정 문제를 다루기 위한 것이라면 이 책에 나오는 패턴들은 그보다 광범위하게 애플리케이션의 전반적인 문제를 다룬다. 전자의 해결 대상은 나무이고 후자의 것은 숲이다. 그리고 여기서 고민한 패턴들 대부분이 현재에는 프레임워크에 녹여져 있다. 초반부 내용은 JPA와 이를 구현한 Hibernate같은 ORM 기술에 적용되어 있고, 중반부는 MVC 프레임워크에서 찾아볼 수 있다. 지금으로서는 당연한 기술이지만 당시에 치열하게 반복 작업을 줄이려는 노력과 추상화에 힘쓴 덕분에 이렇게 편리하게 개발할 수 있지 않나 싶다. 내용을 하나하나 정리하기에는 비슷한 내용이 많고, 저수준의 프레임워크적인 내용이라 현재도 잘 ..
-
호텔 상세 페이지 성능 개선 경험 : DB 데이터 패치 크기를 줄이자개발 나누고 더하기/DB 2023. 3. 3. 23:05
1년 전 간단한 쿼리 수정으로 호텔 상세 정보 조회 API 응답속도를 15% 가량 개선한 적이 있다. APM으로 핀포인트를 쓰는데 아래와 같이 API에서의 메서드별 처리시간이 나온다. 어디서 시간이 오래 걸리는지 병목지점을 찾기 위해 봤는데, 아래와 같이 단순한 쿼리가 전체 응답시간의 60%정도를 차지하고 있었다. SELECT ha.hotel_id, a.name, ha.is_using FROM hotel_amenity ha JOIN amenity a ON ha.amenity_id = a.id WHERE hotel_id = 77; 아주 단순한 쿼리이고, 해당 쿼리를 가져와 실행계획을 보면 인덱스도 잘 타는 것을 확인할 수 있다. 일단 여기까지 중간 정리하면, 호텔에는 아기 침대, 피트니스, 사우나 등 해당..
-
SQL AntiPatterns : 개발자가 알아야 할 25가지 SQL 함정과 해법QL책책책 책을 읽읍시다/프로그래밍 2023. 2. 23. 15:58
저자 : 빌 카윈 옮긴이 : 윤성준 DBA가 아닌 프로그래머의 애플리케이션 개발 레벨에서의 자주 잘못 쓰는 SQL문 방식이나 테이블 설계에 대해 문제점과 대안을 제시하는 책이다. 어디서 봤더라. 2년전에 애플리케이션 개발하는데 SQL 종속적이지 않게 이끌어주는 책으로 잘 못 보아 구매했었다. SQL AntiPatterns가 아닌 Anti SQL Patterns로 잘 못 본 것이었다. 당시 있던 회사 서비스의 심각한 DB 종속적인 구조 때문에 스트레스를 많이 받았었고, 어떻게 뜯어 고칠까를 계속 고민했었다. 비즈니스 로직의 반이 쿼리나 스토어드 프로시저에 있었고, 자바는 이렇게 나온 데이터를 매핑해주는 역할에 그치는 경우가 많았다. 몇백줄에 이르는 쿼리나 프로시저 수정은 항상 부담이었고, 테스트는 더더욱 ..
-
오브젝트 6 - 다형성, 서브타이핑, 일관된 협력책책책 책을 읽읍시다/프로그래밍 2023. 2. 14. 23:29
다형성 다형성의 의미와 종류 다형성(polymorphism)이라는 단어는 그리스어에서 '많은'을 의미하는 'poly'와 '형태'를 의미하는 'morph'의 합성어로 '많은 형태를 가질 수 있는 능력'을 의미한다. 컴퓨터 과학에서는 다형성을 하나의 추상 인터페이스에 대해 코드를 작성하고 이 추상 인터페이스에 대해 서로 다른 구현을 연결할 수 있는 능력으로 정의한다[Czanecki00]. 간단하게 말해서 다형성은 여러 타입을 대상으로 동작할 수 있는 코드를 작성할 수 있는 방법이라고 할 수 있다. 객체지향 프로그래밍에서 사용되는 다형성은 아래와 같이 4가지로 분류할 수 있다. 유니버설(Universal 매개변수(Parametric) : 제네릭 프로그래밍과 관련이 높은데 클래스의 인스턴스 변수나 메서드의 메개..
-
오브젝트 5 - 상속 vs. 합성책책책 책을 읽읍시다/프로그래밍 2023. 2. 14. 22:15
중복과 상속 중복 코드는 변경을 방해한다. 이것이 중복 코드를 제거해야 하는 가장 큰 이유다. 중복 코드가 가지는 가장 큰 문제는 코드를 수정하는 데 필요한 노력을 몇 배로 증가시킨다는 것이다. 우선 어떤 코드가 중복인지를 찾아야 한다. 일단 중복 코드의 묶음을 찾았다면 찾아낸 모든 코드를 일관되게 수정해야 한다. 모든 중복 코드를 개별적으로 테스트해서 동일한 결과를 내놓는지 확인애야만한다. 중복 코드는 수정과 테스트에 드는 비용을 증가시킬뿐만 아니라 시스템과 우리를 공황상태로 몰아넣을 수도 있다. 이번 예제는 한 달에 한 번씩 가입자별로 전화 요금을 계산하는 애플리케이션이다. 전화 요금을 계산하는 규칙은 통화 시간을 단위 시간당 요금으로 나눠주면 된다. 10초당 5원의 통화료를 부과하는 요금제에 가입돼..
-
오브젝트 4 - 메세지, 인터페이스, 의존성책책책 책을 읽읍시다/프로그래밍 2023. 2. 13. 23:21
퍼블릭 인터페이스와 오퍼레이션 객체가 의사소통을 위해 외부에 공개하는 메세지의 집합을 퍼블릭 인터페이스라고 부른다. 프록래밍 언어의 관점에서 퍼블릭 인터페이스에 포함된 메세지를 오퍼레이션(operation)이라고 부른다. 오퍼레이션은 수행 가능한 어떤 행동에 대한 추상화다. 흔히 오퍼레이션이라고 부를 때는 내부의 구현 코드는 제외하고 단순히 메세지와 관련된 시그니처를 가리키는 경우가 대부분이다. 영화 예매 시스템의 예로 DiscountCondition 인터페이스에 정의된 isSatisfiedBy가 오퍼레이션에 해당한다. public interface DiscountCondition { boolean isSatisfiedBy(Screening screening); } 그에 비해 메세지를 수신했을 때 실제로..
-
오브젝트 3 - 데이터 중심 설계 vs. 책임 주도 설계책책책 책을 읽읍시다/프로그래밍 2023. 2. 13. 14:31
데이터 중심 설계 예제로 보는 설계 품질과 트레이드 오프 객체지향 설계에서는 두 가지 방법을 이용해 시스템을 객체로 분할할 수 있다. 첫 번째 방법은 상태(데이터)를 분할의 중심축으로 삼는 방법이고, 두 번째 방법은 책임을 분할의 중심축으로 삼는 방법이다. 데이터 중심의 관점에서는 객체는 자신이 포함하고 있는 데이터를 조작하는 데 필요한 오퍼레이션을 정의한다. 책임 중심의 관점에서 객체는 다른 객체가 요청할 수 있는 오퍼레이션을 위해 필요한 상태를 보관한다. 데이터 중심의 관점은 객체의 상태에 초점을 맞추고 책임 중심의 관점은 객체의 행동에 초점을 맞춘다. 전자는 객체를 독립된 데이터 덩어리로 바라보고 후자는 객체를 협력하는 공동체의 일원으로 바라본다. 훌륭한 객체지향 설계는 책임에 초점을 맞춰야 하는데..
-
오브젝트 2 - 유연한 객체 협력 모델 만들기책책책 책을 읽읍시다/프로그래밍 2023. 2. 8. 22:58
이번 예제는 영화 예매 시스템이다. 영화를 상영하는 스크린이 있고, 영화 상영 요금에 대한 할인 정책과 할인 조건이 있다. 할인 정책은 금액(예: 1000원)과 비율(예: 5%)이 있고, 한 영화에 하나만 적용 가능하다. 할인 조건은 순번(예: 조조 첫타임 할인)과 기간(예: 월요일 10:00~12:00 할인)이 있는데 정책과 달리 복수개가 적용 가능하다. 아래는 각 객체들에 대한 설명이다. Screening : 영화 상영 정보에 따라 상영 회차별 예매 금액을 표시한다. Reservation : 영화 상영 회차별 예약을 담당한다. Movie : Screen의 요청을 받아 영화별 할인 정책에 따른 예매 금액을 계산한다. 영화별로 할인 정책을 정할 수 있다. DiscountPolicy : 할인 정책으로 아래..