배워가는블로거

CleanCode - 동시성 동시성이 필요한 이유? 동시성은 '무엇'과 '언제'를 분리하는 전략입니다. '무엇'과 '언제'를 분리하면 애플리케이션 구조와 효율이 극적으로 나아집니다. 동시성에 대한 일반적인 오해 동시성은 항상 성능을 높여준다. 여러 스레드가 프로세서를 공유하거나, 여로 프로세서가 동시에 처리할 계산이 충분히 많은 경우 성능이 높아집니다. 위 경우 같을 때 성능을 높여줍니다. 항상은 아닙니다. 동시성을 구현해도 설계는 변하지 않는다. 단일 스레드와 다중 스레드 시스템은 설계가 다릅니다. 웹 또는 EJB 컨테이너를 사용하면 동시성을 이해할 필요가 없다. 반드시 이해해야 데드락, 동시 수정등의 문제를 피할 수 있습니다. 동시성 방어 원칙 단일 책임 원칙 주어진 메서드/클래스/컴포넌트를 변경할 ..

CleanCode - 창발성 창발적 설계로 깔끔한 코드를 구현하자. 여기서 창발성이란 무슨 뜻일까요? 보통 자주쓰는 단어는 아닙니다. 사전에 따르면 창발성이란 하위 계층(구성 요소)에는 없는 특성이나 행동이 상위 계층(전체 구조)에서 자발적으로 돌연히 출현하는 현상이라고 합니다. 책에서는 켄트 벡이 제시한 단순한 설계 규칙 네 가지가 소프트웨어 설계 품질을 크게 높여준다고 합니다. 이는 다음과 같습니다. - 모든 테스트를 실행한다. - 중복을 없앤다. - 프로그래머의 의도를 표현한다 - 클래스와 메서드 수를 최소로 줄인다. 1. 모든 테스트를 실행한다. 무엇보다 먼저 설계는 의도한대로 돌아가는 시스템을 내놓아야 합니다. 문서로는 잘 설계했지만, 의도한 대로 시스템이 동작하는지 검증할 방법이 없다면 인정받..

CleanCode - 시스템 이 장에서는 사용과 제작이 다르다는 사실을 명심하는 것부터 시작됩니다. 사용과 제작을 분리하는 메커니즘 하나가 의존성 주입(DI)입니다. DI는 제어의 역전(IoC)기법을 의존성 관리에 적용한 메커니즘입니다. IoC에서는 한 객체가 맡은 보조 책임을 새로운 객체에게 전적으로 떠넘깁니다. 새로운 객체는 넘겨받은 책임만 맡으므로 단일책임원칙을 지키게됩니다. 호출하는 객체는 실제로 반환되는 객체의 유형을 제어하지 않습니다. 대신 의존성을 능동적으로 해결합니다. 확장 '처음부터 올바르게' 시스템을 만들 수 있다는 믿음은 미신이라고 합니다. (말이 안됩니다!) 그래서 우리는 오늘 주어진 사용자 스토리에 맞춰 시스템을 구현해야 합니다. 그리고 내일은 새로운 스토리에 맞춰 시스템을 조정하..

CleanCode - 클래스 클래스를 정의하는 표준 자바 관례에 따르면, 가장 먼저 변수 목록이 나옵니다. 변수 목록 다음에는 공개 함수가 나옵니다. 그리고 그 이후에는 비공개 함수가 나옵니다. 즉, 추상화 단계가 순차적으로 내려갑니다. 클래스를 만들 때 첫 번째 규칙은 크기입니다. 클래스가 작아야 좋다고 책에서는 강조를 하고 있습니다. 크기를 줄이는 방법 중 중요한 것은 바로 '작명' 입니다. 클래스 이름은 해당 클래스 책임을 기술해야 합니다. 명확히 해당 클래스의 책임을 기술한다면 클래스의 크기를 줄이는데 많은 도움이 됩니다. (하지만 작명이 가장 어려운 것 같습니다!) 그 다음은 SRP (Single Responsibility Principle). 단일 책임 원칙에 대해 설명합니다. SRP는 클래스..

CleanCode - 단위 테스트 이 장에서는 TDD에 대해 간단히 소개하고 있습니다. 책에서 알려주는 TDD 법칙 세 가지가 있는데, 다음과 같습니다. - 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. - 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. - 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. 하지만 단순히 이렇게 일하면 실제 코드와 맞먹을 정도의 방대한 테스트 코드가 생기며, 관리 문제를 유발하기도 합니다. 그래서 깨끗한 테스트코드 관리가 필요합니다. 테스트 코드는 실제 코드 못지 않게 중요합니다. 그러므로 실제 코드처럼 깨끗하게 짜야 합니다. 테스트는 유연성, 유지보수성, 재사용성을 제공합니다. 깨끗한 테스트는 다음 규칙을 ..

