stack — 최근 글

객체지향 프로그래밍의 장점 중 하나는 코드의 재사용이다. 객체지향은 코드를 재사용 하기 위해 새로운 코드를 추가한다. 객체지향에서 클래스를 재사용 하는 전통적인 방법은 클래스를 추가하는 것이다. 이 장에서는 클래스를 재사용하기 위해 클래스를 추가하는 대표적인 방법인 상속에 관한 내용이다. 상속 외에도 새로운 클래스의 인스턴스 내에 기존 클래스의 인스턴스를 포함시키는 합성이라는 방법도 있다. 중복 코드를 제거해야 하는 이유 중복 코드는 변경을 방해한다. 중복 코드는 코드를 수정하기 위해 어떤 코드가 중복인지 먼저 찾아야 하는 시간이

HAProxy를 HA 기능 또는 리버스 프록시 용도의 gateway로 사용하고 있다면 하위의 master와 slave 노드들의 모든 상태를 REST API로 추출할 수 있다. 이것은 어플리케이션의 health check api 뿐만 아니라 TCP, SSH, HTTP 등 다양한 프로토콜에도 대응하기 때문에 특정 프로토콜에 의존적이지 않다. 또한 HAProxy에 하위 프로세스만 띄우는 형식이라 설정이 번잡하지 않고, 모든 노드를 알고 있는 HAProxy를 사용하면 health check 어플리케이션을 구축할 필요가 없으므로 비용도 절감

의존성 주입 Dependency Injection : 사용하는 객체가 아닌 외부의 독립적인 객체가 인스턴스를 생성한 후 이를 전달해서 의존성을 해결하는 방법 의존성 주입 기법 생성자 주입 Setter 주입 메서드 주입 SERVICE LOCATOR 패턴 서비스를 사용하는 코드로부터 서비스가 누구인지 (서비스를 구현한 구체 클래스의 타입이 무엇인지), 어디에 있는지(클래스 인스턴스를 어떻게 얻을지)를 몰라도 되게 해준다. 사용처에서 특정 인스터스에 의존하기 원한다면 아래와 같이 사용해야 한다. Movie 생성자 만으로 의존성이 해결되지

한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다. 원제 : FastAPI: Modern Python Web Development 저자 : Bill Lubanovic 출간 : O'Reilly Media, 2023 / 한빛미디어, 2024 웹 서비스를 구성하는 요소 중에 비즈니스 요구사항을 처리하고, 데이터의 가공과 저장을 하고, 보안의 위협에서 적절한 조치를 해야하는 백엔드 어플리케이션은 없어서는 안되는 요소다. 웹 어플리케이션은 원래 정적 페이지로부터 시작되어 자바스크립트로 시작된 동적 처리에서 마침내 대

개방 폐쇄 원칙 Open-Closed Principle : 소프트웨어 개체 (클래스, 모듈, 함수) 는 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다. 이는 다음의 관점을 반영한다. 확장 -> 동작 확장에 대해 열려 있다 : 어플리케이션의 요구사항이 변경될 때 이 변경에 맞게 새로운 동작을 추가해서 어플리케이션의 기능을 확장할 수 있다. 수정 -> 코드 수정에 대해 닫혀 있다 : 기존의 코드를 수정하지 않고도 어플리케이션의 동작을 추가하거나 변경할 수 있다. 인터페이스, 추상화는 컴파일타임 의존성을 고정기키게 한

남들 평생 한번 겪을까 말까 하는 큰 일들이 한 분기 안에 다 일어나서 이번 정리는 짧게 하려고 한다. 작년엔 오토바이 몇 대가 치고 가더니, 올해는 짐 가득 실은 덤프트럭 여러대가 나를 깔아 뭉게고 갔습니다. 추스리는 중. 좋은 사람이란 무엇인가에 대해 나름대로 결론을 얻었습니다. 일련의 사건들과 별개로 이젠 참는 것을 완전히 그만 두게 되었습니다. *생각없이 무례하겠다는 뜻이 아님.* 요즘 유행하는 분산락 구현, 버전 릴리즈에 큰 기능 실장, 인증 프로젝트, 면접 참관 까지 회사가 매우 즐겁습니다. 하루가 48시간 이였으면 좋겠

한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다. 원제 : Observability Engineering 저자 : Charity Majors, Liz Fong-Jones, George Miranda 출간 : O'Reilly Media, 2022 / 한빛미디어, 2024 프로덕트 운영을 하다 보면 서비스 품질을 유지하기 위해 항상 모니터링 알람에 신경을 써야 할때가 많다. 그러나 대부분의 모니터링은 사고가 먼저 있고 그로 인한 사후 대응성격의 산출물인 경우가 많다. 하지만 현대의 비즈니스는 복잡한 요구사항을

모든 의존성이 나쁜것은 아니다. 의존성은 객체들의 협력을 가능하게 만드는 매개체라는 관점에서 자연스러운 것. 바람직한 의존성 = 재사용성 어떤 의존성이 다양한 환경에서 클래스를 재사용할 수 없도록 제한한다면 그 의존성은 바람직하지 못한 것. 즉, 컨텍스트에 독립적인 의존성은 바람직하다. 의존성에 대한 정도 = 결합도 (약한 결합도, 강한 결합도) 의존성과 결합도 일반적으로 의존성과 결합도를 동의어로 사용하지만 사실 두 용어는 서로 다른 관점에서 관계의 특성을 설명하는 용어다. 의존성은 두 요소 사이의 관계 유무를 설명한다. 따라서