집에가고싶을때마다

•  About
•  Project
•  IT
•  Travel
•  ETC

Clean Code 17장, 냄새와 휴리스틱 주석 C1: 부적절한 정보 - 다른 시스템에 저장할 정보는 주석으로 적절하지 못함 ex) 소스코드 관리 시스템, 버그 추적 시스템, 이슈 추적 시스템 등 - 변경 이력과 장황한 날짜는 소스 코드를 번잡하게 만듦 - 작성자, 최종 수정일, SPR 번호등만 주석으로 삽입 C2: 쓸모 없는 주석 - 오래된 주석, 엉뚱한 주석, 잘못된 주석 들은 빠르게 삭제 C3: 중복된 주석 - 설명하는 주석 주의 ex) i++ // i 증가 C4: 성의 없는 주석 - 작성 할 가치가 있으면 간결하고 명료하게 작성 C5: 주석 처리된 코드 - 주석 처리된 코드는 즉각 지워버려야 함 환경 E1: 여러 단계로 빌드 - 빌드는 간단히 한 단계로 끝나야 함 - 소스코드 관리 시스템에서 이..

Clean Code 15장, JUnit 들여다보기 자바 프레임워크 중 가장 유명한 JUnit에 대한 평가 ComparisonCompactor 두 문자열의 차이를 받아 반환하는 모듈, 오류를 파악할 때 유용 ex) ABCDE와 ABXDE 비교 시, 반환 > 리팩토링 방법은 책 참조 1. 변수 이름에 범위 명시X 2. 조건문 캡슐화 3. 부정문 대신 긍정문 사용 4. 시간적인 결합에 주의 ( A -> B로 반드시 실행되야 하는 경우): 인수로 넘겨주기 or 이름 바꾸기 ... 16장, SerialDate 리팩터링 - 코드 커버리지 분석 도구인 클로버를 이용해 단위테스트가 실행하는 코드와 실행하지 않는 코드 조사 - 한 소스코드에 여러 언어 사용X - 부모 클래스는 자식을 몰라야 함 - 주석 제거 .... 책..

Clean Code 14장, 점진적 개선 - 출발은 좋았으나 확장성이 부족했던 모듈 - 모듈을 개선하고 정리하는 단계: 위에서 아래로 자연스럽게 읽혀야 함 - 깨끗한 코드를 짜기 위해서는 지저분한 코드를 먼저 짠 뒤에 정리를 해야 함 점진적 개선 - 개선이라는 이름 아래 구조를 크게 뒤집는 행위는 프로그램을 망친다. - 테스트 주도 개발(TDD) 기법을 사용하여 시스템을 망가뜨리는 변경을 허용하지 않음 > 한 번에 하나씩 고침, 테스트 케이스를 하나라도 실패하면 다음으로 넘어가지 않음 ex. 반복되는 코드를 함수로 옮길 때, 먼저 함수에 다 넣은 후, 파생 클래스를 만들어서 분산하고 이후에 추상화, set, get 등 함수를 만드는 등 단계를 나눠서 진행해야 함 > 중간 중간에 테스트를 진행하면서 기능 ..

Clean Code 13장, 동시성 동시성과 깔끔한 코드는 양립하기 어려움 여러 스레드를 동시에 돌리는 이유, 여러 스레드를 동시에 돌리면 왜 어려울까? 그리고 이러한 어려움에 대처하고 깨끗하게 코드는 어떻게 작성할 수 있을까? 1. 동시성이 필요한 이유 동시성: 결합(coupling)을 없애는 전략, 처리량(throughput) 개선 - 무엇과 언제를 분리 ex. 단일 스레드: breakpoint를 정해서 디버깅하여 시스템 상태 파악 멀티 스레드: 구조적 관점에서 작은 협력 프로그램 여럿으로 보이게 되어 시스템 이해가 쉬워짐 ex. 서블릿 - 컨테이너는 동시성을 부분적으로 관리: 웹 요청이 들어올 때, 웹 서버는 비동기식으로 서빌릿 실행, 서블릿 프로그래머는 웹 요청을 ㅗ간리하지 않아도 됨 - 정보를 ..

Clean Code 12장, 창발성 켄트 벡이 제시한 단순한 설계 규칙 네가지가 소프트웨어 설계 품질을 크게 높여준다. 1. 모든 테스트를 실행한다. 2. 중복을 없앤다. 3. 프로그래머 의도를 표현한다. 4. 클래스와 메서드 수를 최소로 줄인다. 1. 단순 설계 규칙 1: 모든 테스트를 실행하라 - 설계는 의도한 대로 돌아가는 시스템을 내놓아야 한다. 그러나 시스템이 의도한 대로 돌아가는지 검증할 간단한 방법이 없다면? - 테스트가 불가능한 시스템은 검증도 불가능하다. 테스트가 가능한 시스템을 만들려고 하면 설계 품질이 높아진다. - SRP(단일 책임 원칙)를 준수하는 클래스는 테스트가 훨씬 쉽다. - 결합도가 높으면 테스트케이스를 작성하기 어려움 > 테스트케이스에 맞춰 만들면 결합도가 낮고 응집력이 ..

