집에가고싶을때마다

•  About
•  Project
•  IT
•  Travel
•  ETC

12장, 컴포넌트 컴포넌트란? 배포 단위 ex) 자바의 jar - 컴포넌트롤 서로 링크하여 실행 가능한 단일 파일로 생성 할 수 있음 ex) .exe, .dll 역사 ... 일부 생략 ... - 링커: 프로그래머가 느린 부분을 처리해주는 링크 과정 처리, 링크가 완료된 재배치 코드를 만듦 -> 로드 속도 향상 = 한 번 만들어둔 실행 파일을 언제나 빠르게 로드 가능 1980년대: 소스 모듈 .c -> .o 컴파일된 후, 링커로 전달되어 로드될 수 있는 실행파일로 만들어 짐 -> 컴파일은 빨랐지만, 링커에서 더 많은 시간이 걸리게 됨 1980년대 후반: 무어의 법칙의 등장으로 디스크가 작아지고 빨라짐 1990년대 후반: 프로그램 링크 속도가 줄어들고, .jar 파일 등 등장 현재: .jar를 기본 애플리케..

SOLID - 함수와 데이터 구조를 클래스로 배치하고 결합하는 방법 종류 SRP: 단일 책임 원칙 - 소프트웨어 모듈은 변경 이유가 하나여야 함 OCP: 개방-폐쇄 원칙 - 기존 코드를 수정하기 보다 새로운 코드를 추가하는 방법으로 행위를 변경해야 함 LSP: 리스코프 치환 원칙 - 상호 대체 가능한 구성요소를 이용해 소프트웨어 시스템을 만들 수 있으려면, 구성요소는 반드시 서로 치환 가능해야 함 ISP: 인터페이스 분리 원칙 - 소프트웨어 설계자는 사용하지 않은 것에 의존하지 않아야 함 DIP: 의존성 역전 원칙 - 고수준 정책을 구현하는 코드는 저수준 세부사항을 구현하는 코드에 의존해서는 안됨 > 세부사항이 정책에 의존 장점 - 변경에 유연 - 이해하기 쉬움 - 컴포넌트 기반 7장, SRP: 단일 책..

Clean Architecture 2부, 프로그래밍 패러다임 패러다임이란 - 프로그래밍을 하는 방법, 언어에 독립적 -어떤 프로그래밍 구조를 사용할 지, 언제 이 구조를 사용해야 하는 지 결정 3장, 패러다임 개요 3가지 패러다임: 구조적 프로그래밍, 객체지향 프로그래밍, 함수형 프로그래밍 구조적 프로그래밍 - 최초로 적용된 패러다임 - 무부별한 점프(goto문장)은 프로그램에 해로움 -> if/then/else, do/while/until 등 구조로 변경 - 제어 흐름의 직접적인 전환에 대해 규칙을 부과 객체 지향 프로그래밍 - 스택 프레임을 힙으로 옮기면 함수 호출이 반환된 이후에도 함수에서 선언된 지역 변수가 오랫동안 유지할 수 있음을 발견 -> 클래스의 생성자 - 지역 변수 = 인스턴스 변수, 중..

Clean Architecture 1장, 설계와 아키텍처 좋은 설계란? 소프트웨어 아키텍처의 목표는 필요한 시스템을 만들고 유지보수 하는 데 투입 인력을 최소화 하는 것에 있다. - 생산성은 낮아지고, 비용을 올라가면 좋지 않은 아키텍처 - 엉망진창인 코드가 쌓이면 결국 생산성은 0으로 수렴 - 자신을 과시하면 재설계 해도 원래 프로젝트와 똑같이 엉망으로 됨 > 재설계가 좋은 방향은 아니다. 그래서 소프트웨어 아키텍처는 - 과신을 미리 방지해서 소프트웨어 품질을 고민해야 한다. - 비용은 최소화하고 생산성은 최대화하는 아키텍처란 2장, 두 가지 가치에 대한 이야기 소프트웨어 개발자가 반드시 높게 가치를 유지해야 하는 것: 행위, 구조 행위 - 기계가 수익을 창출하거나 비용을 절약하도록 만들기 위해서 소프..

드디어 한 달 한 권 1번째 책을 다 읽었다. 먼저, 간단 후기를 말하자면 매우 유용했다. 그러나 약 500페이지가 되는 책에서 핵심 내용은 앞 부분에 몰려있고, 뒤에는 반복되는 예시들이었다. 책을 추천하자면 5점 만점에 4.5점정도로 강추하는 책이다. 왜 Clean Code였는가? 첫 번째 책을 무엇으로 할 건지에 대한 고민은 별로 하지 않았다. 많은 개발자들이 추천하는 필독도서인 Clean Code, 그 필요성에 대해서 늘 느꼈기 때문이다. 그리고 실제로 현업에서 ASIS 소스를 TOBE로 옮기면서 Clean Code에 대해 많이 생각하게 되었다. 만약 변수명이 좀 더 의미를 가지고 있었다면, 이렇게 분석하기 어렵지는 않지 않았을까? 하나의 함수가 하나의 기능만 가지고 있었다면, 좀 더 쉬웠을까? 그..

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(단일 책임 원칙)를 준수하는 클래스는 테스트가 훨씬 쉽다. - 결합도가 높으면 테스트케이스를 작성하기 어려움 > 테스트케이스에 맞춰 만들면 결합도가 낮고 응집력이 ..