본문 바로가기

Develop167

리팩토링으로 클래스 응집도 높이기 객체지향 코드를 짜기 위해 노력해 본 사람이라면, 좋은 객체지향적 코드를 짜기 위해서는 결합도는 낮추고 응집도를 높이라는 말을 들어보셨을 것이다. 혹시 결합도, 응집도가 무엇인지 잘 모르는 사람은 아래의 링크를 통해 공부하고 오자. https://devkingdom.tistory.com/300 결합도와 응집도 이야기 OOP를 다루는 개발자라면 혹은 컴퓨터 공학을 전공하는 사람이라면 누구나 이런 얘기를 들어본 적이 있을 것이다. "결합도는 낮추고, 응집도는 높여야 유지보수하기 쉬운 좋은 프로그램이 된다" devkingdom.tistory.com 클래스가 아래와 같은 이유로 분리의 필요성을 느낀다면 이는 클래스가 응집도가 낮은 것이니 클래스를 분리해야한다. 1. 변경의 이유를 기준으로 클래스를 분리 클래스가.. 2023. 8. 23.
[git] git branch 삭제하기 프로젝트를 진행하다면 수많은 브랜치를 만들고 작업을 진행하게 된다. 브랜치를 계속 만들다 보면 이미 반영된 브랜치도 로컬에 남아있게 된다. 이미 정상적으로 반영된 브랜치이니 해당 브랜치는 유지할 필요가 따로 없다. 그래서 아래 명령어를 통해 브랜치를 삭제 해줘야한다. 로컬 브랜치 삭제하기 git branch -d 위의 명령어를 날렸을 때, 만약 브랜치에 병합되지 않은 변경사항이나 푸시되지 않은 커밋이 있으면 삭제가 되지 않는다. 브랜치가 가지고 있는 커밋이 다른 브랜치나 저장소에 기록되어 있지 않을 경우 커밋 히스토리가 손실되는 것을 git 이 막기 때문이다. 이럴때는 아래와 같이 강제로 삭제할 수도 있다. git branch -D 원격 브랜치 삭제하기 원격 브랜치는 아래의 명령어로 삭제가 가능하다. g.. 2023. 7. 28.
[git] commit message 를 잘 작성하는 방법 새로운 회사에 입사하고, 깃의 새로운 커밋 컨벤션에 적응하느라 애를 썼다. 그래도 팀에서 정해진 컨벤션을 지키며 개발하니, 내가 어떤 내용에 대한 개발을 할지 명확하게 구분이 가능하고, 또한 동료의 산출물을 리뷰하는데에도 큰 도움이 됐다. 오늘은 그래서 깃 커밋 메시지에 대해 정리를 해두려한다. 커밋 메시지를 잘 써야하는 이유 1. 일관적이고 명확한 내용이 들어간 커밋 메시지는 다른 개발자가 산출물을 더 잘 이해할 수 있도록 돕는다. 2. 잘 작성된 커밋 메시지는 코드에서 문제가 발생했을 때, 더 쉽고 편하게 디버깅이 가능하게 한다. 3. 잘 작성된 커밋 메시지는 프로젝트의 맥락을 이해하는데 도움을 준다. 즉 해당 프로젝트에서 함께 작업하는 다른 개발자와 본인에게 변경 사항에 대한 컨텍스트를 전달한다. .. 2023. 5. 30.
동시성과 정합성을 어떻게 관리할 수 있을까? 이전에 동시성에 대한 내용을 다룬적 있다. https://devkingdom.tistory.com/303 동시성 프로그래밍에 대하여 백엔드 개발자라면 동시성을 고려한 프로그래밍을 할 줄 알아야한다. 다만 아직 학생이거나 주니어 레벨에서는 이러한 동시성을 이해하기가 쉽지는 않다. 프론트 단의 개발과는 다르게 백엔드 devkingdom.tistory.com 관련한 내용을 옛자료를 보고 정리를 해놔서... 요즘 대체적으로 많이 쓴느 개발 환경인 Spring JPA 에서는 어떻게 적용하면 될지를 정리해야겠다는 생각을 했었다. 우선 상황을 가정해보자. 상품 구매 시스템을 만든다고 가정하고, 인기 있는 상품을 조회하는 기능을 개발한다고 가정하자. 상품 구매 -> 이미 구매된 동일 상품이 있는지 조회 -> 상품 정보.. 2023. 3. 19.
RESTFul API 설계 팁 - Consumer first 개발하거나 설계하는 사람의 시각에서가 아닌 실제 사용하는 사용자 입장에서 직관적이고 명료하게 설계해야 한다. 소비자는 엔드 유저인 실제 고객이 아니라 이 api를 이용하는 사람이 될 것이다. - Make best use of HTTP http의 메서드와 request, response 의 타입, 헤더값 등을 이용하는 등 http의 장점을 모두 사용해서 설계할 필요가 있다. - Request methods 최소한 메서드의 4 종류는 구분하여 설계하라 . GET, POST, PUT, DELETE 를 이용하여 crud 를 구분하여 설계하자 - Response Status 각각의 api 요청에 따른 응답 코드가 전송되어야 한다 (200, 404, 400, 201, 401 등..) .. 2023. 2. 15.
Microservice 12 Factors + 3 Factors 1. base code - 각 레퍼지토리에 저장된 마이크로서비스 단일 코드 베이스를 뜻함. - 버전 제어를 위한 목적, 형상관리를 위해 코드를 한곳에서 배포하는 것이 목적. - 이후 테스트 환경이나 라이브 환경 등에 배포하기 위해서는 통일된 코드 관리가 필요함 2. dependency isolation - 각 마이크로 서비스는 자체 종속성을 가지고 패키징되어 있는 구조 - 전체 시스템에 영향을 주지 않는 상태에서 변경되어야 함 3. configurations - 코드 내에 하드 코딩되어 있는 구성 설정 정보가 없어야함 - 위부에서 마이크로서비스의 설정에 필요한 작업들을 할 수 있어야함 - 동일한 구성정보가 외부 서비스 정보에 전파될 수가 있음 4. linkable backing services - 서비스.. 2023. 2. 15.
[Design Pattern] Singleton Pattern 우리는 객체를 하나만 사용하기 위해 Singleton 패턴을 많이 활용한다. Singleton 을 구현하기 위해 몇가지 방법이 있는데 간단하게 말씀드려보겠다. public static member 해당 방법은 인스턴스를 초기화 시킨 뒤 고정시켜 사용하는 방법이다. 사용자는 변수에 직접 접근하여 사용하여야 한다. 이렇게 사용하면 의도하지 않은 객체 생성을 막을 수 있다. public class Member { public static final Member INSTANCE = new Member(); private Member() { } } private static final field 해당 방법은 getInstance라는 메서드를 통해 instance에 접근하는 방법이다. 인스턴스 변수에 직접 접근하는.. 2023. 1. 28.
추상적인 책임 vs 상세한 책임 앞선 글들에서 객체지향 설계의 품질은 책임을 어떻게 설정하는가에 달려있다고 했다. 객체지향 설계를 하다보면 책임의 레벨을 어떻게 설정해야할지 고민할 때가 올 것이다. 오늘은 어떤 수준의 책임을 만들어내는 것이 적합한지에 대해 이야기 해보고자 한다. 1번 상황 위의 상황을 보자. 이와 같은 경우는 책임에 대한 자율성이 높지만 너무 추상적인 책임이다. 이러한 경우에는 자율성이 높은 만큼 잘못된 의도대로 책임이 수행되지 않을 수 있다. 2번 상황 위와 같은 경우는 1번과는 다르게 아주 상세한 수준으로 구현이 되었다. 이렇게 하면 정확하게 의도한대로 책임을 수행하긴 하지만 책임에 대한 자율성이 제한된다. 마치 신입직원(?)처럼 팀장에게 의존할 수 밖에 없는 형태이다. 3번 상황 1번 상황에서의 일하라라는 책임은.. 2022. 10. 25.
[Design Pattern] Composite 패턴 정리 Composite pattern 오늘은 Composite Pattern 에 대해 정리를 해 두고자한다. 해당 패턴은 전체와 부분을 하나의 단위로 추상화해야할 경우 사용된다. 클라이언트 입장에서 메시지 수신자가 부분인지 전체인지에 상관없이 동일한 메시지를 통해 동일한 방식으로 대상과 상호작용해야할 경우 사용하는 패턴이다. 아래는 Composite Pattern 을 다이어그램으로 그린 형태이다. Composite pattern에서 협력에 참여하는 역할과 책임을하는 구성요소를 살펴보자. Component 는 클라이언트와 협력할 수 있는 공용인터페이스를 정의하는 역할을 수행한다. 예시로 든 다이어그램에서는 추가, 제거, 포함된 하위 컴포넌트 반환 등의 역할을 수행한다. Leaf 는 공용 인터페이스에 대한 오퍼레.. 2022. 10. 11.