Sadie의 개발일기

변경으로부터 격리 상세한 구현에 의존하는 클라이언트 클래스는 구현이 바뀌면 위험에 빠진다. => 인터페이스와 추상 클래스를 사용해 구현이 미치는 영향을 격리할 수 있음 시스템 시스템 수준과 같은 높은 추상화 수준에서 깨끗함을 유지하는 방법을 살펴보자. 시스템 제작과 시스템 사용을 분리하라 시스템을 제작하는 단계(시작 단계)와 사용하는 단계를 분리하여 코드를 설계하는 것이 좋다. 만일 생성 로직과 실행 로직이 뒤섞여 있으면(ex: 초기화 지연 기법), 실행 메서드에서 생성자 인수에 의존하게 되고, 테스트 시에도 적절한 테스트 전용 객체와 실행 경로 등을 신경써야 하는 복잡성이 생긴다. 또한 실행 로직과 뒤섞인 생성 로직에서 생성하는 객체는 모든 문맥에 적합하기 어렵다. 설정 논리는 일반 실행 논리와 분리해..

변경하기 쉬운 클래스 변경을 하고 싶을 때 이미 존재하는 클래스 코드에 손대어야만 수정할 수 있는 코드는 바람직하지 않다. => 클래스에 손대면 다른 코드를 망가뜨릴 잠정적인 위험이 존재함. 위의 경우, 클래스를 분리하면 기존 클래스를 변경하지 않고도 기능을 추가할 수 있도록 리팩토링할 수 있다. => SRP(단일 책임 원칙), OCP(확장에 개방적이고 수정에 폐쇄적이어야 한다는 원칙)의 관점에서 바람직함. 새 기능을 수정하거나 기존 기능을 변경할 때 건드릴 코드가 최소인 시스템 구조가 바람직하다.

클래스 깨끗한 클래스가 깨끗한 코드를 만든다. 클래스 체계 표준 자바 관례에 따르면, 정적 공개 상수 정적 비공개 변수 비공개 인스턴스 변수 공개 함수 비공개 함수(자신을 호출하는 공개 함수 직후에 등장) 순으로 정의되며 클래스를 구성한다. => 추상화 단계가 순차적으로 내려가 신문 기사처럼 읽힌다. 캡슐화 변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫다. 클래스는 작아야 한다! 클래스는 작게 만드는 것이 기본 규칙 -> 하나의 클래스는 하나의 책임만 맡아야 한다. 클래스 이름은 해당 클래스 책임을 기술해야 한다. (클래스 이름이 모호하다면 클래스 책임이 너무 많아서일 확률 높음. Processor, Manager, Super 등과 같은 단어들) 클래스 설명은 만일(if), 그리고(and), 또한..

도메인에 특화된 테스트 언어 가독성을 위해 테스트 코드에서만 사용하는 특수 API를 사용하는 것도 좋다. 이중 표준 실제 환경과 테스트 환경은 요구사항이 다르다. => 실제 환경에서는 절대로 안 되지만 테스트 환경에서는 전혀 문제없는 방식이 있음(메모리나 CPU 효율과 관련 있는 경우 등) 테스트 당 assert 하나 함수마다 assert 문을 단 하나만 사용해야 한다고 주장하는 의견들이 있음 assert문이 하나인 함수는 결론이 하나라 코드를 이해하기 쉽고 빠르지만, 꼭 지켜야만 하는 법칙은 아니다. => 테스트 코드를 짜다 보면 assert를 여럿 두는 편이 가장 간결하고 이해하기 쉬울 때가 있음. 다만 assert문 개수는 최대한 줄이는 편이 좋다. 테스트 당 개념 하나 테스트 함수마다 한 개념을 ..

깨끗한 경계 경계를 잘 처리하면 소프트웨어 변경에 많은 투자와 재작업이 필요하지 않다. 경계에 위치하는 코드는 깔끔히 분리하고, 테스트 케이스를 작성하여 통제할 수 있게 한다. 단위 테스트 TDD 법칙 세 가지 TDD : 실제 코드를 짜기 전에 단위 테스트부터 짜는 것 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. 위 세 가지 규칙을 따르면 개발과 테스트가 30초 주기로 묶여, 테스트 코드와 실제 코드가 함께 나온다. 깨끗한 테스트 코드 유지하기 테스트 코드는 유지하기 힘들지만, 테스트 코드가 없으면 시스템 결함율이 높아진다. => 코드 변경을 ..

