닭발개발

17일차. 클린코드[3주차_ 금요일] 151-160pg #요약 8. 경계 1) 외부 코드 사용하기 2) 경계 살피고 익히기 3) log4j 익히기 4) 학습 테스트는 공짜 이상이다. 5) 아직 존재하지 않는 코드를 사용하기 6) 깨끗한 경계 - 경계에서는 흥미로운일 (변경)이 많이 벌어진다. - 경계에 위치하는 코드는 깔끔히 분리한다. - 통제가 불가능한 외부 패키지에 의존하는 대신 통제가 가능한 우리 코드에 의존하는 편이 훨씬 좋다. 9. 단위 테스트 - 제대로 된 테스트 케이스를 작성하자 1) TDD 법칙 세 가지 a. 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. b. 컴파일은 실패하지 않으면서 실행히 실패하는 정도로만 단위 테스트를 작성한다. c. 현재 실패하는 테스트를 통과..

16일차. 클린코드[3주차_ 목요일] 142-150pg #요약 7. 오류처리 1) 오류 코드보다 예외를 사용하라 2) Try-Catch-Finally 문부터 작성하라 3) 미확인(unchecked) 예외를 사용하라 4) 예외에 의미를 제공하라 5) 호출자를 고려해 예외 클래스를 정의하라 6) 정상 흐름을 정의하라 7) null을 반환하지 마라 8) null을 전달하지 마라 9) 결론 - 깨끗한 코드는 읽기도 좋아야 하고, 안정성도 높아야 한다. - 오류 처리를 프로그램 논리와 분리하면 독립적인 추론이 가능해지고 코드 유지보수성도 높아진다. 8. 경계 - 외부 코드를 우리 코드에 깔끔하게 통합하는 법 - 소프트웨어 경계를 깔끔하게 처리하는 기법과 기교 1) 외부 코드 사용하기 - 인터페이스 제공자는 적용성..

14일차. 클린코드[3주차_화요일] 123-131pg #요약 6. 객체와 자료구조 1) 자료 추상화 2) 자료/객체 비대칭 3) 디미터 법칙 - 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다는 법칙 a. 기차 충돌 final String outputDir = stxt.getOptions().getScratchDir().getAbsolutePath(); - 여러 객체가 한 줄로 이어진 기차처럼 보이기 때문에 위와 같은 코드를 기차 충돌이라고 한다. - 기차충돌 코드는 조잡하다. - 위코드를 깨끗하게 하는 법 Options opts = ctxt.getOptions(); File scratchDir = opts.getScaratchDir(); final String outputDir = scratchDi..

6일차. 클린코드[1주차_토요일] 46-56pg #요약 1. 깨끗한 코드 2. 의미 있는 이름 3. 함수 - 함수를 잘 만드는 법을 소개한다. 1) 작게 만들어라! 2) 한 가지만 해라! 3) 함수 당 추상화 수준은 하나로! - 함수가 확실히 '한 가지' 작업만 하려면 함수 내 모든 문장의 추상화 수준이 동일해야 한다. - 한 함수 내에 추상화 수준을 섞으면 코드를 읽는 사람이 햇갈린다. -- 위에서 아래로 코드 읽기 : 내려가기 규칙 => 코드를 위에서 아래로 읽으면 함수 추상화 수준이 한 단계씩 내려가는 것. 4) Switch문 - switch문은 작게 만들기 어렵지만 다형성을 이용하여 각 switch문을 저차원 클래스에 숨기고 절대로 반복하지 않는 방법을 쓴다. 5) 서술적인 이름을 사용하라! - ..

3일차. 클린코드[1주차_수요일] 13-23pg #요약 1. 깨끗한 코드 {깨끗한 코드란?} - 론 제프리스 : 중복이 없고 표현력 높이고, 초반부터 간단한 추상화를 고려한 코드 - 워드 커닝햄 : 코드를 읽으며 짐작했던 기능을 제대로 수행한 코드 {우리들 생각} 이 책은 우리의 오브젝트 멘토 진영이 생각하는 깨끗한 코드를 설명한다. {우리는 저자다.} Javadoc에서 @author 필드가 저자를 소개하듯이 우리는 저자다. - 코드를 짤 때, 자신이 저자고, 이것을 볼 독자가 있다는 사실을 기억해야 한다. - 새 코드를 짜면서 기존 코드를 끊임없이 읽기 때문에 읽기 쉬운 코드가 중요하다. 보이스카우트 규칙에서는 캠핑장에 체크인 할 때보다 체크아웃 할 때 더 깨끗하게 하라고 한다. 코드도 마찬가지이다. ..

