IT 도서/Clean Code

Clean Code를 읽고 내용을 정리한 것입니다. 책 구매하러 가기 동시성 객체는 처리의 추상화다. 스레드는 일정의 추상화다. 동시성과 깔끔한 코드는 양립하기 어렵다. 단일 스레드 프로그래밍은 상대적으로 쉬운 편에 속한다. 다중 스레드 코드도 맘만 먹으면 코드를 쉽게 작성할 수 있다. 하지만 쉽게 작성한 다중 스레드 코드는 시스템의 부하가 큰 환경에서 코드 내부 깊숙한 곳부터 발생한 문제가 있을 수 있다. 동시성의 필요성 동시성은 무엇과 언제를 분리하는 전략이다. 단일 스레드 프로그램을 생각해보자. Breakpoint를 걸어놓기만 하면 언제 무엇을 하는지 명확하게 잡아낼 수 있다. 무엇과 언제를 분리하면 프로그램 구조와 효율이 극적으로 나아진다. 구조적인 관점에선 거대한 루프 하나가 아니라 작은 단위의..

Clean Code를 읽고 내용을 정리한 것입니다. 책 구매하러 가기 창발성 (創發性) 하위 체계로부터 생겨나지만, 그 하위 체계로 환원되지 않는 속성 하위 계층(구성 요소)에는 없는 특성이나 행동이 상위 계층(전체 구조)에서 자발적으로 돌연히 출현하는 현상 조직(organization)의 일정수준에서 실체에 속한 성질은 그보다 낮은 차원에서 발견된 성질로부터는 예견할 수 없다는 것 즉, 하위 요소를 잘 결합하여 전혀 다른 결과를 얻어 내는 것을 말한다. SW 설계 품질을 높여주는 켄트 벡의 단순한 설계 규칙 4가지 (중요도 순) 모든 테스트 실행 중복 제거 개발자의 의도를 표현 클래스/메소드의 수를 최소한으로 모든 테스트 실행하기 SW 설계는 개발자의 의도가 담겨있다. 테스트를 거친 시스템은 개발자의 ..

Clean Code를 읽고 내용을 정리한 것입니다. 책 구매하러 가기 시스템 복잡성은 죽음이다. 개발자에게서 생기를 앗아가며, 제품을 계획하고 제작하고 테스트하기 어렵게 만든다. By Ray Ozzie (Microsoft CTO) 도시 현대의 도시는 온갖 세세한 사항들을 나누어서 맡는 식으로 관리되고 있다. 수도 관리 (수도공사) 치안 관리 (경찰) 재난 (소방서) 전기 관리 (한전) ... etc 도시를 소스코드로 작성한다고 하면 도시를 구성하는 세부 사항들이 추상화/모듈화된 것으로 볼 수 있다. 큰 그림을 이해하지 못해도 작은 단위의 기능들은 잘 동작하기 때문에 효율적인 것이다. 관심사 분리 살펴보고자 하는 관심사는 시작 단계이다. public class Singleton { public static..

Clean Code를 읽고 내용을 정리한 것입니다. 책 구매하러 가기 클래스 클래스 구성 자바 표준은 클래스를 아래의 순서대로 구성하라고 권고하고 있다. static public 상수 static private 변수 private 변수 자바에서 비정적 public 변수가 필요한 일은 거의 없다. public method private method는 호출하는 public method 함수 뒤에 넣는다. 추상화 단계를 순차적으로 내려가도록 지키면 신문 기사처럼 가독성이 좋은 코드를 작성할 수 있다. 클래스의 크기 클래스는 작아야 한다. 메소드는 줄 수로 크기를 측정하지만 클래스는 맡은 책임의 개수로 크기를 측정한다. 클래스의 책임에 관련된 이야기는 [OOP 5대 원칙] 관련 내용을 찾아보자. public c..

Clean Code를 읽고 내용을 정리한 것입니다. 책 구매하러 가기 단위 테스트 TDD의 법칙 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. 위의 규칙을 따르면 매일 굉장히 많은 테스트 코드가 산출물로 작성될 것이다. SW 오류를 조금 더 정확하게 짚어낼 수 있겠지만 방대한 테스트 코드는 관리 문제를 유발하기도 한다. 깨끗한 테스트 코드 유지하기 지저분한 테스트 코드는 없는 것보다 못할 수도 있다. 테스트 코드가 굉장히 많이 작성되어 있는데 SW의 스펙이 변경된다면 실제 코드도 변경해야 한다. 실제 코드가 변경되면 테스트 코드는 반드시 같이 변..

Clean Code를 읽고 내용을 정리한 것입니다. 책 구매하러 가기 주석 코드를 표현하는 대표적인 수단 너무 과신하진 말자. 주석은 오래될수록 코드에서 멀어지며 전혀 다른 의미를 갖게될 수 있다. 주석은 나쁜 코드를 보완하지 못한다. 주석을 추가하는 일반적인 이유는 명백하다. 코드 품질이 나쁘기 때문이다. 주석을 달기보다는 깔끔한 코드를 작성하기 위해 노력하자. 코드에 의도를 담아보자 대다수의 코드에는 개발자의 의도를 충분히 담을 수 있다. // 1) if (employee.flags & DEV_FLAG) { // Do something... } // 2) if (employee.isDeveloper()) { // Do something... } 위의 코드에서 1과 2 중 어느 코드에 개발자의 의도가 ..

Clean Code를 읽고 내용을 정리한 것입니다. 책 구매하러 가기 1. 작게 만들어라 함수는 100줄을 넘기지 마라. 만약 100줄이 넘어가는 함수가 있다면 따로 함수로 분리하라. 그래야 읽고 이해하기 쉬워진다. 2. 한 가지만 해라. 아래의 함수는 몇 가지를 수행하는 것일까? 1) 페이지가 테스트 페이지인지 판단한다. 2) 맞다면 설정 페이지/해제 페이지를 넣는다. 3) 페이지를 렌더링한다. 함수 이름 아래에서 추상화 수준이 한 단계인 행위를 수행하면 한 가지 동작을 하는 것이다. 한 가지의 개념을 추상화 수준에서 생각하고 일관되게 작성하도록 한다. 3. 서술적인 이름을 사용하라. 함수 이름을 보고 짐작한 동작이 그대로 작동하는 이름이 좋다. ex) isTestable, setup 4. 함수 매개변..

Clean Code를 읽고 내용을 정리한 것입니다. 책 구매하러 가기 1. 의도를 분명히 밝혀라 boolean flag; // 무슨 의미? boolean isDarkMode; boolean isLightMode; flag라는 이름엔 아무 의미가 담겨있지 않다. isDarkMode / isLightMode처럼 의도가 드러나는 이름을 사용해야 코드 이해와 변경이 쉽다. 2. 그릇된 정보를 피하라 1) 개발자에게 List는 자료구조를 의미한다. 실제로 List가 아닌 것들은 List라는 의미를 붙이지 않는 편이 좋다. 2) 흡사한 이름을 사용하지 않는다. 일관성이 떨어지는 표기법은 오해를 낳는다. List/Queue 등 자료구조나 기술을 의미하는 단어는 개발자에게 친숙하다. 실제로 대중적인 기술명을 변수 이름..