반응형

Dev/Books 10

[DDD Start!] 1장. 도메인 모델 시작

도메인 소프트웨어로 해결하고자 하는 문제영역을 도메인이라고 한다. 도메인은 하위 도메인으로 이루어 지기도 하는데, 예를 들어 주문이라는 도메인에는 혜택, 결제, 배송, 정산이라는 하위 도메인이 존재한다. 그러나 모든 도메인이 하위 도메인이 존재하는 것은 아니므로, 상황에 따라 하위 도메인 구성을 판단하면 된다. 도메인 모델 특정 도메인을 개념적으로 표현한 것을 도메인 모델이라고 한다. 도메인을 이해하기 위해서는 제공하는 기능과 도메인의 주요 데이터 구성을 파악해야 하는데, 이런 면에서 기능과 데이터를 함께 보여주는 객체 모델은 도메인을 모델링하기에 적합하다. 도메인 모델을 모델링 하는 방법은 객체 모델 외에도 상태 다이어그램이나 UML 표기기법 외에도 그래프(관계가 중요한 도메인일 시), 수학 공식(계산..

Dev/Books 2020.06.06

[CleanCode] 10장. 클래스

클래스 체계 클래스 정의 표준 자바 관례에 따른 클래스 구성 순서 public satic 상수 private static 변수 private instance 변수 public 함수 private 함수 - 자신을 호출하는 public 함수 직후에 위치 캡슐화 변수와 유틸리티 함수는 가능한 공개하지 않아야 함 테스트를 위해 protected 선언/패키지 전체 공개, but!!!! 캡슐화를 풀어주는 결정은 최후의 수단 클래스는 작아야 한다! 클래스를 만들때의 규칙은 무조건 작게! 얼마나 작아야 할까? 함수와는 다르게 맡은 책임의 수가 기준 클래스의 책임? 네이밍이 나타낸다. 구현 과정에서 간결한 이름이 떠오르지 않거나 클래스 이름이 모호하다는 것은 책임이 많다는 반증 단일 책임의 원칙 Single Respon..

Dev/Books 2020.05.31

[CleanCode] 9장. 단위 테스트

목차 TDD 법칙 세 가지 깨끗한 테스트 코드 유지하기 깨끗한 테스트 코드 테스트 당 assert 하나 F.I.R.S.T TDD 법칙 세 가지 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. 깨끗한 테스트 코드 유지하기 깨끗하지 않은 테스트 코드는 유지 보수에 많은 비용이 필요하게 되고, 테스트 코드가 없으면 프로덕션 코드의 결함율이 높아지게 된다. 테스트 코드는 유연성, 유지보수성, 재사용성을 제공해야 한다. 깨끗한 테스트 코드 깨끗한 테스트 코드는 명료성, 단순성, 풍부한 표현을 바탕으로 한 가독성이 필수이다. 테스트 당 assert 하나 as..

Dev/Books 2020.05.18

[CleanCode] 8장. 경계

목차 외부 코드 사용하기 경계 살피고 익히기 log4j 익히기 학습 테스트는 공짜 이상이다 아직 존재하지 않는 코드를 사용하기 깨끗한 경계 패키지를 사거나, 오픈소스를 사용하는 등 외부의 코드와 팀의 코드를 함께 사용할 때 소프트웨어 경계를 깔끔하게 처리하여 통합하는 방법에 대하여 이야기 한다. 외부 코드 사용하기 인터페이스 제공자 더 많은 환경에 돌아가게 하기 위해 적용성을 최대한 넓히려 함 인터페이스 사용자 자신의 요구에 집중하는 인터페이스를 바람 경계 인터페이스가 외부에 공개되지 않도록 한다. 캡슐화 등을 통해 API의 인수나 메서드의 반환 값 등으로 경계 인터페이스를 직접 노출하지 않도록 한다. 이 방법을 통해 경계 인터페이스가 변경 되었을 때 관련된 코드를 모두 고치지 않아도 되고, 불필요한 인..

Dev/Books 2020.05.18

[CleanCode] 7장. 예외 처리

목차 오류 코드보다 예외를 사용하라 Try-Catch-Finally 문부터 작성하라 미확인 예외를 사용하라 예외에 의미를 제공하라 호출자를 고려해 예외 클래스를 정의하라 정상 흐름을 정의하라 null을 반환하지 마라 null을 전달하지 마라 오류 코드보다 예외를 사용하라 오류 코드를 받아 처리 로직을 추가하는 것보다 오류가 발생하면 예외를 던지는게 좋음 Bad : 함수를 호출한 즉시 오류를 확인하지 않으면 문제가 발생할 확률이 높음 public class DeviceController { ... public void sendShutDown() { DeviceHandle handle = getHandle(DEV1); if (handle != DeviceHandle.INVALID) { retrieveDevi..

Dev/Books 2020.05.16

[CleanCode] 6장. 객체와 자료 구조

목차 자료 추상화 자료/객체 비대칭 디미터 법칙 자료 전달 객체 자료 추상화 변수를 함수를 통해 계층을 추가한다고 해서 구현이 저절로 감춰지지는 않는다. 추상 인터페이스를 제공해 사용자가 구현을 모르는 채 자료의 핵심을 조작할 수 있어야 클래스라고 할 수 있다. Bad : // 해당 클래스에 getX, getY 메서드를 추가한다 해도 사용자는 x, y를 반환할 뿐일 것이라고 추측이 가능하다 // 이것은 전혀 추상화되지 않은 상태이다 public class Point { public double x; public double y; } Good : // x, y가 실제 직교 좌표계인지, 극좌표계인지 알 수 없다 // 내부에서 변수가 바뀌던, 로직이 바뀌던 클라이언트는 상관이 없다 public interfac..

Dev/Books 2020.05.15

[CleanCode] 5장. 형식 맞추기

목차 형식을 맞추는 목적 적절한 행 길이를 유지하라 가로 형식 맞추기 팀 규칙 프로그래머는 규칙에 맞게 형식을 깔끔하게 맞춰 코드를 짜야 한다. 팀으로 일한다면 팀이 합의해 규칙을 정하고 모두가 그 규칙을 따라야 한다. 형식을 맞추는 목적 맨 처음 잡아놓은 코드의 스타일과 가독성은 유지보수 용이성과 확정성에 계속 영향을 미친다. 적절한 행 길이를 유지하라 신문 기사처럼 작성하라 소스 파일은 고차원 개념/알고리즘 -> 저차원 함수와 세부 내역 순으로 아래로 내려갈수록 의도를 세세하게 표현 개념은 빈 행으로 분리하라 세로 밀집도 서로 밀접한 코드 행은 세로로 가까이 놓여야 함 수직 거리 변수 선언 - 사용하는 위치에 최대한 가까이 선언 인스턴스 변수 - 클래스의 맨 처음에 선언, 변수 간에 세로로 거리를 두..

Dev/Books 2020.05.12

[CleanCode] 4장. 주석

목차 주석은 나쁜 코드를 보완하지 못한다 코드로 의도를 표현하라 좋은 주석 나쁜 주석 주석은 나쁜 코드를 보완하지 못한다 모듈이 지저분하다면 주석을 다는것이 아니라 코드를 정리해야 한다. 코드로 의도를 표현하라 Bad : // 직원에게 복지 혜택을 받을 자격이 있는지 검사한다 if ((employee.flags && HOURLY_FLAG) && (employee.age > 65)) Good : if (employee.isEligibleForFullBenefits()) 좋은 주석 법적인 주석 정보를 제공하는 주석 코드를 개선하면 없앨 수 있는 주석이다. 의도를 설명하는 주석 소스 코드의 알고리즘을 결정하게 된 의도를 설명하는 주석 의미를 명료하게 밝히는 주석 인수나 반환값이 변경하지 못하는 코드일 경우 의..

Dev/Books 2020.05.12

[CleanCode] 3장. 함수

목차 작게 만들어라! 한 가지만 해라! 함수 당 추상화 수준은 하나로! Switch 문 서술적인 이름을 사용하라 함수 인수 부수 효과를 일으키지 마라! 명령과 조회를 분리하라! 오류 코드보다 예외를 사용하라! 반복하지 마라! 구조적 프로그래밍 함수를 어떻게 짜죠? 결론 작게 만들어라! 작게의 기준은 무엇일까? 블록과 들여쓰기 if/else/switch 문 등에 들어가는 블록은 한 줄이며 indent는 2단을 넘어서면 안된다. 적절한 메서드명을 가지는 메서드를 호출하는 방식을 통해 이를 충족시킨다. 한 가지만 해라! 함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다. 함수는 추상화 수준이 하나인 단계만 수행한다면 그 함수는 한 가지 작업만 한다. 한 함수에서 섹션을 나..

Dev/Books 2020.05.06

[CleanCode] 2장. 의미있는 이름

의미있는 이름 목차 의도를 분명히 밝혀라 그릇된 정보를 피하라 의미 있게 구분하라 발음하기 쉬운 이름을 사용하라 검색하기 쉬운 이름을 사용하라 인코딩을 피하라 자신의 기억력을 자랑하지 마라 클래스 이름 메서드 이름 기발한 이름은 피하라 한 개념에 한 단어를 사용하라 말장난을 하지마라 해법 영역에서 가져온 이름을 사용하라 문제 영역에서 가져온 이름을 사용하라 의미 있는 맥락을 추가하라 불필요한 맥락을 없애라 의도를 분명히 밝혀라 이름을 지을 때 아래의 질문들을 고려해야 한다. 변수(혹은 함수나 클래스)의 존재 이유는? 수행 기능은? 사용 방법은? Bad public List getThem() { List list1 = new ArrayList(); for (int[] x : theList) if (x[0]..

Dev/Books 2020.05.02
반응형