클린코드

개발자라면 모두 나쁜 코드를 짠 적이 있고, 나쁜 코드로 인해 고생한 경험이 있을 것이다.제대로 짤 시간이 없다고 생각해서다른 업무가 밀려 빨리 해치우려고그리고 나중에 다시 수정하자고 다짐해도, 나중은 결코 오지 않는다.나쁜 코드는 개발 속도를 크게 떨어뜨린다. 얽히고

의미 있는 이름 소프트웨어에서 이름은 어디에나 쓰이므로, 이름을 잘 지으면 여러모로 편하다. ex) 변수, 함수, 클래스, 패키지, 소스 파일, 디렉터리, jar파일, war 파일 의도를 밝혀야 한다. 변수, 함수, 클래스 이름은 다음 질문에 모두 답해야 한다.

함수를 만드는 규칙 > 함수는 그 언어에서 동사며, 클래스는 명사다. > 시스템에서 발생하는 모든 동작을 설명하는 함수 계층 즉, 시스템이라는 이야기를 풀어가는 데 목표를 두어야 한다. 작게 만들어라 함수의 길이 함수는 2~4줄 정도가 좋다. 최대 100줄은 넘어서면 안된다. 블록과 들여쓰기 If-else문, while 문 등에 들어가는 ...

주석을 다는 이유 주석은 코드로 의도를 표현하지 못해 사용하는 것이다. 주석은 오래될 수록 코드에서 멀어지며, 완전히 그릇될 가능성도 커진다. 주석이 코드의 변화를 딸라가지 못한다. 주석은 나쁜 코드를 보완하지 못한다. 주석을 다는 것이 아니라, 코드를 정리해야 한다.

형식을 맞추는 목적 코드 형식은 의사소통의 일환이다. 맨 처음 잡아 놓은 구현 스타일과 가독성 수준은 유지보수 용이성과 확장성에 계속 영향을 미친다. 따라서 코드 형식을 맞추기 위한 간단한 규칙을 정하고 그 규칙을 따라야 한다. 코드 형식 적절한 행의 길이를 유지 자바

들어가기 전에 변수와 조회/설정 함수 변수를 비공개(private)으로 정의하는 이유는 남들이 변수에 의존하지 않게 만들고 싶어서 이다. 그렇지만 조회(get) 함수와 설정(set) 함수를 제공한다면, 구현을 외부로 노출하는 셈이다. 객체와 자료구조 객체는 동작을 공개

클린 코드와 오류 처리의 연관성 상당수 코드 기반은 전적으로 오류 처리 코드에 좌우된다. 여기저기 흩어진 오류 처리 코드 때문에 실제 코드가 하는 일을 파악하기 힘들다. 오류 처리 코드로 인해 프로그램 논리를 이해하기 어려워진다면, 깨끗한 코드라 부르기 어렵다. 깨끗한

들어가기 전에 개발을 하다 보면 외부 코드를 사용하는 일이 많은데, 이러한 외부 코드는 우리 코드에 깔끔하게 통합해야만 한다. 이 장에서는 소프트웨어 경계를 깔끔하게 처리하는 기법과 기교를 살펴보도록 한다. 외부 코드 사용하기 긴장으로 인한 시스템 경계의 문제 인터

TDD TDD 법칙 세 가지 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. 방대한 테스트 코드의 문제 위 법

클래스 체계 표준 자바 관례에 따르면 가장 먼저 변수 목록이 나와야 한다. 1) public static 상수 2) private static 변수 3) 비공개 인스턴스 변수 4) 공개 변수 공개 변수가 필요한 경우는 거의 없다. 그 다음으로 함수가 나와야 한다. 1)

깨끗한 시스템 높은 추상화 수준, 즉 시스템 수준에서도 깨끗함을 유지하는 방법을 살펴본다. 깨끗하지 못한 아키텍처 깨끗하지 못한 아키텍처는 도메인 논리를 흐리며 기민성을 떨어뜨린다. 도메인 논리가 흐려지면 제품 품질이 떨어진다. 버그가 숨어들기 쉬워지고 스토리를 구현

하위 계층(구성 요소)에는 없는 특성이나 행동이 상위 계층(전체 구조)에서 자발적으로 돌연히 출현하는 현상위키백과착실하게 다르기만 하면 우수한 설계가 나오는 간단한 규칙 네 가지가 있다.서적에서는 위와 같은 규칙을 소개하고 있다. 창발이란 단어의 사전적 의미와 함께 보

이 장의 주제 여러 스레드를 동시에 돌리는 이유 여러 스레드를 동시에 돌리는 어려움과 이에 대처하고 깨끗한 코드를 작성하는 방법 동시성을 테스트하는 방법과 문제점 동시성에 관하여 동시성은 결합을 없애는 전략이다. 즉, 무엇(What)과 언제(When)를 분리하는 전략이

이 장의 주제 모듈을 개선하고 정리하는 내용이어서, 모든 내용을 정리하지 않고 필요한 부분만 체크하여 정리할 것이다. 점진적인 개선을 보여주는 사례 연구이다. 출발은 좋았으나 확장성이 부족했던 모듈을 제시하고, 해당 모듈을 개선하고 정리하는 단계를 정리했다. 개선 깨

이 장의 주제 > 세상에 개선이 불필요한 모듈은 없다. > 자바 프레임워크 중 가장 유명한 JUnit에서 가져온 코드를 평가한다. 일반적인 프레임워크가 그렇듯 개념은 단순하며 정의는 정밀하고 구현은 우아하다. JUnit 프레임워크 살펴볼 모듈 ComparisonCompactor 모듈 > 코드 출처: https://github.com/junit-t...

이 장의 주제 > 부록의 코드와 함께 보면서 설명하는 챕터다. > > 책의 흐름을 따라가며 리팩토링 시 신경써야 할 것 같은 부분들만 일부 정리해봤다. JCommon 라이브러리에서 org.jfree.date 패키지의 SerialDate라는 클래스를 탐험한다. 라이브러리 사이트: https://www.jfree.org/jcommon/index.ht...

이 장의 주제 마틴 파울러의 『Refactoring』에서 거론된 다양한 ‘코드 냄새’와 저자가 추가한 냄새들의 목록이다. 저자가 코드를 짜면서 사용하는 기교와 휴리스틱도 포함한다. 해당 목록은 다양한 프로그램을 검토하고 리팩터링하면서 만들었다. 결론 이 장에서 소

클라이언트/서버 예제 서버는 소켓을 열어 놓고 클라이언트가 연결하기를 기다린다. 연결을 기다리다, 들어오는 메시지를 처리한 후, 다음 클라이언트 요청을 기다린다. 클라이언트는 소켓에 연결해 요청을 보낸다. 서버가 열어 놓은 소켓에 메시지를 전송하고, 응답 메시지를 받는