클린코드

p.19객체지향 설계 원칙 (SOLID)SRP (Single Reponsibility Principle / 단일 책임 원칙) \- "어떤 클래스를 변경 해야 하는 이유는 오직 하나뿐 이어야 한다 - 로버트 C 마틴" \- 작성된 클래스는 하나의 기능만 가지며, 클

Chapter 3, 4 >함수, 주석 인상깊은 구절 작은 함수가 좋다 함수에서 들여쓰기 수준은 1단이나 2단을 넘어서지 않을 것 위에서 아래로 프로그램을 읽으면 함수 추상화 수준이 한번에 한 단계씩 낮아지도록: 내려가기 규칙 switch문과 같이 작게 만들기 어려

개념은 빈 행으로 분리하라서로 밀접한 개념은 세로로 가까이 둬야한다protected 변수를 최대한 피해야 함틈새 접근자 (Access Modifier) 상식private -> default -> protected -> public 순으로 보다 많은 접근을 허용priva

요 챕터에서 경계라함은 외부 코드를 우리 코드에 활용해야할 때, (외부 API 연동 등) 테스트의 방식이나 구현의 경계를 의미한다.외부 코드 사용하기 ex) Map 인터페이스 사용하기Map<String, String> sensors = new HashMap<

시스템 수준에서도 깨끗함을 유지하는 방법애플리케이션 객체를 제작하고 의존성을 서로 "연결"하는 준비과정과, 준비 과정 이후에 이어지는 런타임 로직을 분리해야한다.그런데 내가 느끼기로는, 요새는 개발자가 따로 신경써서 분리하기 보다도 스프링 등의 프레임워크를 사용하면,

동시성 무엇(What)과 언제(When)을 분리하면, 애플리케이션 구조와 효율이 극적으로 나아짐ex) 서블릿 모델: EJB(Enterprize Java Bean) 컨테이너로 관리되는데, 이들은 동시성을 부분적으로 관리실제로 컨테이너가 어떻게 동작하는지, 어떻게 동시 수

점진적인 개선: 명령행 인수 구문분석기 코드 개선깨끗한 코드를 짜려면 먼저 지저분한 코드를 짠 뒤에 정리해야한다.인수 유형은 다양하지만 모두가 유사한 메서드를 제공할 경우 클래스 하나가 적합TDD: 언제 어느 때라도 시스템이 돌아가야 한다. 각 인수 유형을 처리하는 코

냄새와 휴리스틱쓸모 없어질 주석은 아예 달지 않는 편이 가장 좋다주석 처리된 코드는 즉시 삭제하라독자는 인수를 일반적으로 입력으로 간주한다. 함수에서 뭔가의 상태 변경이 필요하면 함수가 속한 객체의 상태를 변경하라.아무도 호출하지 않는 함수는 삭제해라모든 경계 조건을