CleanCode

Robert C. Martin

P.S. 클린코드 책에 대한 많은 사람들의 우려를 잘 알고 있습니다. 해서 맹신 하지 않고, 저자의 의도를 비판적으로 바라보려고 노력하고 있습니다.! 맹신하게 된다면 빠르게 변하는 개발 업계에서 잘못된 방식의 접근이 될 수도 있는 책인 것 같습니다. 그러나 저자의 의도를 더 깊게 받아들인다면 스택이 변하여도 가치가 변치 않을 수 있는 책이라고 생각합니다.

내가 그의 이름을 불러주었을 때

그는 나에게 와서 꽃이 되었습니다.
결국 애매모호한 표현과 이름을 피해야 된다는 것입니다. 단순하지만 모든 것을 품을 수 있는 것들이어야 합니다. 글쓰기와 동일합니다. 나만 읽을 수 있거나 읽기 복잡하고 어려운 배려 없는 글은 훌륭한 글이 아니 듯이 코드도 동일합니다. 내가 어떻게 불러 주는지가 대상을 더 배려심 있고, 사랑스러운 존재로 만듭니다.

함수는 쪼개고, 분리해야 한다

소설과 같은 문학에서는 긴 문장의 글을 선호하기도 합니다. 더 깊은 묘사가 가능하기 때문입니다. 그러나 개발자에게 필요한 것은 리포트와 논문과도 같은 명백하고, 읽기 쉬운 글입니다. 한 문장이 2줄을 넘어가지 않는 그런 문장 말입니다.
함수(메서드)는 간결하고, 짧아야 됩니다. 길다면 너무 많은 것을 담고 있는 것일지도 모릅니다. 때로는 함수에 클래스에 담겨야 할 명사적인 큰 존재를 담으려고 해서 넘칠 수도 있습니다. 함수(메서드)는 동사입니다. 동사는 하나의 동작만을 표현하는 것이 좋습니다.

주석은 쓰레기일 수도 있다.

주석이 분명 필요할 때도 있습니다. 그러나 필요악입니다. 없앨 수 있다면 여러 방법을 동원해 우회 해야 됩니다. 주석과 코드는 서로 독립된 존재입니다. 코드 수정 후 주석도 수정할 것이라는 생각은 오만입니다. 또한 필요해 보이는 주석도 이제는 VCS의 기능들이 처리해줍니다. 그러므로 주석은 최소화 되어야 됩니다.
(내가 주석을 쓰지 않아도 될 정도로 코드를 짤 수 있는지 물어봐야 될 것입니다. 주석을 줄일 수 있을 정도로 명명백백한 코드를 짜기 위해 노력해야 된다는 의미에 더 가깝지 않을까?)

구조가 잘 짜여진

건물과 같은 구조물은 아름답고, 단순하다. 보기 좋고, 이해하기 편하다는 의미입니다. 코드도 그래야 합니다. 괄호와 띄어쓰기, 메서드의 위치들이 사람의 직관을 관통할 수 있어야 된다. 잘 짜여진 구조의 코드는 스크롤을 줄이고 이해하기 위해 소모되어질 시간을 아껴줍니다.

• 2 + 2 와 2$*$ 2의 차이를 느낄 것

오류처리와 논리의 분리

예외처리를 통해 논리코드와 오류처리 코드를 분리 할 수 있습니다. 이는 코드를 간결하게 해줍니다. 뿐만 아니라 정확한 예외처리는 프로그램 자체의 안정성까지 책임져줍니다. 잘쓸 글 = 잘쓴 코드였던 위의 내용과 일관되지만 예외처리는 좀 더 기술적인 방법들이 중요하게 부각됩니다..
아래는 예외처리 방법들입니다.

