담백한 웹 개발 이야기

글의 목적 재사용 가능한 모듈 또는 컴포넌트를 만드는 작업은 비용을 절약하는 데 큰 역할을 한다. 재사용성 관련해서는 난이도 3배의 법칙이 있다. 재사용 가능한 모듈을 만드는 작업은 단일 소프트웨어에서 사용할 모듈을 개발할 때보다 3배 어렵다는 법칙이다. 프런트의 역할이 많아지면서 소프트웨어의 볼륨이 커졌다. 재사용 가능한 모듈과 컴포넌트를 만들지 않으면 유연한 요구사항 대응과 개발 비용이 많이 소비될 수 밖에 없다. 재사용 가능한 코드 개발을 위해서 어떠한 원칙들을 지켜야 하고 어떤 과정이 있는 지 정리한 포스트이다. 재사용성 재사용을 위한 소프트웨어 개발은 장래의 프로젝트에서 재사용할 수 있는 모듈을 현재 소프트웨어 개발 과정에서 창출하는 것을 의미한다. 다른 소프트웨어에서 재사용하기 위한 소프트웨어..

DIP: 의존성 역전 원칙 (Dependency Inversion Principle) 의존성 역전 원칙에서 말하는 유연성이 극대화된 시스템이란 소스 코드 의존성이 추상에 의존하여 구체에는 의존하지 않는 시스템이다. 이 아이디어를 규칙으로 보기는 확실히 비현실적이다. 소프트웨어 시스템이라면 구체적인 많은 장치에 반드시 의존하기 때문이다. DIP를 논할 때 운영체제나 플랫폼같이 안전성이 보장된 환경에 대해서는 무시하는 편이다. 우리가 의존하지 않도록 피하고자 하는 것은 바로 변동성이 큰 구체적인 요소이다. 그리고 이 구체적인 요소는 우리가 열심히 개발하는 중이라 자주 변경될 수밖에 없는 모듈들이다. 인터페이스는 구현체보다 변동성이 낮다. 그래서 실제로 뛰어난 소프트웨어 설계자와 아키텍트라면 인터페이스의 변동..

ISP: 인터페이스 분리 원칙 (Interface Segregation Principle) Ops 클래스 그리고 op1, op2, op3 오퍼레이션이 있고 사용자 클래스인 User1, User2, User3가 있다고 가정하겠다. User1은 op1만 사용하고, User2은 op2만 사용하고, User3은 op3만 사용한다. Ops의 오퍼레이션이 하나라도 수정되면 사용자 클래스는 모두 수정되어야 한다. 각 사용자 클래스는 사용하지 않는 오퍼레이션에 의존하고 있다. 오퍼레이션의 의존성을 분리하기 위해서는 op1, op2, op3의 인터페이스를 분리하여 해결할 수 있다. ISP를 아키텍처가 아니라 언어와 관련된 문제라고 결론 내일 여지가 있다. 정적 타입언어는 사용자가 타입선언문을 사용하도록 강제한다. 선언문..

LSP: 리스코프 치환 원칙 (Liskov Substitution Principle) 리스코프 치환 원칙는 바바라 리스코프가 정의한 원칙으로 바바라 리스코드는 하위 타입을 다음과 같이 정의했다. 여기에서 필요한 것은 다음과 같은 치환(substitution) 원칙이다. S타입의 객체 o1 각각에 대응하는 T타입 객체 o2가 있고, T타입을 이용해서 정의한 모든 프로그램 P에 o2의 자리에 o1을 치환하더라도 P의 행위가 변하지 않는다면, S는 T의 하위타입이다. LSP는 아키텍처 수준까지 확장할 수 있고, 반드시 확장해야만 한다. 치환 가능성을 조금이라도 위배하면 시스템 아키텍처가 오염되어 상당량의 별도 메커니즘을 추가해야 할 수 있기 때문이다. SOLID 원칙 시리즈 - 리스코프 치환 원칙 LSP: 리..

OCP: 개방-패쇄 원칙 (Open-Closed Principle) 개방 폐쇄 원칙은 "소프트웨어 개체(artifact)는 확장에는 열려 있어야 하고, 변경에는 닫혀있어야 한다."를 의미한다. 다시 말해 소프트웨어 개체의 행위는 확장할 수 있어야 하지만, 이때 산출물을 변경해서는 안 된다. 소프트웨어 아키텍처를 공부하는 가장 근본적인 이유가 바로 이 때문이다. 만약 요구사항을 살짝 확장하는 데 수정사항이 많다면 설계한 아키텍트는 엄청난 실패에 맞닥뜨린 것이다. 소프트웨어 아키텍처가 훌륭하다면 변경되는 코드의 양이 가능한 한 최소화될 것이다. 이상적인 변경량은 0이다. 어떻게 하면 될까? 서로 다른 목적으로 변경되는 요소를 적절하게 분리하고(단일 책임 원칙, SRP), 이들 요소 사이의 의존성을 체계화함으..

