반응형 SMALL Clean code15 [Clean Code] 17장, 냄새와 휴리스틱 Clean Code 17장, 냄새와 휴리스틱 주석 C1: 부적절한 정보 - 다른 시스템에 저장할 정보는 주석으로 적절하지 못함 ex) 소스코드 관리 시스템, 버그 추적 시스템, 이슈 추적 시스템 등 - 변경 이력과 장황한 날짜는 소스 코드를 번잡하게 만듦 - 작성자, 최종 수정일, SPR 번호등만 주석으로 삽입 C2: 쓸모 없는 주석 - 오래된 주석, 엉뚱한 주석, 잘못된 주석 들은 빠르게 삭제 C3: 중복된 주석 - 설명하는 주석 주의 ex) i++ // i 증가 C4: 성의 없는 주석 - 작성 할 가치가 있으면 간결하고 명료하게 작성 C5: 주석 처리된 코드 - 주석 처리된 코드는 즉각 지워버려야 함 환경 E1: 여러 단계로 빌드 - 빌드는 간단히 한 단계로 끝나야 함 - 소스코드 관리 시스템에서 이.. 2021. 11. 21. [Clean Code] 15장, 16장, 코드 리팩토링 해보기 Clean Code 15장, JUnit 들여다보기 자바 프레임워크 중 가장 유명한 JUnit에 대한 평가 ComparisonCompactor 두 문자열의 차이를 받아 반환하는 모듈, 오류를 파악할 때 유용 ex) ABCDE와 ABXDE 비교 시, 반환 > 리팩토링 방법은 책 참조 1. 변수 이름에 범위 명시X 2. 조건문 캡슐화 3. 부정문 대신 긍정문 사용 4. 시간적인 결합에 주의 ( A -> B로 반드시 실행되야 하는 경우): 인수로 넘겨주기 or 이름 바꾸기 ... 16장, SerialDate 리팩터링 - 코드 커버리지 분석 도구인 클로버를 이용해 단위테스트가 실행하는 코드와 실행하지 않는 코드 조사 - 한 소스코드에 여러 언어 사용X - 부모 클래스는 자식을 몰라야 함 - 주석 제거 .... 책.. 2021. 11. 19. [Clean Code] 14장, 점진적인 개선 Clean Code 14장, 점진적 개선 - 출발은 좋았으나 확장성이 부족했던 모듈 - 모듈을 개선하고 정리하는 단계: 위에서 아래로 자연스럽게 읽혀야 함 - 깨끗한 코드를 짜기 위해서는 지저분한 코드를 먼저 짠 뒤에 정리를 해야 함 점진적 개선 - 개선이라는 이름 아래 구조를 크게 뒤집는 행위는 프로그램을 망친다. - 테스트 주도 개발(TDD) 기법을 사용하여 시스템을 망가뜨리는 변경을 허용하지 않음 > 한 번에 하나씩 고침, 테스트 케이스를 하나라도 실패하면 다음으로 넘어가지 않음 ex. 반복되는 코드를 함수로 옮길 때, 먼저 함수에 다 넣은 후, 파생 클래스를 만들어서 분산하고 이후에 추상화, set, get 등 함수를 만드는 등 단계를 나눠서 진행해야 함 > 중간 중간에 테스트를 진행하면서 기능 .. 2021. 11. 14. [Clean Code] 13장, 동시성 Clean Code 13장, 동시성 동시성과 깔끔한 코드는 양립하기 어려움 여러 스레드를 동시에 돌리는 이유, 여러 스레드를 동시에 돌리면 왜 어려울까? 그리고 이러한 어려움에 대처하고 깨끗하게 코드는 어떻게 작성할 수 있을까? 1. 동시성이 필요한 이유 동시성: 결합(coupling)을 없애는 전략, 처리량(throughput) 개선 - 무엇과 언제를 분리 ex. 단일 스레드: breakpoint를 정해서 디버깅하여 시스템 상태 파악 멀티 스레드: 구조적 관점에서 작은 협력 프로그램 여럿으로 보이게 되어 시스템 이해가 쉬워짐 ex. 서블릿 - 컨테이너는 동시성을 부분적으로 관리: 웹 요청이 들어올 때, 웹 서버는 비동기식으로 서빌릿 실행, 서블릿 프로그래머는 웹 요청을 ㅗ간리하지 않아도 됨 - 정보를 .. 2021. 11. 14. [Clean Code] 12장, 창발성 Clean Code 12장, 창발성 켄트 벡이 제시한 단순한 설계 규칙 네가지가 소프트웨어 설계 품질을 크게 높여준다. 1. 모든 테스트를 실행한다. 2. 중복을 없앤다. 3. 프로그래머 의도를 표현한다. 4. 클래스와 메서드 수를 최소로 줄인다. 1. 단순 설계 규칙 1: 모든 테스트를 실행하라 - 설계는 의도한 대로 돌아가는 시스템을 내놓아야 한다. 그러나 시스템이 의도한 대로 돌아가는지 검증할 간단한 방법이 없다면? - 테스트가 불가능한 시스템은 검증도 불가능하다. 테스트가 가능한 시스템을 만들려고 하면 설계 품질이 높아진다. - SRP(단일 책임 원칙)를 준수하는 클래스는 테스트가 훨씬 쉽다. - 결합도가 높으면 테스트케이스를 작성하기 어려움 > 테스트케이스에 맞춰 만들면 결합도가 낮고 응집력이 .. 2021. 11. 13. [Clean Code] 11장, 시스템 Clean Code 11장, 시스템 복잡성은 죽음이다. 1. 소프트웨어 = 도시 - 도시를 세울 때, 혼자서 직접 관리하기는 어렵지만 각 분야를 관리하는 팀으로 나뉨 > 작은 사항에 집중 할 수 있음 > 추상화와 모듈화: '구성요소'가 효율적으로 돌아감 - 소프트웨어에서도 낮은 추상화 수준에서 관심사를 분리해야함 - 시스템 수준에서의 깨끗함 유지 2. 시스템 제작과 시스템 사용 분리 - 제작(Construction)과 사용(Use)은 다르다. > 소프트웨어 시스템(애플리케이션 객체를 제작하고 의존성을 서로 연결)은 준비과정과 런타임 로직을 분리해야 함 - 시작 단계: 관심사(Concern) 분리 Bad Code //초기화 지연(Lazy Initialization) == 계산 지연(Lazy Evaluati.. 2021. 11. 7. 이전 1 2 3 다음 반응형 LIST
