728x90
반응형

Book Record/Clean Code 14

[Clean Code] 13장 동시성(2)

깨끗한 코드를 작성하기 위한 열세번째 기록 다중 스레드 프로그래밍에서 사용하는 실행 모델 1. 생산자-소비자 생산자 스레드가 정보를 생성해 버퍼나 대기열에 넣습니다. (버퍼와 대기열은 한정된 자원) 소비자 스레드는 대기열에서 정보를 가져와 사용합니다. 생산자 스레드는 대기열에 빈 공간이 있어야 정보를 채웁니다. 소비자 스레드는 대기열에 정보가 있어야 가져옵니다. 생산자 스레드는 대기열에 정보를 채운 다음 소비자 스레드에게 신호를 보냅니다. 소비자 스레드는 대기열에서 정보를 읽어들인 후 신호를 보냅니다. 따라서 잘못하면 생산자 스레드와 소비자 스레드가 둘다 진행 가능함에도 불구하고 동시에 서로에게서 오는 신호를 기다릴 가능성이 존재합니다. 2. 읽기-쓰기 쓰기 스레드가 버퍼를 갱신하느 동안 읽기 스레드가 ..

[Clean Code] 13장 동시성(1)

깨끗한 코드를 작성하기 위한 열세번째 기록 동시성이 필요한 이유 동시성은 결합을 없애는 전략입니다. 즉, 무엇과 언제를 분리하는 전략입니다. 무엇과 언제를 분리하면 애플리케이션 구조와 효율이 극적으로 나아집니다. 예시1) 서블릿 모델을 살펴보면 웹 혹은 EJB 컨테이너라는 우산 아래서 돌아가는데 컨테이너 들은 동시성을 부분적으로 관리합니다. 웹 요청이 들어올 때 마다 웹 서버는 비동기식으로 서블릿을 실행합니다. 그래서 서블릿 프로그래머는 들어오는 모든 웹 요청을 관리하지 않습니다. 예시2) 매일 수많은 웹 사이트에서 정보를 가져와 요약하는 정보 수집기를 봤을 때 단일 스레드 프로그램이라면, 수집하는데 많은 시간이 소요될 것입니다. 단일 스레드 수집기는 웹 소켓에서 입출력을 기다리는 시간이 아주 많기 때문..

[Clean Code] 12장 창발성

깨끗한 코드를 작성하기 위한 열두번째 기록 창발적 하위계층(구성 요소)에는 없는 특성이나 행동이 상위계층(전체 구조)에서 자발적으로 돌연히 출현하는 현상을 창발성 [동아사이언스 기사 참조] 창발적 설계로 깔끔한 코드를 구현하자 1) 우수한 설계, 2) 쉬운 코드 구조와 설계 파악, 3) 쉬운 SRP, DIP 적용, 4) 우수한 설계의 창발성 촉진을 위해 4가지 규칙만 따르면 된다고 말합니다. 아래에서 4가지 규칙을 중요도 순으로 소개해드리겠습니다. 모든 테스트를 실행합니다. 중복을 없앱니다. 프로그래머 의도를 표현합니다. 클래스와 메서드 수를 최소로 줄입니다. 모든 테스트를 실행합니다. 검증을 위해서는 모든 테스트를 통과해야 합니다. 그렇기 때문에 테스트가 가능한 시스템을 만드는 것은 중요합니다. 검증이..

[Clean Code] 11장 시스템

깨끗한 코드를 작성하기 위한 열한번째 기록 깨끗한 코드를 구현하면 낮은 추상화 수준에서 관심사를 분리하기 쉬워집니다. 이 장에서는 높은 추상화 수준, 즉 시스템 수준에서도 개끗함을 유지하는 방법을 살펴보겠습니다. 시스템 제작과 시스템 사용을 분리하라 소프트웨어 시스템은 애플리케이션 객체를 제작하고 의존성을 서로 '연결' 하는 준비과정, 준비 과정 이후에 이어지는 런타임 로직을 분리해야 합니다. 관심사 분리는 가장 중요한 설계 기법 중 하나로, 많은 사람들은 이 부분을 놓치고 있습니다. public Service getService(){ if(service == null) service = new MyServiceImpl(); return service; } 다음 코드는 초기화 지연, 또는 계산 지연이라는..

[Clean Code] 10장 클래스

깨끗한 코드를 작성하기 위한 열번째 기록 클래스 체계 클래스의 구성은 가장 먼저 변수 목록이 나오고, 정적 공개(static public) 상수, 그리고 정적 비공개(static private) 변수, 그리고 비공개 인스턴스가 나옵니다. 변수 목록 다음에는 공개 함수가 나온다. 비공개 함수는 자신을 호출하는 공개 함수 직후에 넣는다. 즉 추상화 단계가 순차적으로 내려간다. 캡슐화 변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫지만 반드시 숨겨야 한다는 법칙도 없다. 때로는 변수나 유틸리티 함수를 protected로 선언해 테스트 코드에 접근을 허용하기도 한다. 하지만 테스트 코드는 중요하기 때문에 같은 패키지 안에서 함수를 호출하거나 변수를 사용해야 한다면 비공개 상태를 유지할 방법을 찾아야 한다...