SRP: 단일 책임 원칙 (Single Responsibility Principle) 역사적으로 SRP는 "단일 모듈은 변경의 이유가 하나. 오직 하나뿐이어야 한다."로 기술되어 있다. 변경의 이유는 무엇을 의미하는 할까? 소프트웨어 시스템은 사용자와 이해관계자를 만족시키기 위해 변경된다. SRP가 말하는 변경의 이유는 바로 이들 사용자와 이해관계자를 가리킨다. 단일 모듈은 무엇을 의미하는 할까? 가장 단순한 정의는 소스파일이다. 대부분의 경우 이 정의는 잘 들어 맞는다. 하지만 일부 언어와 개발 환경에서는 코드를 소스파일에 저장하지 않는다. 이러한 경우 모듈은 단순히 함수와 데이터 구조로 구성된 응집된 집합이다. 응집된이라는 단어가 SRP를 암시한다. 단일 액터를 책임지는 코드를 함께 묶어주는 힘이 바..

일반적인 상황의 제어흐름 일반적인 상황에서 프로그램은 Top-Down으로 제어흐름이 흐른다. 다형성으로 인한 의존성 역전 현상 다형성이 끼어들면 의존성 역전 현상이 발생한다. HL1 모듈은 인터페이스를 통해 F()를 호출한다. ML1과 I 인터페이스 사이의 소스코드 의존성이 제어흐름과 반대이다. 결론 객체지향 언어가 다형성을 안전하고 편리하게 제공한다는 사실은 소스 코드 의존성을 어디에서든 역전시킬 수 있다는 뜻이기도 하다. 결국 소스 코드 의존성이 제어흐름의 방향과 일치되도록 제한되지 않는다. 의존성 역전! 한장에 정리 일반적인 상황의 제어흐름 일반적인 상황에서 프로그램은 Top-Down으로 제어흐름이 흐른다. 다형성으로 ... blog.naver.com

글의 목적 코드 리뷰를 받다보면 본인이 작성한 네이밍의 의미가 모호하다는 피드백을 받거나 로직이 이해하기 힘들다는 피드백을 받을 때가 있다. 동료들이 본인이 작성한 코드를 이해하지 못했을 때는 코드 작성 방법에 변경할 필요가 생긴 것이다. 이 부분을 개선하기 위해 이해하기 쉬운 코드 작성 방법을 리서치를 했다. 이 포스트는 리서치한 자료들을 정리한 포스트이다. 왜 코드는 이해하기 쉬워야 할까? 우리는 코드를 작성하는 시간보다 코드를 보고만 있는 시간을 대부분 차지한다. 우리에게는 시간은 유한하고 제한시간에 요구사항을 개발하는 게 하나의 목표이다. 그렇기 때문에 서비스를 운영하고 있는 내 자신 또는 동료가 코드를 이해하는 데 소비되는 시간을 최소화해야 한다. 코드를 완전히 이해한다는 것은 무엇을 의미할까?..

2019년 5월 19일에 구조 리펙토링 정리 관련 작업 중에 고민했던 내용들을 정리한 포스트입니다.글의 목적코드는 만들어진 목적과 역할이 있기 때문에 어울리는 자리가 있다. 어울리는 자리에 정확히 있으면 왜 그 자리에 있는 지 이해가 되고 유추가 가능하다. 그런데 막상 코드를 작성할 때 코드가 어떤 자리에 위치해야 하는 지 결정을 못해 유틸에 정의하는 경우를 많이 봤다. 코드의 명확한 위치를 정하는 기준에 대해서 알아보기 위해 작성한 글이다.코드의 위치코드의 위치를 정하는 기준은 변수/함수/클래스/컴포넌트/모듈 모두 동일한 기준으로 정의된다. 기본적으로 관계가 깊은 코드를 그룹핑하고 영향도에 따라 범위를 최소화하는 것이다. 특정 컴포넌트에만 사용될 때 특정한 컴포넌트에 사용되는 코드는 해당 컴포넌트에 정..