닭발개발

24일차. 클린코드[4주차_ 토요일] 216-223pg #요약 12. 창발성 1) 창발적 설계로 깔끔한 코드를 구현하자. - 켄트 벡이 제시한 단순한 설계 규칙 네 가지가 소프트웨어 설계 품질을 높여줄 수 있다. ( 중요도 순 ) 🎈 모든테스트를 실행한다. 🎈 중복을 없앤다. 🎈 프로그래머 의도를 표현한다. 🎈 클래스와 메서드 수를 최소로 줄인다. 2) 단순한 설계 규칙1 : 모든 테스트를 실행하라 - 테스트가 가능한 시스템을 만드려고 애쓰면 설계 품질이 더불어 높아진다. 3) 단순한 설계 규칙 2 ~ 4 : 리팩터링 - 코드를 정리하면서 시스템이 깨질까 걱정할 필요없다. 테스트 케이스가 있어서. - 리팩터링 단계에서는 소프트웨어 설계 품질을 높이는 기법이라면 무엇이든 적용해도 괜찮다. 4) 중복을 없애..

23일차. 클린코드[4주차_ 금요일] 206-215pg #요약 11. 시스템 1) 도시를 세운다면? 2) 시스템 제작과 시스템 사용을 분리하라. 3) 확장 * 자바에서 사용하는 관점 or 관점과 유사한 메커니즘 3개 a. 자바 프록시 b. 순수 자바 AOP 프레임워크 c. AspectJ 관점 : 관심사를 관점으로 분리하는 가장 강력한 언어도구, 언어 차원에서 관점을 모듈화 구성으로 지원하는 자바 언어 확장. 4) 테스트 주도 시스템 아키텍쳐 구축 - 코드 수준에서 아키텍쳐 관심사를 분리할수 있으면 진정한 테스트 주도 아키텍처 구축이 가능해진다. 5) 의사결정을 최적화하라 - 의사결정을 최대한 미루는게 최선이며, 가장 적합한 사람에게 의사결정을 맡기면 좋다. 6) 명백한 가치가 있을 때 표준을 현명하게 사..

22일차. 클린코드[4주차_ 목요일] 198-205pg #요약 11. 시스템 1) 도시를 세운다면? 2) 시스템 제작과 시스템 사용을 분리하라. 가. Main 분리 : 시스템 생성과 시스템 사용을 분리하는 한 방법. 나. 팩토리 다. 의존성 주입 : 사용과 제작은 분리하는 강력한 메커니즘 하나. 의존성 관리 맥락에서 객체는 의존성 자체를 인스턴스로 만드는 책임은 지지 않고 이런 책임을 다른 '전담' 메커니즘에 넘겨야만 한다. 그렇게 제어를 역전한다. 3) 확장 - 소프트웨어 시스템은 '수명이 짧다'는 본질로 인해 아키텍처의 점진적인 발전이 가능하다. 가. 횡단(cross-cutting) 관심사 : 원론적으로는 모듈화되고 캡슐화된 방식으로 영속성 방식을 구상할 수있는데 현실적으로는 영속성 방식을 구현한 코..

21일차. 클린코드[4주차_ 수요일] 189-197pg #요약 10. 클래스 1) 클래스 체계 2) 클래스는 작아야 한다! 3) 변경하기 쉬운 클래스 가. 변경으로부터 격리 : 상세한 구현에 의존하는 클라이언트 클래스는 구현이 바뀌면 위험에 빠진다. - DIP Dependency Inversion Principle : 클래스가상세한구현이 아니라 추상화에 의존해야 한다는 원칡 11. 시스템 1) 도시를 세운다면? - 도시가 잘 돌아가는 이유는 적절한 추상화와 모듈화 때문. - 시스템 수준(높은 추상화 수준)에서도 깨끗함을 유지하는 방법 2) 시스템 제작과 시스템 사용을 분리하라. - 제작(construction)과 사용(use)은 아주 다르다. - 시작은 관심사(concern) - 흔히 쓰는 좀스럽고 손쉬..

20일차. 클린코드[4주차_ 화요일] 180-188pg #요약 10. 클래스 1) 클래스 체계 2) 클래스는 작아야 한다! 다. 응집도를 유지하면 작은 클래스 여럿이 나온다 : 클래스가 응집력을 잃는다면 쪼개라! 3) 변경하기 쉬운 클래스 - OCP Open-Closed Principle : 클래스는 확장에 개방적이고 수정에 폐쇄적이어야 한다는원칙 - 새 기능을 수정하거나 기존 기능을 변경할 때 건드릴 코드가 최소인 시스템 구조가 바람직하다.

18일차. 클린코드[3주차_ 토요일] 161-169pg #요약 9. 단위 테스트 - 제대로 된 테스트 케이스를 작성하자 1) TDD 법칙 세 가지 2) 깨끗한 테스트 코드 유지하기 3) 깨끗한 테스트 코드 a. 도메인에 특화된 테스트 언어 - 테스트를 구현하는 당사자와 나중에 테스트를 읽어볼 독자를 도와주는 테스트 언어 b. 이중표준 - 실제 환경에서는 절대로 안 되지만 테스트 환경에서는 전혀 문제없는 방식 - 대게 메모리나 CPU 효율과 관련있는 경우 4) 테스트 당 assert 하나 - assert문이 단 하나인 함수는 결론이 하나라서 코드를 이해하기 쉽고 빠르다. a. 테스트 당 개념 하나 - 테스트 함수마다 한 개념만 테스트하라 - 개념 당 assert 문 수를 최소로 줄여라 5) F.I.R.S...

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

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..

12일차. 클린코드[2주차_토요일] 103-110pg #요약 1. 깨끗한 코드 2. 의미 있는 이름 3. 함수 4. 주석 5. 형식 맟추기 1) 형식을 맞추는 목적 2) 적절한 행 길이를 유지하라 ㄹ. 수직거리 a) 변수 선언 b) 인스턴스 변수 : 인스턴스 변수는 클래스 맨 처음에 선언한다. 변수 간에 세로로 거리를 두지 않는다. c) 종속 함수 : 한 함수가 다른 함수를 호출한다면 두함수는 세로로 가까이 배치한다. d) 개념적 유사성 : 개념적 친화도가 높을수록 코드를 가까이 배치한다. ㅁ. 세로순서 - 호출되는 함수를 호출하는 함수보다 나중에 배치한다. 가장 중요한 개념을 가장 먼저 표현 3) 가로 형식 맞추기 - 한 행은 가로로 보통 20자~60자 사이의 길이다. 짧은 행을 선호한다. ㄱ. 가로 ..

10일차. 클린코드[2주차_목요일] 84-94pg #요약 1. 깨끗한 코드 2. 의미 있는 이름 3. 함수 4. 주석 1) 주석은 나쁜 코드를 보완하지 못한다. 2) 코드로 의도를 표현하라! 3) 좋은 주석 4) 나쁜 주석 // 함수나 변수로 표현할 수 있다면 주석을 달지 마라 // 위치를 표시하는 주석 : 특히 뒷부분에 / 로 이어지는 잡음은 제거하는 편이 좋다. 배너를 남용하면 독자가 흔한 잡음으로 여겨 무시한다. // 닫는 괄호에 다는 주석 : 닫는 괄호에 주석을 달기 보다는 함수를 줄이려 노력하라 // 공로를 돌리거나 저자를 표시하는 주석 : 이런 정보는 소스 코드 관리 시스템에 저장하는 편이 좋다. // 주석으로 처리한 코드 : 삭제해도 된다. 잃어버릴 염려 없다. 약속한다. ㅋㅋ // HTML..