• 오류코드가 아닌 예외처리를 사용합니다.
• Try-Catch-Finally문을 먼저 작성하여 구조를 세웁니다.
• unchecked 예외를 사용합니다. (C++, C#에는 checked예외가 없으나 잘 작동한다. 아주 중요한 라이브러리를 작성할 떄만 checked 예외를 사용하도록 한다.)
• 오류를 정의하는 것이 아닌 오류를 잡아내는 것이 목표가 되어야 합니다. 죽, 문제재기를 넘어 전후 상황과 해결책을 제시해야 합니다.
• Wrapper 클래스를 사용하여 오류를 분류해줍니다.
• 특수 사례 패턴: try-catch로 예외를 잡아 작동하는 코드는 상위 비즈니스 코드에서 처리합니다.
• 코드를 모호하게 만드는 Null을 반환하기보다는 빈 Collection과 같은 의미 있는 값을 반환하며 좋습니다. 예를 들어 Assert [조건문] : ["메시지"] 문을 사용하여 전달된 Null을 처리합니다.

외부소스의 내부화

외부소스는 다른 사람과 기관이 만든 코드를 말합니다. 그래서 내부에서 사용할 방식에는 딱 들어맞지 않기 마련입니다. 그래서 Wrapper로 감싸거나 Adaptor를 사용하여 내부화 해야 됩니다.

• 학습테스트(TDD)를 활용하여 외부 API를 적용할 것을 추천합니다. 기록된 테스트들은 다른 외부 API로 변경하거나 사용하던 API가 업데이트 되었을 때 신속하고 안전하게 반영하도록 해줍니다.
• Adaptor 패턴을 사용할 경우, 아직 구현되지 않은 API에 맞는 내부 코드를 미리 만들 수 있습니다. 구현되지 않았더라도 외부 API가 전달해줄 값의 의미는 유출 할 수 있습니다. 이를 근거로 하여 전면에는 Adaptor 인터페이스를 두고 FakeAdaptor를 임시로 구현하여 코드를 짤 수 있습니다.

TDD

TDD는 한 문단으로 요약할 수 없는 또 하나의 개념과 프레임워크 규모의 내용입니다. 이 장을 읽고 요약하기 위해 키보드를 두들기기보다는 TDD관련 책을 읽는 것이 맞을 것 같습니다.

유연한 클래스는 단순한 클래스이다

단일 책임 원칙(SRP)에 의해서 클래스는 변경해야 할 이유가 단 하나여야 한다고 말합니다. 하나보다 많다면 클래스가 너무 커졌기 때문입니다. 하나의 책임만을 갖는 클래스는 단순하기에 변경이 용이해집니다. 또한, 추상 클래스와 인터페이스를 활용하여 의존성 역전 원칙(DIP)을 적용하면 외부의 변화로부터 유연한 코드를 만들 수 있습니다.

시스템 : 작성 중

창발성 : 작성 중

신은 디테일 속에 있다. 동시성

컴퓨터는 거짓말 할일이 없지만 거짓말한다고 느껴질 떄가 있습니다. 바로 동시성이 꺠졌을 때 입니다. 동시성 방어 원칙이라 할 수 있는 기본적으로 지켜볼 수 있는 동시성 문제를 해결 할 수 있을 것이 입니다. 그러나 스레드는 매우 섬세하고, 예민합니다. 그렇기 떄문에 더 근본적으로 깊게 스레드를 이해하는 방법 밖에 없습니다. TDD에서도 그랬 듯이 동시성 또한 책 몇권은 읽어야 되는 부분입니다.

동시성 방어 원칙

• SRP - 동시성 코드와 일반 코드를 분리
• Corollary (따름 정리)
  - 자료를 제한하라: 자료를 캡슐화하고, 공유 자료를 최대한 줄인다.
  - 자료 사본을 사용하라: 자료를 복사해 읽기전용으로 사용 <- 사용된 해결책
  - 스레드는 가능한 독립적으로 구현히리: 쓰레드 간 동기화를 최소화한다.

점진적 개선 : 작성중

JUnit 들여다보기 : 작성중

냄새와 휴리스틱 : 작성중

동시성2 : 작성중