클린 코드(Clean Code)
-
16장 - 독립성클린 코드(Clean Code)/클린 아키텍처요약 2022. 12. 21. 00:01
좋은 아키텍트는 다음을 지원해야 합니다. - 시스템의 유스케이스 - 시스템의 운영 - 시스템의 개발 - 시스템의 배포 유스케이스 아키텍트는 시스템의 의도를 지원해야 합니다. 예를 들어 시스템이 장바구니 애플리케이션이라면 장바구니와 관련된 유스케이스를 지원해야 합니다. 만약 좋은 아키텍처를 갖춘다면 해당 시스템의 유스케이스는 시스템 구조 자체에서 한눈에 드러날 것입니다. 이들 행위는 일급 요소이며 시스템의 최상위 수준에서 알아볼 수 있으므로 개발자가 일일이 찾아 헤매지 않아도 됩니다. 운영 시스템이 초당 100,000명의 고객을 처리해야 한다면, 아키텍처는 이 요구와 관련된 각 유스케이스에 걸맞은 처리량과 응답 시간을 보장해야 합니다. 이런 형태를 지원하기 위한 시스템은 다양한 의미를 지닙니다. - 시스템..
-
15장 - 아키텍처란?클린 코드(Clean Code)/클린 아키텍처요약 2022. 12. 20. 00:01
아키텍처란? 아키텍처라는 단어는 권력과 신비로움을 연상케 합니다. 중대한 결정, 기술적 정취의 정점, 고수준의 문제에 집중해야 함 등이 떠오릅니다. 다른 프로그래머만큼 많은 작업은 하지 않을 수 있지만 아키텍트는 코드와 동떨어지면 안 됩니다. 아키텍처란 시스템을 컴포넌트로 분할하는 방법, 분할된 컴포넌트를 배치, 의사소통하는 방식에 따라 정해집니다. 가장 중요한 것은 아키텍처 안에 담긴 소프트웨어 시스템이 쉽게 개발, 배포, 운영, 유지보수되어야 합니다. 아키텍처의 목적으로 시스템의 동작도 중요하지만 주된 목적은 시스템의 생명주기를 지원하는 것입니다. 궁극적인 목표로 시스템의 수명과 관련된 비용은 최소화하고, 프로그래머의 생산성은 최대화해야 합니다. 개발 만약 5명 이내의 팀이라면 잘 정의된 컴포넌트, ..
-
14장 - 컴포넌트 결합클린 코드(Clean Code)/클린 아키텍처요약 2022. 12. 16. 00:01
컴포넌트 사이의 관계를 설명하는 세 가지 원칙을 다루고자 합니다. 의존성 비순환 원칙 컴포넌트 의존성 그래프에 순환이 있어서는 안 된다. 어떤 코드가 동작하는 것을 확인한 뒤, 다음날 출근해보면 작동하지 않는 경험이 있으신가요? 많은 개발자가 동일한 소스 파일을 수정하는 환경에서 발생하는 문제로 당신보다 더 늦게까지 일하면서 당신이 의존하고 있던 무언가를 수정해서 벌어진 일입니다. 이를 해결하기 위한 두 가지 방법이 발전되어 왔습니다. 주 단위 빌드 4일은 개발자들이 개별 작업 , 1일은 통합하는데 시간을 소요합니다. 하지만 프로젝트의 덩치가 커질수록 통합하는 작업을 하루가 아니라 더 소모됩니다. 점점 개발팀의 통합 효율성은 낮아지고 빌드 일정은 늘어나며 프로젝트가 감수할 위험은 커집니다. 순환 의존성 ..
-
13장 - 컴포넌트 응집도클린 코드(Clean Code)/클린 아키텍처요약 2022. 12. 14. 00:01
어떤 클래스를 어떤 컴포넌트에 포함시켜야 할까요? 이 장에서는 컴포넌트 응집도와 관련된 세 가지 원칙을 논합니다 REP: 재사용/릴리스 등가 원칙 CCP: 공통 폐쇄 원칙 CRP: 공통 재사용 원칙 Reuse/Release Equivalence Principle(REP) : 재사용/릴리스 등가 원칙 재사용 단위는 릴리스 단위와 같다. 지난 십 년은 메이븐, 라이닝언, RVM 같은 모듈 관리 도구가 많이 생겼습니다. 이 기간에는 재사용 가능한 컴포넌트가 컴포넌트 라이브러리가 엄청나게 많이 만들어졌기 때문입니다. 소프트웨어 컴포넌트가 릴리즈 절차를 통해 추적 관리되지 않거나 릴리스 번호가 부요되지 않는다면 해당 컴포넌트를 재사용하고 싶어도 할 수도 없고, 하지도 않을 것입니다. 릴리스 번호가 없다면 재사용 ..
-
12장 - 컴포넌트클린 코드(Clean Code)/클린 아키텍처요약 2022. 12. 13. 00:01
SOLID와 컴포넌트 SOLID가 벽과 벽돌의 어떻게 배치하는지 알려준다면 컴포넌트는 빌딩에 어떻게 방을 배치하는지 설명합니다. 컴포넌트란? 시스템의 구성 요소로 배포할 수 있는 가장 작은 단위입니다. 자바의 경우 jar파일이 컴포넌트입니다. 또한 여러 컴포넌트를 서로 링크하여 실행 가능한 단일 파일로 생성할 수 있습니다. 잘 설계된 컴포넌트는 독립적으로 배포 가능하고 개발 가능한 능력을 갖추어야 합니다. 역사 소프트웨어 개발 초장기에는 프로그램의 시작부에 프로그램이 로드될 주소를 선언하는 구문이 필요했습니다. 한번 위치가 결정되면 재배치가 불가능했습니다. 이런 구시대에 라이브러리 함수에 접근하기 위해서는 소스 코드를 애플리케이션 코드에 직접 포함시켜 단일 프로그램으로 컴파일했습니다. 이 시대의 장치는 ..
-
11장 - DIP: 의존성 역전 원칙클린 코드(Clean Code)/클린 아키텍처요약 2022. 11. 27. 00:01
의존성 역전 원칙 추상화에 의존하며 구체에는 의존하지 않음을 의미합니다. 하지만 소프트웨어의 시스템은 많은 구체화에 의존합니다. 예를 들어 String은 구체 클래스이며 추상 클래스로 만들려는 시도는 현실성이 없습니다. String 클래스는 매우 안정적으로 변경되는 일은 거의 없으며, 있더라도 엄격하게 통제됩니다. 따라서 DIP를 논할 때 OS나 플랫폼과 같이 안정성이 보장된 환경에 대해서는 무시하는 편입니다. 우리가 중요하게 생각해야 할 것은 열심히 개발중이라 자주 변경될 수밖에 없는 모듈들입니다. DIP를 지키는 매우 구체적인 코딩 실천법 - 변동성이 큰 구체 클래스를 참조하지 말아야 한다. - 변동성이 큰 구체 클래스로부터 파생하지 말아야 한다. - 구체 함수를 오버라이드 하지 말아야 한다. (추상..
-
10장 - ISP: 인터페이스 분리 원칙클린 코드(Clean Code)/클린 아키텍처요약 2022. 11. 26. 00:01
인터페이스 분리 원칙 책의 예제에서는 op1, op2, op3 메서드를 포함하고 있는 ops 인터페이스를 소개합니다. 이때 user1은 op1 만 user2는 op2 만 user3는 op3 만 사용한다고 하더라도 3가지 추상 클래스를 모두 구현해야 합니다. 또한 정적 타입 언어로 작성된 클래스라 하였을 때 op2의 소스 코드가 변경되면 user1도 다시 컴파일한 후 새로 배포해야 합니다. 따라서 op1, op2, op3를 각각의 인터페이스로 분리하여 사용하게 된다면 이런 문제를 해결할 수 있습니다. ISP와 언어 사실 동적 언어 타입의 언어라면 런타임에 추론을 하기 때문에 소스 코드 의존성이 아예 없어져 재컴파일과 재배포가 필요 없습니다. 따라서 ISP를 아키텍처보다는 언어와 관련된 문제라고 결론 내릴 ..
-
9장 - LSP: 리스코프 치환 원칙클린 코드(Clean Code)/클린 아키텍처요약 2022. 11. 25. 00:01
리스코프 치환 원칙 간단하게 인터페이스 하나를 두고 2개의 구현 클래스가 o1, o2가 존재할 때 o2자리에 o1을 치환하더라도 행위가 변하지 않아야 합니다. 인터페이스와 상속 License라는 인터페이스가 존재하며 calcFee라는 메서드를 가집니다. 이때 PersonalLicense와 BusinessLicense라는 2가지의 License 인터페이스를 구현하는 클래스가 존재합니다. 두 클래스는 서로 다른 알고리즘을 이용해서 라이선스 비용을 계산합니다. 이때 프로그램이 License 인터페이스에 의존하고 있다면 이들 하위 타입 중 무엇을 사용하는지는 중요하지 않습니다. 정사각형/직사각형 문제 : LSP 위반 정사각형은 직사각형의 하위 타입으로는 적절하지 않습니다. 직사각형은 높이와 너비가 서로 독립적인..