닭발개발

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 : 클래스는 확장에 개방적이고 수정에 폐쇄적이어야 한다는원칙 - 새 기능을 수정하거나 기존 기능을 변경할 때 건드릴 코드가 최소인 시스템 구조가 바람직하다.

19일차. 클린코드[4주차_ 월요일] 170-179pg #요약 10. 클래스 - 깨끗한 클래스 만들기 1) 클래스 체계 - 클래스를 정의하는 표준 자바 관례에 따르면, 추상화 단계가 순차적으로 내려간다. 가. 캡슐화 : 변수와 유틸리티 함수는 반드시 숨겨야 한다. 캡슐화를 푸는 것은 언제나 최후의 수단 2) 클래스는 작아야 한다! - 클래스의 첫째는 크기, 둘째도 크기. 작아야 한다. - 얼마나? 클래스가 맡은 책임을 기준으로. 한 클래스에 책임이 너무 많으면 안됨 - 클래스 설명은 25단어 내외로 해야함. 가. 단일 책임 원칙(SRP, Single Responsibility 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. 현재 실패하는 테스트를 통과..

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

15일차. 클린코드[3주차_수요일] 132-141pg #요약 7. 오류처리 - 뭔가 잘못될 가능성은 항상 존재하고 그것을 바로 잡을 책임은 프로그래머들에게 있다. - 우아하고 고상하게 오류처리하는 법 1) 오류 코드보다 예외를 사용하라 2) Try-Catch-Finally 문부터 작성하라 - 강제로 예외를 일으키는 테스트 케이스를 작성한 후 테스트를 통과하게 코드를 작성하는 방법이 좋다. 3) 미확인(unchecked) 예외를 사용하라 - 확인된 예외는 잘 쓰지 않는다. - 확인된 오류가 치르는 비용에 상응하는 이익을 제공하는지 따져봐야한다. 확인된 예외는 OCP(Open Closed Principal)를 위반한다. - 확인된 예외는 캡슐화를 깨버리는 현상이 일어날 수 있다. 4) 예외에 의미를 제공하라..