나의 흐름대로 천천히, 그리고 꾸준히 나아가자

17장 - 냄새와 휴리스틱 리팩터링이 필요한 코드에서 나쁜 냄새가 난다고한다. 코드를 작성하고 해당되는지 확인해야할 것을 정리해놓았다. 주석 - 부적절한 정보, 쓸모 없는 주석, 중복된 주석, 성의 없는 주석, 주석 처리된 코드 환경 - 여러 단계로 빌드 및 테스트 함수 - 너무 많은 인수, 출력 인수, 플래그 인수, 죽은 함수 일반 - 한 소스 파일에 여러 언어를 사용한다, 당연한 동작을 구현하지 않는다, 경계를 올바로 처리하지 않는다, 안전 절차 무시, 중복, 추상화 수준이 올바르지 못하다, 기초 클래스가 파생 클래스에 의존한다, 과도한 정보, 죽은 코드, 수직 분리, 일관성 부족, 잡동사니, 인위적 결합, 기능 욕심, 선택자 인수, 모호한 의도, 잘못 지운 책임, 부적절한 static 함수, 서술적..

15장 - JUnit 들여다보기 JUnit은 자바 프레임워크 중 가장 유명한 프레임워크이다. JUnit의 저자는 많지만 시작은 켄트 벡과 에릭 감마, 두 사람이라고 한다. 비행기를 타고가다가 세 시간만에 JUnit의 기초가 되는 코드를 작성하였다고 하는데 그 JUnit이 지금은 자바 프레임워크 중 가장 유명한 프레임워크가 되었다. JUnit의 프레임워크에서 가져온 코드를 보니 그야말로 '클린 코드'인 것 같다는 생각이 들었다. 심지어 이 책에서는 이 JUnit의 코드를 개선하며 이 세상에 개선이 불필요한 모듈은 없다고 말한다. 완벽한 것 같아도 코드가 개선될 여지는 있다는 것이다. 16장 - SerialDate 리팩터링 이 장에서는 JCommon 라이브러리에 SerialDate 클래스를 리팩터링해본다. ..

14장-점진적인 개선 여기서는 직접 코드를 개선하는 과정을 보여준다. 일단 프로그램이 돌아간다고 다음 업무로 넘어가지 말자! 이 코드를 검증하고 개선하는 것이 필수적이다. 코드를 고치는데 난잡해지는 것 같은 느낌이 들면 멈춰보자! TDD를 이용하여 개발하며 개선을 할 때는 자잘한 변경을 하면서 변경 전후의 시스템이 비슷하도록 해야한다. 프로그램을 완전 갈아엎는 것을 개선이라고 보기는 어렵다. getter와 setter를 사용하며 메소드, 생성자 간에 인수 전달이 명확하고 효과적으로 하도록 한다. 만든 함수, 넘긴 인자가 다 쓰여야한다. 클래스와 함수에 되도록 하나의 책임, 하나의 기능을 담당하도록 구성한다. 계속 테스트를 실행해보는 것이 필요하다.

11장-시스템 사용과 제작 분리 - 의존성 주입 - 단일 책임 원칙 클래스는 수동적으로 작동, setter나 생성자를 이용하여 의존성을 주입한다. AOP - Aspect Oriented Programming, 관점 지향 프로그래밍 - 관점: 특정 관심사를 지원하려면 시스템에서 특정 지점들이 동작하는 방식을 일관성 있게 바꿔야한다. - 영속성 제공 자바 프록시 - 단순한 상황에 적합 - 개별 객체나 클래스에서 메서드 호출 감싸기 순수 자바 AOP 프레임워크 AspectJ 관점 - 관심사를 관점으로 분리하는 가장 강력한 도구: AspectJ 언어 테스트 주도 시스템 아키텍처 구축 - 상황에 맞게 새로운 기술을 채택해 아키텍처 변경 가능 깨끗하지 못한 아키텍처는 도메인 논리를 흐리며 기민성을 떨어뜨리고 제품 ..

7장 - 예외처리 오류가 발생하면 예외를 던져라! try문에서 실행하는 메소드를 정의할 때 예외를 throws하는 형식으로 코드를 작성한다. try-catch-finally문을 작성하여 프로그램 안에다 범위를 정의하자. 강제로 예외를 일으키는 테스트 케이스를 작성한 후 테스트를 통과하게 코드를 작성하는 방법을 권장한다. 예외를 던질 때 로깅을 하는 것이 좋다. 외부API를 사용할 때 감싸기 기법(Wrapper 사용)를 쓰는 것이 좋다. null을 반환/전달하지 말아라. 8장 - 경계 외부 코드를 내 코드에 깔끔하게 통합하는 방법 Generics 사용하는 것도 좋지만 사용자에게 불필요한 기능까지 제공한다는 단점이 있다. 경계 인터페이스를 다른 클래스 안으로 숨겨서 공개 API의 인수로 넘기거나 반환값으로 ..

4장 주석 이 책의 저자는 주석을 달지 않는 방향으로 유도하는 주석이 좋은 주석이라고 한다. 이 내용을 처음 보았을 때 사실 '이게 무슨 말이지?'라고 생각했다. 주석을 달지 않기 위한 주석이라니... 어떻게 보면 굉장히 모순적이지 않은가 1~3장에서 보았듯이 이 책의 저자는 변수명, 함수명 등 코드 자체적으로 이것이 어떤 의미를 담고있는지 직관적으로 나타나게 해야한다고 했었다. 이것의 연장선으로 코드가 분명하여 주석이 필요없을 정도가 되어야한다는 뜻인 것 같다. 이 책에서 말하는 좋은 주석과 나쁜 주석에 대해 간단히 요약을 해보자. 좋은 주석 - 법적인 주석 - ex. 저작권 정보, 소유권 정보 등 - 정보를 제공하는 주석 - 그래도 가능하다면 함수 이름에 정보를 담는 편이 좋음. - 의도를 설명하는 ..

책을 읽기 전 내가 생각했던 클린코드란? 내 코드 그리고 다른 사람의 코드를 읽으면서 '이 코드는 잘 읽히고 잘 이해가 된다.' '이 코드는 너무 복잡하다. 이해하기 힘들다.' 이런 생각을 무의식적으로 하다보니 대충 이런 게 좋은 코드, 클린코드인 것 같다는 생각을 했지 구체적으로 "이것이 클린코드다"라고 정의하지는 못했던 것 같다. 앞으로 더 나은 개발자, 성장하는 개발자가 되기 위해, 그리고 나를 위해서도 같이 일하는 동료를 위해서도 내 코드를 볼 제 3자를 위해서도 클린 코드로 코드를 짜는 것은 중요한 과제이기에 이 책을 읽게 되었다. 1장 나쁜 코드로 치르는 대가가 생각보다 굉장하다는 것을 알게 되었다. 하지만 이 점에 대해 생각을 해보지 못했을 뿐이지 어쩌면 당연한 것이다. 상상을 해보자. 나 ..