CleanCode - 경계 시스템에 들어가는 모든 소프트웨어를 직접 개발하는 경우는 거의 없습니다. 때로는 패키지를 사고, 때로는 오픈 소스를 쓰며, 때로는 다른 부서에서 만든 컴포넌트를 쓰며 개발합니다. 이렇듯 외부 코드를 사용하는 경우가 많은데, 이 외부 코드를 우리 코드에 깔끔하게 적용시켜야 합니다. 책에서는 이러한 경계를 깔끔하게 처리하는 방법을 안내해주고 있습니다. 예시로 java.util.Map 클래스가 등장합니다. Map은 굉장히 다양한 인터페이스로 수 많은 기능을 제공하고 있습니다. ex) clear(), remove(Object key), put(Object key, Object value)... Map을 단순히 반환하면 사용자가 불필요한 기능까지 전달하거나 변환의 책임까지 전가합니다. ..

CleanCode - 오류 처리 오류 처리는 프로그래밍에 반드시 필요한 요소 중 하나입니다. 오류가 발생할 가능성은 항상 존재합니다. 그러므로 오류를 없애는 것 만큼 오류를 빠르게 바로 잡는 것이 더 중요합니다. 책에서는 오류 코드보다 예외를 사용하는 것을 권장하고 있습니다. 즉, 쉽게 말해 Try-Catch-Finally 문을 활용하여 예외를 사용하는 것을 추천합니다. 이는 앞서 3장에서도 언급한 내용이었습니다. 그리고 다른 것보다 중요한 내용은 null을 반환하지 마라는 내용입니다. 책에서는 null을 반환하드 코드는 나쁜 코드로 정의하고 있습니다. 이는 일거리를 늘릴 뿐 아니라 호출자에게 문제를 떠넘기는 코드라고 합니다. null을 반환한다면 호출자는 모든 곳에서 null 확인을 해야 합니다. 그래..

CleanCode - 객체와 자료 구조 책에서 정의하는 객체와 자료 구조의 정의부터 알아보겠습니다. 객체 : 추상화 뒤로 자료를 숨긴 채 자료를 다루는 함수만 공개한다. 자료구조 : 자료를 그대로 공개하며 별다른 함수를 제공하지 않는다. 객체와 자료구조는 근본적으로 양분됩니다. 아래 2가지 문장이 그 예시인데, 모두 참인 문장입니다. '절차적인 코드는 기존 자료 구조를 변경하지 않으면서 새 함수를 추가하기 쉽다. 반면 객체 지향 코드는 기존 함수를 변경하지 않으면서 새 클래스를 추가히기 쉽다.' '절차적인 코드는 새로운 자료구조를 추가하기 어렵다. 객체 지향 코드는 새로운 함수를 추가하기 어렵다.' 객체와 자료구조는 각각 적합한 경우가 있습니다. 새로운 함수가 아니라 새로운 자료 타입이 필요한 경우 -..

CleanCode - 형식 맞추기 프로그래머라면 형식을 깔끔하게 맞춰 코드를 짜야 합니다. 코드 형식을 맞추기 위한 규칙을 정하고, 그 규칙을 따라야합니다. (팀이라면 팀 모두가 합의하여 함께 정하자) '코드 형식은 매우 중요하다' 코드 형식은 의사소통의 일환입니다. 그리고 가독성은 앞으로 유지보수하는 코드의 품질에 많은 영향을 끼친다. 책에서 원활한 소통을 장려하는 코드 형식이 몇 가지 있는데, 그 중 4가지만 정리해보겠습니다. 1. 적절한 행 길이를 유지하라. 하나의 파일에 모든 내용을 담는 것 보다 작은 파일로 잘 유지하는 것이 좋습니다. 책의 예제에서는 대다수 프로젝트의 파일이 500줄을 넘지 않고도 큰 프로젝트를 유지할 수 있다는 사실을 말하고 있습니다.. 엄격한 규칙이 아니지만 지키면 좋습니다..

CleanCode - 주석 잘 달린 주석은 그 어떤 정보보다 유용합니다. 하지만 책에서는 주석에 대해 부정적으로 표현하는 것 같습니다. 보통 주석을 아래와 같이 표현합니다. - 경솔하고 근거없는 주석은 코드를 이해하기 더 어렵게 만든다. - 부정확한 주석은 아예 없는 주석보다 훨씬 더 나쁘다. 이렇게 생각하는 이유는 주석은 나쁜 코드를 보완하지 못한다고 생각하기 때문입니다. 일반적으로 주석을 추가하는 이유는 코드 품질이 나쁘기 때문이라고 합니다. 자신이 저지른 안 좋은 코드를 감추기 위해 보통 주석을 단다고 합니다. 그리고 그렇게 주석을 다는 대신 코드를 다시 잘 짜는데 시간을 보내라고 팩트를 말합니다. '주석 대신 코드로 의도를 표현하라. 잘 짜여진 코드와 함수명이면 충분하다.' 책에서 말하는 몇 가지..