Clean Code 11장, 시스템 복잡성은 죽음이다. 1. 소프트웨어 = 도시 - 도시를 세울 때, 혼자서 직접 관리하기는 어렵지만 각 분야를 관리하는 팀으로 나뉨 > 작은 사항에 집중 할 수 있음 > 추상화와 모듈화: '구성요소'가 효율적으로 돌아감 - 소프트웨어에서도 낮은 추상화 수준에서 관심사를 분리해야함 - 시스템 수준에서의 깨끗함 유지 2. 시스템 제작과 시스템 사용 분리 - 제작(Construction)과 사용(Use)은 다르다. > 소프트웨어 시스템(애플리케이션 객체를 제작하고 의존성을 서로 연결)은 준비과정과 런타임 로직을 분리해야 함 - 시작 단계: 관심사(Concern) 분리 Bad Code //초기화 지연(Lazy Initialization) == 계산 지연(Lazy Evaluati..

Clean Code 10장, 클래스 깨끗한 클래스란 1. 클래스 체계 - 클래스를 정의하는 표준 자바 관례: 추상화 단계로 순차적으로 내려감 정적(static), 공개(public) 상수 -> 정적 비공개(private) -> 비공개 인스턴스 변수 -> 공개 함수 -> 비공개 함수 캡슐화 변수와 유틸리티 함수는 가능한 숨기는 게 좋음 - protected: 변수나 유틸리티 함수에 테스트 코드가 접근 가능하도록 허용 why? 테스트가 매우 중요하기 때문 - 비공개 상태를 유지할 방법을 찾아야 함 2. 클래스는 작아야 함 - 클래스나 함수는 항상 '작게'가 기본 규칙이다. - 클래스의 크기는 '책임'으로 나눔 ex. SuperDashboard는 약 70개의 method로 이루어짐: 책임이 너무 많음 - 클래..

Clean Code 9장, 단위 테스트(TDD: Test Driven Development) - 코드가 제대로 도는지 확인하여, 지속가능하게 사용 가능한 테스트 코드를 작성하는 것이 중요 > 테스트 케이스를 모두 구현하고 통과한 후, 다른 사람들에게 공개해야 함 - 애자일과 TDD로 단위 테스트를 자동화하고 제대로 된 테스트 케이스를 작성해야 함 1. TDD 법칙 세가지 1) 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않음 2) 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트 작성 3) 현재 실패하는 테스트를 통과할 정도로만 실제 코드 작성 - 개발과 테스트가 대략 30초 주기로 묶임 - 그러나 많은 테스트 코드는 심각한 관리 문제를 유발함 2. 깨끗한 테스트 코드 유지 ..

Clean Code 8장, 경계 외부 코드를 우리 코드에 깔끔하게 통합하는 방법 1. 외부 코드 사용하기 - 인터페이스 제공자와 인터페이스 사용자 사이의 경계 > 인터페이스 제공자: 적용성을 최대한 넓힘 > 사용자: 요구에 집중하기를 원함 ex) java.util.Map: 제공하는 기능성과 유연성으로 인해 유용함 > 그러나 위험 ⬆ - Map을 사용하는 누구든 Map의 내용을 지울 수 있음 2. 경계 살피고 익히기 - 타사 라이브러리의 사용법이 분명하지 않을 때 > 문서를 읽어서 사용 ➡ 우리쪽 코드를 작성하여 라이브러리가 동작하는지 확인 - 학습 테스트: 간단한 테스트 케이스를 작성하여 외부 코드를 먼저 익히기 3. 아파치의 log4j - 문서를 읽기전 테스트 케이스 작성 4. 학습 테스트 - 학습 테..

Clean Code - 로버트 C. 마틴 7장, 오류 처리 - 잘못된 것을 바로 잡을 책임 1. 오류 코드보다 예외를 사용 - 오류 코드를 사용하면 함수를 호출한 즉시 오류를 확인해야 함 - 예외를 던지면 호출자의 코드가 깔끔해짐 2. Try-Catch-Finally 문부터 작성 - 예외 프로그램 안에 범위 정의 - try 블록에 들어가는 코드를 실행하면서 어느 시점에서든 실행이 중단된 후 catch 블록을 넘어갈 수 있음 - try-catch 블록은 프로그램 상태를 일관성 있게 유지해야 함 ▶️ try 블록에서 생기는 일들에 대해 호출자가 기대하는 상태를 정의하기 쉬움 - 단위 테스트를 구현할 때, 강제로 예외를 일으키는 테스트케이스를 작성하여 try-catch문 구현 진행 3. 미확인(unchechk..