reviews/Clean Code (16) 썸네일형 리스트형 16. SerialDate 리팩터링 JCommon 라이브러리의 SerailDate 클래스 코드 커버리지 분석 도구 클로버Clover를 사용하면 단위테스트가 실행하는 코드와 실행하지 않는 코드를 조사할 수 있다. 15. JUnit 들여다보기 회고 지금 저자만 신난 것 같은데.. 14. 점진적인 개선 깨끗한 코드를 짜려면 먼저 지저분한 코드를 짠 뒤에 정리해야 한다. 코드에 개선이 필요할 때 코드 구조를 유지보수하기 좋은 상태로 만들려면 기능 추가를 밀어붙이지 말고 당장 리팩토링을 시작해야 한다. 프로그램을 망치는 가장 좋은 방법 중 하나는 개선이라는 이름 아래 구조를 크게 뒤집는 행위이다. 변경 후에도 시스템이 변경 전과 똑같이 돌아가야 하므로 테스트 주도 개발 Test-Driven Development, TDD 를 사용해야 한다. 지저분한 소스를 점진적으로 고치며 테스트를 반복해 시스템을 망가뜨리지 않았는지 확인해야 한다. 13. 동시성 동시성은 결합을 없애는 전략이다. 즉, 무엇과 언제를 분리하는 전략이다. 동시성 동시성은 때로 성능을 높여준다. 동시성을 구현하면 설계가 판이하게 달라진다. 컨테이너가 어떻게 동작하는지, 어떻게 동시 수정, 데드락 등과 같은 문제를 피할 수 있는지 알아야 한다. 다소 부하를 유발한다. 복잡하다. 동시성 버그는 재현하기 어렵다. 동시성 방어 원칙 단일 책임 원칙 Single Responsibility Principle, SRP : 주어진 메서드/클래스/컴포넌트를 변경할 이유가 하나여야 한다는 원칙 동시성을 구현할 때 고려해야 하는 것 동시성 코드는 독자적인 개발, 변경, 조율 주기가 있다. 동시성 코드에는 독자적인 난관이 있다. 잘못 구현한 동시성 코드는 별의별 방식으로 실패한다. 자료 범위를 제한하라. .. 12. 창발성 창발적 설계 1. 모든 테스트를 실행하라. 시스템은 설계한 의도대로 돌아가야 하며 이를 검증할 테스트가 가능한 시스템이어야 한다. 2. 중복을 없애라. 깔끔한 시스템을 만들려면 단 몇줄이라도 중복을 제거하겠다는 의지가 필요하다. 표현하라. 코드는 개발자의 의도를 분명히 표현해야 한다. 좋은 이름을 선택한다. 함수와 클래스 크기를 가능한 줄인다. 표준 명칭을 사용한다. 단위 테스트 케이스를 꼼꼼히 작성한다. 클래스와 메서드 수를 최소로 줄여라. 하지만 이건 우선순위가 낮다. 리팩토링 하라. SRP 참고 > https://sjh836.tistory.com/159 11. 시스템 설정 논리는 일반 실행 논리와 분리해야 모듈성이 높아진다. Main 분리 생성과 관련한 코드는 모두 main이나 main이 호출하는 모듈로 옮기고, 나머지 시스템은 모든 객체가 생성되었고 모든 의존성이 연결되었다고 가정한다. 애플리케이션은 main이나 객체가 생성되는 과정을 전혀 모른다. 팩토리 객체가 생성되는 시점을 애플리케이션이 결정해야 하는 경우 ABSTRACT FACTORY 패턴을 사용한다. 의존성 주입 Dependency Injection, DI 제어 역전(Inversion of Control, IoC) 기법을 의존성 관리에 적용한 메커니즘이다. .... 중간부분은 스프링 공부 후 다시 읽어보는 게 좋겠다... 테스트 주도 시스템 아키텍처 구축 코드 수준에서 아케텍처 관심사를 분리할 수 있다면 .. 10. 클래스 클래스 체계 변수 목록 정적 공개 상수 static public 정적 비공개 변수 static private 비공개 인스턴스 변수 공개 변수 (거의 없다) 공개 함수 비공개 함수 (자신을 호출하는 공개 함수 직후) => 추상화 단계가 순차적으로 내려감 클래스는 작아야 한다 응집도가 높은 클래스를 선호한다. 몇몇 메서드만이 사용하는 인스턴스 변수가 아주 많아지면 클래스를 쪼개야 한다는 신호다. 클래스를 쪼갤 수록 프로그램에 점점 더 체계가 잡히고 구조가 투명해진다. 단일 책임 원칙 (SRP) 클래스나 모듈을 변경할 이유가 단 하나뿐이어야 한다는 원칙 객체 지향 설계에서 중요한 개념 클래스를 쪼갤 수록 프로그램에 점점 더 체계가 잡히고 구조가 투명해진다.는 말이 이해는 되는데 선뜻 적용하기 어렵게 느껴진다... 09. 단위 테스트 실제 코드를 짜기 전에 단위 테스트부터 짜라 TDD의 법칙 세 가지 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. 깨끗한 테스트 코드 실제 코드가 진화하면 테스트 코드도 변해야 한다. 테스트 코드가 지저분할 수록 부담이 늘어난다. 깨끗한 테스트 코드는 실제 코드의 변경을 쉽게해서 유연성, 유지보수성, 재사용성을 제공한다. 설계와 아키텍처를 최대한 깨끗하게 보존하는 열쇠다. Fast 빠르게 테스트가 느리면 자주 돌리지 못하게 되어 결국 코드 품질이 망가진다. Independent 독립적으로 각 테스트는 서로 의존하면 안된다. 한 테스트가 다음 테스.. 이전 1 2 다음
