클린 코드를 작성하기 위해서는 우선 지저분한 코드더라도 작성한 후에 정리하는 것이 좋다 깔끔한 작품을 내놓으려면 단계적으로 개선해야한다는것을 기억해야한다. 이 책에 따르면 , 프로그램을 망치는 가장 좋은 방법 중 하나는 개선 이라는 이름 아래 구조를 크게 뒤집는 행위이다. 어떤 프로그램은 그저 그런 개선에서 결코 회복 하지 못하기도 한다. 그래서 테스트 주도 개발(tdd)가 중요하다. TDD는 언제 어느때라도 시스템이 돌아가야 한다는 원칙을 따르기 때문에 변경 후에도 시스템이 변경 전과 똑같이 돌아가야한다는 것이다. 이를 위해서는 테스트 슈트 작성이 필요하기도 한다. 변경이 있을 때마다 영향을 미치는 부분을 테스트 하면서 수정하여 개선해 나가면 시스템을 많이 해치지 않을 수 있다. 코드는 언제나 최대한 ..
| 동시성이 필요한 이유 동시성은 결합을 없애는 전략이다. 무엇과 언제를 분리하는 전략이다. 스레드가 하나인 프로그램은 무엇과 언제가 서로 밀접하다 무엇과 언제를 분리하면 애플리케이션의 구조와 효율이 극적으로 나아진다. 어떤 시스템은 응답 시간과 작업 처리량 개선이라는 요구사항으로 인해 직접적인 동시성 구현이 불가피하다. 많은 사용자를 동시에 처리하면 시스템 응답시간을 높일 수 있다. | 동시성에 대한 미신과 오해 - 동시성은 항상 성능을 높여준다? 동시성을 때때로 성능을 높여준다. 대기시간이 길거나 여러 프로세서가 동시에 처리할 독립적 계산이 많은 경우에만 그렇다. - 동시성을 구현해도 설계는 변하지않는다? 무엇과 언제를 분리하면 시스템 구조가 크게 달라진다. - 웹 또는 ejb 컨테이너를 사용하면 동..
켄트 백이 제시한 단순한 설계 규칙 네가지를 지키면 소프트 웨어 설계 품질을 크게 높일 수 있다고 대부분의 사람들은 말한다. | 켄트백의 규칙 네가지 (중요도순) - 모든 테스트를 실행한다 - 중복을 없앤다 - 프로그래머의 의도를 표현한다 - 클래스와 메서드 수를 최소로 줄인다 단순한 설계 규칙 1 : 모든 테스트를 실행하라 설계는 의도한 대로 돌아가는 시스템을 내놓아야 한다. 모든 테스트 케이스를 만들어 무조건 통과하는 시스템이야말록 ‘테스트가 가능한 시스템’이다. 이는 크기가 작고 한가지 목적만 수행하는 클래스를 만든다. 단일 책임의 원칙을 준수하는 클래스는 테스트가 훨씬 쉽다. 의존 관계 역전 원칙을 적용하고, 의존성 주입, 인터페이스, 추상화 등과 같은 도구를 사용해 결합도를 낮추면 설계 품질이 ..
1. 시스템 제작과 시스템 사용을 분리하라 - 제작은 사용이 아니다. 👉 소프트웨어 시스템은 (애플리테이션 객체를 제작하고 의존성을 서로 '연결' 하는) 준비과정과 (준비 과정 후에 이어지는) 런타임 로직을 분리해야한다. 시작단계 : 관심사 분리 1) Main 분리 : 시스템생성과 시스템 사용을 분리하는 방법 생성과 관련한 코드는 모두 main이나 main 이 호출하는 모듈로 옮기고, 나머지 시스템은 모든 객체가 생성되었고 의존성이 모두 연결되었다고 가정할 때, main에서 시스템에 필요한 객체를 생성한 후 이를 애플리케이션에 넘겨 사용하도록 한다. 2) 팩토리 ABSTRACT FACTORY 패턴 (추상 팩토리 패턴) 추상 팩토리 패턴은 다양한 구성 요소 별로 '객체의 집합'을 생성해야 할 때 유용하다...
1. 클래스의 체계 - 캡슐화 접근제한자를 통해 캡슐화와 추상화 단계를 이룰 수 있다 2. 클래스는 작아야한다. - 즉 클래스가 맡은 책임이 한가지여야 한다. 한 클래스는 하나의 역할을 한다고 생각한다. - 단일 책임의 원칙 큰 클래스 몇개가 아닌 작은 클래스 몇개로 구성된 시스템이 복잡한 시스템을 구축하는데 더 적합하다. - 응집도 인스터스변수가 작아야한다. 모든 인스턴스 변수를 메서드마다 사용하는 클래스의 응집도가 가장 높다. 응집도가 높은 클래스가 바람직하다고 하기는 어렵지만, 단일 책임원칙을 위해서는 결국 응집력이 높은 여러개의 클래스들이 생성될 것이다. 깨끗한 코드를 작성한다면 클래스를 체계적으로 정리하여 변경을 하기에 더 쉬운 코드가 된다.
