CleanCode

2장 2장에서는 의미있는 이름에 대해서 다룬다. 우리는 변수, 함수, 인수, 클래스, 패키지, 소스파일, 디렉토리, war, jar 등 많은 곳에 이름을 붙인다. 이름을 잘 지으면 여러모로 편하다는 것과 몇가지 규칙을 소개하고 있다. 의도를 분명히 밝혀라 의도가 분명

어떤 프로그램이든 가장 기본적인 단위가 함수다. 이 장은 함수를 잘 만드는 법을 소개한다.함수를 만드는 첫째 규칙은 '작게'다. 이 책의 저자는 함수가 적을 수록 좋다는 근거를 대기는 좀 어렵지만 40여년 동안 온갖 크기로 함수를 구현해봤을 때 작은 함수가 좋았다라고

이 장은 프로그래밍 언어 자체가 표현력이 풍부하다면 주석은 필요 없을 것이라고 말한다.주석은 코드 표현의 실패를 의미한다. 이렇게나 저자가 주석을 무시하는 이유는 주석이 너무 자주 거짓말을하기 때문이다. 주석은 오래될수록 코드에서 멀어진다. 점점 유지 보수하기 어려워진

깨끗한 코드와 오류 처리는 확실히 연관성이 있다. 상당수 코드 기반은 전적으로 오류 처리 코드에 좌우된다. 이 말은 지저분한 오류 처리 코드 때문에 실제 코드가 무엇을 하는지 파악하기 어려워지기 때문이다. 이 장은 오류 처리하는 기법과 고려 사항 몇 가지를 소개한다.위

우리는 때로는 오픈 소스를 이용하거나, 사내에서 다른 팀이 제공하는 컴포넌트를 이용하기도 한다.우리는 어떤 식으로든 이 외부 코드를 깔끔하게 통합을 해야한다. 이 장에서는 소프트웨어 경계를 깔끔하게 처리하는 기법과 기교를 설명하고 있다.패키지 제공자나 프레임워크 제공자

"복잡성은 죽음이다. 개발자에게서 생기를 앗아가며, 제품을 계획하고 제작하고 테스트하기 어렵게 만든다" - 레이 오지, 마이크로소프트 최고 기술 책임자도시의 온갖 세세한 사항을 혼자서 직접 관리하기란 어렵다. 도시가 잘 돌아가는 이유는 수도 관리팀, 전력 관리 팀, 치

켄트 벡이 제시한 소프트웨어 설계 품질을 높여줄 단순한 설계 규칙 네 가지(중요도 순)모든 테스트를 실행한다.중복을 없앤다.프로그래머 의도를 표현한다.클래스와 메서드 수를 최소를 줄인다.설계는 의도한 대로 돌아가는 시스템을 내놓아야 한다.문서로 완벽하게 설계했어도 검증

자바 프레임워크 중 가장 유명한 JUnit은 이미 잘 짜여진 코드지만 저자는 조금 더 개선할 수 있는 방향을 제시한다. 문자열 비교 오류를 파악할 때 유용한 코드인 ComparisonCompactor라는 모듈을 살펴보며 코드를 개선해본다.아래 코드는 Comparison