시스템
도시를 세운다면
- 도시는 큰 그림을 그리는 사람과 작은 사항에 집중하는 사람들이 모여서 제대로 된 기능을 한다
- 추상화와 모듈화로 시스템을 깨끗하게 유지가능
시스템 제작과 시스템 사용을 분리하라
- 시스템웨어 시스템은 준비과정과 런타임 로직으로 분리를 해야한다
- 관심사 분리를 하자
의존성 주입
- 사용과 제작을 분리하는 메커니즘 중 하나
- 제어 역전 : 한 객체가 맡은 보조 책임을 새로운 객체에게 넘기는 것 , 새로운 객체는 넘겨받은 책임으로 단일 책임 우너칙을 지킨다
- 보통 필요한 객체는 실행시점에서 이미 만들어져있고 생성자 인수나 설정자 메서드를 사용해서 의존성을 설정한다
확장
- 처음부터 어떻게 규모를 다 알고 설계하냐? 처음엔 작게 그리고 점차 키우는게 정석이다
- 오늘 주어진 사용자 스토리에 맞춰 구현하고 주기적으로 새로운 스토리에 맞춰 개발하는 것이 애자일 방식의 핵심
테스트 주도 시스템 아키텍쳐 구축
- 코드 수준에서 아키텍쳐 관심사 분리가 가능하면 테스트 주도 아키텍처 구축 가능
- 방향이 확고하면 작게 만든 후 점차 규모를 키워도 오케이
창발성
창벌적 설계로 깔끔한 코드를 구현하자
1) 모든 테스트를 실행한다
2) 중복을 없앤다
3) 프로그러머 의도를 표현한다
4) 클래스와 메서드 수를 최소로 줄인다
모든 테스트를 실행하라
- 문서도 좋지만 코드도 검증이 필요하다
- 테스트 케이스를 많이 작성할 수록 DIP원칙과 의존성 주입 , 추상화 , 인터페이스를 사용해서 결합도를 낮춰야한다
- 테스트 케이스 작성이 끝나면 코드와 클래스를 리팩터링 해가면서 검증이 필요할 때마다 케이스를 실행하면 됨
중복을 없애라
- 적은 양이라도 공통적인 코드를 뽑아내자
표현하라
- 내가 생각하는 코드보다 다른 사람이 볼 때 좋은 코드로 표현하기 위해선 의도를 분명히 표현해야한다
- 좋은 이름을 선택하자
- 함수와 클래스 크기를 줄이자
- 단위테스트를 꼼꼼하게 작성하자
- 표준 명칭을 사용하자
클래스와 메서드 수를 줄여라
- 가능한 줄이는 것이 유지 보수하긴 편함
- 다만 테스트 케이스와 중복 없애기 , 표현하는 작업이 더 중요하다
동시성
동시성이 필요한 이유?
- 무엇과 언제를 분리하는 전략
- 스레드가 하나면 무엇과 언제가 밀접함 , 단일 스레드면 디버깅에서 브레이크 포인트로 디버깅 가능
미신과 오해
- 동시성은 항상 성능을 높여주진 않고 설계도 크게 바뀐다.
- 동시성은 복잡하며 다소 부하를 유발한다
- 동시성 구현을 위해선 설계 전략을 재고해야함
난관
- 두 스레드가 같은 변수를 참조하면 모두 같은 변수를 공유하게 됨
동시성 방어 원칙
- 단일 책임 우너칙 : 주어진 메서드, 클래스, 컴포넌트 변경할 이유가 하나여야한다.
따름 정리
1)자료 범위를 제한하라
- 임계 영역 : 두 스레드가 동일 필드 공유 및 수정할 떄 서로 간섭하여 예상못한 결과를 내놓는데 이를 방지하기 위한 방안 중 하나 / synchronized 키워드로 보호
2) 자료 사본을 사용하라
- 처음부터 공유하지 마라
- 객체를 복사해서 읽기 전용을 ㅗ사용해라
3) 스레드는 간으한 독립적으로 구현하라
- 다른 스레드와 자료 공유하지 않도록 하라
참고
https://product.kyobobook.co.kr/detail/S000001032980
'도서' 카테고리의 다른 글
객체지향의 사실과 오해 (1) | 2024.09.06 |
---|---|
클린코드 : 점진적인 개선 (0) | 2024.07.27 |
클린 코드 : 오류 처리 , 경계 , 단위 테스트, 클래스 (1) | 2024.07.14 |
클린코드 : 객체와 자료 구조 (0) | 2024.07.07 |
클린코드 : 형식 맞추기 (0) | 2024.07.07 |
하고 싶은 걸 하고 되고 싶은 사람이 되자!
포스팅이 좋았다면 "좋아요❤️" 또는 "구독👍🏻" 해주세요!