경계 패키지, 오픈 소스 등의 외부 코드를 우리 코드에 깔끔하게 통합시키기 위한 기교를 알아보자. 외부 코드 사용하기 만약 외부에서 가져온 인터페이스를 우리 코드 여기저기에서 각자의 인스턴스를 만들어 사용한다면, 해당 인터페이스가 변할 경우 수정할 코드가 상당히 많아진다. => 경계 인터페이스를 여기저기 넘기지 않고 이를 캡슐화한 클래스를 만들어 이용하면 이를 예방할 수 있다. 경계 살피고 익히기 외부 패키지를 사용할 땐 테스트 코드를 사용하는 게 바람직하다. 학습 테스트 : 간단한 테스트 케이스를 통해 외부 코드를 익히는 기법 학습 테스트는 패키지가 예상대로 도는지 검증하며, 우리가 패키지를 익히게 해주고, 새 버전이 나올 때마다 우리 코드와 호환되는지를 검사한다. 경계 테스트가 없으면 버전 마이그레이..

Try-Catch-Finally 문부터 작성하라 예외가 발생할 코드를 짤 때는 try-catch-finally 문으로 시작하는 편이 낫다. -> 강제로 예외를 일으키는 테스트 케이스를 작성한 후 테스트를 통과하게 코드를 작성하고, 이를 기반으로 나머지 논리를 추가하는 방법을 권장한다. (try 블록의 트랜잭션 본질을 유지하기 쉬움) 미확인 예외를 사용하라 자바에는 확인된 예외라는 게 있는데, 이는 OCP를 위반하므로 일반적인 애플리케이션에서는 쓰지 않는 게 좋다. 예외에 의미를 제공하라 예외를 던질 때 충분한 정보를 넘겨준다. 호출자를 고려해 예외 클래스를 정의하라 예외에 대응하는 방식이 거의 동일할 경우엔, 래퍼 클래스를 하나 정의해서 중복 코드를 줄일 수 있다. 정상 흐름을 정의하라 예외 처리를 활용..

디미터 법칙 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다는 법칙. => C 클래스의 메서드 f는 다음 객체의 메서드만 호출해야 한다는 법칙 - 클래스 C - f가 생성한 객체 - f 인수로 넘어온 객체 - C 인스턴스 변수에 저장된 객체 예를 들어, final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath() 위 코드는 객체의 메서드를 두 번 중첩해서 호출하므로 디미터 법칙을 어김. 위와 같은 코드는 기차 충돌이라 부르며, 일반적으로 피하는 편이 좋다. 객체라면 내부 구조를 숨겨야 하므로 디미터 법칙이 적용되지만, 자료 구조는 기본적으로 내부 구조를 노출하므로 디미터 법칙이 적용되지 않는다. 즉 다음과 같은 코드는 디미터..

들여쓰기 범위로 이뤄진 소스 계층을 표현하기 위해 코드를 들여씀 => 들여쓰기는 가독성을 향상시킨다. 들여쓰기 무시하기 if, while문을 쓰면서 한 행에 범위를 뭉뚱그리는 것은 좋지 않다. 가짜 범위 빈 while문이나 빈 for 문은 피한다. 팀 규칙 팀은 한 가지 규칙에 합의해야 하고, 모든 팀원은 그 규칙을 따라야 한다. => 소프트웨어가 일관적인 스타일을 보일 수 있도록. 객체와 자료 구조 자료 추상화 구현을 감추려면 추상화가 필요함 형식 논리에 치우쳐 getter/setter로 변수를 다룬다고 클래스가 되지는 않음 => 추상 인터페이스를 사용해 구현을 몰라도 자료의 핵심을 조작할 수 있어야 진정한 클래스. 아무 생각 없이 getter/setter를 추가하는 방법은 나쁘다. 자료/객체 비대칭 ..

인스턴스 변수 인스턴스 변수는 클래스 맨 처음에 선언하고, 변수 간에 세로로 거리를 두지 않는다. => 언어마다 인스턴스 변수를 선언하는 위치는 다를 수 있지만, 잘 알려진 위치에 인스턴스 변수를 모은다는 점은 같으며 그 점이 중요하다. 종속 함수 한 함수가 다른 함수를 호출한다면 두 함수는 세로로 가까이 배치하며, 가능하다면 호출하는 함수를 호출되는 함수보다 먼저 배치한다. => 프로그램이 자연스럽게 읽히기 위함 + 규칙을 일관적으로 적용하면 독자는 방금 호출한 함수가 잠시 후에 정의되리라는 사실을 예측한다. 개념적 유사성 개념적인 친화도가 높을수록 코드를 가까이 배치한다. 친화도가 높은 경우 : 한 함수가 다른 함수를 호출할 때(종속성), 변수와 그 변수를 사용하는 함수, 비슷한 동작을 수행하는 일군..