[Clean Code] 9장 단위 테스트

깨끗한 코드를 작성하기 위한 아홉번째 기록 TDD 법칙 세 가지 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. 위와 같은 법칙을 따른다면 코드를 한줄 작성할 때 마다 테스트 코드가 생길 것입니다. 그렇게 되면 실제 코드 보다도 더 많은 테스트 코드가 생길 것입니다. 이는 심각한 문제를 유발하기도 하기 때문에 신중하게 테스트 코드를 짜야합니다. 깨끗한 테스트 코드 유지하기 책에서 한 이야기가 나옵니다. 급하게 프로젝트를 완성해야 했기 때문에 지저분하지만 빠르게 테스트 코드를 작성한 이야기. 여러분도 예상하셨겠지만 지저분한 테스트는 테스트를 안 하는..

[Clean Code] 8장 경계

깨끗한 코드를 작성하기 위한 여덟번째 기록 외부 코드 사용하기 java.util.Map을 살펴보면 Map은 다양한 인터페이스로 수많은 기능을 제공합니다. Map이 제공하는 기능성과 유연성은 확실히 유용하지만 그만큼 위험도 큽니다. 프로그램에서 Map을 만들어 여기저기 넘긴다고 했을 때 Map 이 제공하는 clear() 메서드를 통해 누구나 Map의 내용을 지울 수 있게 되기 때문입니다. Map과 같은 경계 인터페이스를 이용할 때는 클래스나 클래스 계열 밖으로 노출되지 않도록 주의해야 합니다. Map 인스턴스를 공개 API의 인수로 넘기거나 반환값으로 사용하지 않습니다. 아직 존재하지 않는 코드를 사용하기 팀 작업에서 다른 팀이 API를 설계하지 않았을 때, 구현을 미루고 자체적으로 필요한 인터페이스를 정..

[Clean Code] 7장 오류 처리

깨끗한 코드를 작성하기 위한 일곱번째 기록 오류 처리는 중요합니다. 하지만 오류 처리 코드로 인해 프로그램 논리를 이해하기 어려워진다면 깨끗한 코드라고 부르기 어렵습니다. 그렇다면 우아하고 고상하게 오류를 처리하는 기법과 고려 사항 몇 가지를 알아보겠습니다. 오류 코드보다 예외를 사용하라 함수를 호출한 즉시 오류를 확인해야 하기 때문에 오류가 발생했을 때 예외를 던지는 편이 낫습니다. 그렇게 하게 되면 논리와, 오류 처리 코드가 섞이지 않아 깨끗한 코드가 됩니다. Try-Catch-Finally 문부터 작성하라 Try 블록에 들어가는 코드를 실행하면 어느 시점에서든 실행이 중단된 후 Catch 블록으로 넘어갈 수 있습니다. 어떤 면에서 Try 블록은 트랜잭션과 비슷합니다. Catch 블록은 Try 블록에..

[Clean Code] 6장 객체와 자료 구조

깨끗한 코드를 작성하기 위한 여섯번째 기록 자료 추상화 구현을 감추기 위해서 추상화가 필요합니다. 그저 조회 함수와 설정함수로 변수를 다룬다고 클래스가 되지 않습니다. 추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 의미의 클래스이다. 개발자는 객체가 포함하는 자료를 표현할 가장 좋은 방법을 심각하게 고민해야 한다. 아무 생각 없이 조회/설정 함수를 추가하는 방법이 가장 나쁘다. 자료/객체 비대칭 객체는 추상화 뒤로 자료를 숨긴 채 자료를 다루는 함수만 공개한다. 자료 구조는 자료를 그대로 공개하며 별다른 함수는 제공하지 않는다. 객체 지향 코드에서 어려운 변경은 절차적인 코드에서 쉬우며, 절차적인 코드에서 어려운 변경은 객체 지향 코드에서 쉽다. 분별 있는 프로..

[Clean Code] 5장 형식 맞추기

깨끗한 코드를 작성하기 위한 다섯번째 기록 형식을 맞추는 목적 코드 형식은 중요하다! 너무 중요해서 무시하기 어렵다. 코드형식은 의사소통의 일환이다. 오늘 구현한 기능이 다음 버전에서 바뀔 확률은 아주 높다. 하지만 오늘 구현한 코드의 가독성은 앞으로 바뀔 코드의 품질에 지대한 영향을 미친다. 가독성 수준은 유지보수 용이성과 확장성에 계속 영향을 미친다. 적절한 행 길이를 유지하라 다양한 프로젝트를 본 결과, 500줄이 넘지 않고, 대부분 200줄 정도인 파일로도 커다란 시스템을 구축할 수 있다는 사실! 반드시 지킬 엄격한 규칙은 아니지만 바람직한 규칙으로 삼으면 좋다. 일반적으로 큰 파일보다 작은 파일이 이해하기 쉽다. 신문 기사처럼 작성하라 소스 코드도 신문 기사처럼 이름은 간단하면서도 설명이 가능하..

728x90
반응형