클린 코드9 10장. 클래스 오늘 읽은 범위 10장. 클래스 기억하고 싶은 내용 클래스 체계 (p.172) 정적(static) 공개(public) 상수 → 정적 비공개(private) 변수 → 비공개 인스턴스 변수 → 공개 함수 → 비공개 함수 변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫다. 클래스는 작아야 한다! (p.172) 클래스의 크기를 측정하는 척도는 클래스가 맡은 책임이다. 단일 책임 원칙(Single Responsibility Principle, SRP): 클래스나 모듈을 변경할 이유가 하나뿐이어야 한다는 원칙이다. 응집도(Cohesion): 클래스에 속한 메서드와 변수가 서로 의존하며 논리적인 단위로 묶인다는 의미이다. 응집도를 유지하면 작은 클래스 여럿이 나온다. 변경하기 쉬운 클래스 (p.185) 시스템의.. 2022. 3. 9. 9장. 단위 테스트 오늘 읽은 범위 9장. 단위 테스트 기억하고 싶은 내용 TDD 법칙 세 가지 (p.155) 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. 깨끗한 테스트 코드 유지하기 (p.156) 테스트 코드는 실제 코드 못지않게 중요하다. 테스트는 유연성, 유지보수성, 재사용성을 제공한다. 테스트 케이스가 있으면 변경이 쉬워지기 때문이다. 깨끗한 테스트 코드 (p.158) 깨끗한 테스트 코드를 만드는데 가독성이 중요하다. 테스트 코드를 도메인에 특화된 언어(DSL)로 리팩터링 해야 한다. 테스트 코드에 적용하는 표준은 실제 코드에 적용하는 표준과 달라도 된다... 2022. 3. 6. 7장. 오류 처리 오늘 읽은 범위 7장. 오류 처리 기억하고 싶은 내용 오류 코드보다 예외를 사용하라 (p.130) 오류 코드를 사용하면 각 개념을 독립적으로 살펴보고 이해할 수 있다. Try-Catch-Finally 문부터 작성하라 (p.132) try 블록에서 무슨 일이 생기든지 호출자가 기대하는 상태를 정의하기 쉬워진다. 미확인(unchecked) 예외를 사용하라 (p.133) 확인된 예외는 OCP(Open Closed Principle)를 위반한다. 예외에 의미를 제공하라 (p.135) 예외를 던질 때는 전후 상황을 충분히 덧붙인다. 호출자를 고려해 예외 클래스를 정의하라 (p.135) 외부 API를 감싸면 외부 라이브러리와 프로그램 사이에서 의존성이 크게 줄어든다. 감싸기 클래스에서 외부 API를 호출하는 대신 .. 2022. 3. 4. 6장. 객체와 자료 구조 오늘 읽은 범위 6장. 객체와 자료 구조 기억하고 싶은 내용 자료 추상화 (p.118) 변수를 private으로 선언하더라도 각 값마다 조회(get) 함수와 설정(set) 함수를 제공한다면 구현을 외부로 노출하는 셈이다. 구현을 감추려면 추상화가 필요하다! 자료/객체 비대칭 (p.119) 객체: 추상화 뒤로 자료를 숨긴 채 자료를 다루는 함수만 공개한다. 자료 구조: 자료를 그대로 공개하며 별다른 함수는 제공하지 않는다. 객체 지향 코드는 기존 함수를 변경하지 않으면서 새 클래스를 추가하기 쉽다. 절차적인 코드는 기존 자료 구조를 변경하지 않으면서 새 함수를 추가하기 쉽다. 디미터 법칙 (p.123) 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다는 법칙이다. 자료 구조라면 당연히 내부 구조를 노출하.. 2022. 3. 1. 5장. 형식 맞추기 오늘 읽은 범위 5장. 형식 맞추기 기억하고 싶은 내용 형식을 맞추는 목적: 코드 형식은 의사소통의 일환이다. (p.96) 적절한 행 길이를 유지하라: 일반적으로 큰 파일보다 작은 파일이 이해하기 쉽다. (p.97) 신문 기사처럼 작성하라 이름은 간단하면서도 설명이 가능하게 짓는다. 소스 파일 첫 부분은 고차원 개념과 알고리즘을 설명한다. 아래로 내려갈수록 의도를 세세하게 묘사한다. 마지막에는 가장 저차원 함수와 세부 내역이 나온다. 개념은 빈 행으로 분리하라 세로 밀집도: 서로 밀접한 코드 행은 세로로 가까이 놓아야 한다. 수직 거리: 서로 밀접한 개념은 세로로 가까이 둬야 한다. 변수 선언: 변수는 사용하는 위치에 최대한 가까이 선언한다. 인스턴스 변수: 인스턴수 변수는 클래스 맨 처음에 선언한다. .. 2022. 2. 28. 4장. 주석 오늘 읽은 범위 4장. 주석 기억하고 싶은 내용 “나쁜 코드에 주석을 달지 마라. 새로 짜라.” (p.68) 주석은 나쁜 코드를 보완하지 못한다. (p.69) 코드 품질이 나쁘다면 주석을 추가할 것이 아니라 코드를 정리해야 한다. 코드로 의도를 표현하라! (p.70) 좋은 주석 (p.70) 정말로 좋은 주석은, 주석을 달지 않을 방법을 찾아낸 주석이다. 법적인 주석 정보를 제공하는 주석: 주석이 유용하다 할지라도, 가능하다면, 함수 이름에 정보를 담는 편이 더 좋다. 의미를 명료하게 밝히는 주석: 인수나 반환값이 표준 라이브러리나 변경하지 못하는 코드에 속한다면 의미를 명료하게 밝히는 주석이 유용하다. 결과를 경고하는 주석: 때로 다른 프로그래머에게 결과를 경고할 목적으로 주석을 사용한다. TODO 주석.. 2022. 2. 25. 3장. 함수 오늘 읽은 범위 3장. 함수 기억하고 싶은 내용 작게 만들어라! (p.42) 함수를 만드는 첫째 규칙은 ‘작게!’다. 함수를 만드는 둘째 규칙은 ‘더 작게!’다. 함수에서 들여 쓰기 수준은 1단이나 2단을 넘어서면 안 된다. 한 가지만 해라! (p.44) 함수는 한 가지를 해야 한다. 그 한 가지를 잘해야 한다. 그 한 가지만을 해야 한다. 단순히 다른 표현이 아니라 의미 있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 여러 작업을 하는 셈이다. 함수 당 추상화 수준은 하나로! (p.45) 함수가 확실히 ‘한 가지' 작업만 하려면 함수 내 모든 문장의 추상화 수준이 동일해야 한다. 코드는 위에서 아래로 이야기처럼 읽혀야 좋다. 한 함수 다음에는 추상화 수준이 한 단계 낮은 함수가 온다. Switc.. 2022. 2. 23. 2장. 의미 있는 이름 오늘 읽은 범위 2장. 의미 있는 이름 기억하고 싶은 내용 의도를 분명히 밝혀라: 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다. (p.22) 그릇된 정보를 피하라: 그릇된 단서는 코드 의미를 흐린다. (p.24) 의미 있게 구분하라: 읽는 사람이 차이를 알도록 이름을 지어라. (p.25) 발음하기 쉬운 이름을 사용하라: 발음하기 어려운 이름은 토론하기도 어렵다. (p.27) 검색하기 쉬운 이름을 사용하라: 변수나 상수를 코드 여러 곳에서 사용한다면 검색하기 쉬운 이름이 바람직하다. (p.28) 인코딩을 피하라: 이름에 불필요한 정보를 추가하지 말고 IDE를 활용하라. (p.29) 자신의 기억력을 자랑하지 마라: 전문가 프로그래머는 자신의 능력을 좋은 방향으로 사용해 남들이 이해하는 코드를 내.. 2022. 2. 20. 1장. 깨끗한 코드 오늘 읽은 범위 추천사 0장. 들어가면서 1장. 깨끗한 코드 기억하고 싶은 내용 "사소한 곳에서 발휘하는 정직은 사소하지 않다" (p.xxii) 깨끗한 코드는 한 가지를 제대로 한다. (p.9) 깨끗한 코드는 잘 쓴 문장처럼 읽힌다. 깨끗한 코드는 명쾌한 추상화와 단순한 제어문으로 가득하다. (p.10) 테스트 케이스가 없는 코드는 깨끗한 코드가 아니다. (p.12) 깨끗한 코드는 주의 깊게 작성한 코드다. (p.12) 중복을 피하라. 한 기능만 수행하라. 제대로 표현하라. 작게 추상화하라. (p.14) 보이스카우트 규칙: 캠핑장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라. (p.19) 소감 및 생각 "사소한 곳에서 발휘하는 정직은 사소하지 않다" 라는 추천사에서 제시한 문장이 크게 와닿았다. 사소한.. 2022. 2. 19. 이전 1 다음