44일차. 오브젝트: 코드로 이해하는 객체지향 설계[8주차_화요일] 547-557pg #요약 **APPENDIX. 계약에 의한 설계** 01. 협력과 계약 02. 계약에 의한 설계 03. 계약에 의한 설계와 서브타이핑 - 서브타입이 리스코프 치환 원칙을 만족시키기 위해서는 클라이언트와 슈퍼타입 간에 체결된 계약을 준수해야 한다. - 리스코프 치환원칙의 규칙 a. 계약 규칙 : 슈퍼타입과 서브타입 사이의 사전조건, 사후조건, 불변식에대해 서술할 수 있는 제약에 관한 규칙 b. 가변성 규칙 : 파라미터와 리턴 타입의 변형과 관련된 규칙 1) 계약 규칙 - 사전조건 완화는 리스코프 치환 원칙을 위반하지 않는다. - 사후조건 완화는 리스코프 치환 원칙 위반이다.

37일차. 오브젝트: 코드로 이해하는 객체지향 설계[7주차_월요일] 471-482pg #요약 **Chapter 14. 일관성 있는 협력** 01. 핸드폰 과금 시스템 변경하기 1) 기본 정책 확장 2) 고정요금 방식 구현하기 3) 시간대별 방식 구현하기 - 책임을 할당하는 기본 원칙은 책임을 수행하는 데 필요한 정보를가장 잘 알고있는 정보 전문가에게 할당하는 것.

4일차. 제 1부. 도입편 제 1장. 시스템과 인프라 기초 지식 1.1. 시스템 기반의 기초 지식 1.2. 하드웨어와 네트워크 기초 지식 1.3. OS(Linux) 기초 지식 1.4. 미들웨어 기초지식 1.5. 인프라 구성 관리 기초 지식 1.6. 코드를 사용한 구성 관리 1.7. 대표적인 인프라 구성 관리 툴 1.8. 지속적 인티그레이션 / 지속적 딜리버리 - 테스트가 끝난 안전한 애플리케이션을 제품 환경으로 제공하기 위한 기초 지식 설명 1.8.1. 지속적 인티그레이션(Continuous Integration) - 애플리케이션의 코드를 추가 및 수정할 때마다 테스트를 실행하고 확실하게 작동하는 코드를 유지하는 방법 - 소프트웨어의 품질 향상을 목적으로 고안된 개발 프로세스 - 단위 테스트 : 소프트웨..

15일차. 오브젝트: 코드로 이해하는 객체지향 설계[3주차_수요일] 186-198pg #요약 **Chapter 06. 메시지와 인터페이스** - 클래스라는 구현 도구에 지나치게 집착하면 경직되고 유연하지 못한 설계에 이르게 된다. - 협력 안에서는 객체가 수행하는 책임에 초점을 맞춰야 하는데, 책임이 객체가 수신할 수 있는 메시지의 기반이 된다. - 애플리케이션은 클래스로 구성되지만 메세지를 통해 정의된다. 01. 협력과 메세지 1) 클라이언트-서버 모델 2) 메시지와 메시지 전송 3) 메시지와 메서드 4) 퍼블릭 인터페이스와 오퍼레이션 5) 시그니쳐 02. 인터페이스와 설계품질 1) 디미터 법칙 - 기차 충돌(train wreck) : 메시지 전송자가 수신자의 내부 구조에 대해 물어보고 반환받은 요소에..

12일차. 오브젝트: 코드로 이해하는 객체지향 설계[2주차_토요일] 142-155pg #요약 **Chapter 05. 책임 할당하기** - 책임에 초점을 맞춰서 설계할 때는 어떤 객체에 어떤 책임을 할당할지 결정하기가 쉽지 않다. - 책임 할당 과정은 일종의 트레이드오프 활동 - GRASP 패턴은 책임 할당의 어려움을 해결하기 위한 답을 제시해줄 것. 01. 책임 주도 설계를 향해 1) 데이터보다 행동을 먼저 결정하라. 2) 협력이라는 문맥 안에서 책임을 결정하라 3) 책임 주도 설계 02. 책임 할당을 위한 GRASP 패턴 1) 도메인 개념에서 출발하기 2) 정보 전문가에게 책임을 할당하라. - 수행할 정보를 알고 있는 객체에게 책임을 할당하는 것 : Information Expert(정보 전문가) 패..