음성 검색
QR/바코드 검색
품목정보
| 발행일 | 2013년 12월 24일 |
|---|---|
| 쪽수, 무게, 크기 | 584쪽 | 950g | 188*254*35mm |
| ISBN13 | 9788966260959 |
| ISBN10 | 8966260950 |
로버트 C. 마틴 저 / 박재호,이해영 역
|
인사이트(insight)
|
2013년 12월 24일
저자/출판사 더보기/감추기
- IT 모바일 8위 | IT 모바일 top20 137주
- eBook
26,400원이동 - 이미 소장하고 있다면 판매해 보세요! 이 상품 팔기 매입가 8,300원 더보기/감추기
![[대학생X취준생] 학점/시험/취업 모두 파이팅 해야지!](https://image.yes24.com/sysimage/renew/loadSpace.png)
관련분류
이 상품의 태그
책소개 책소개 보이기/감추기
목차 목차 보이기/감추기
| 1장 깨끗한 코드 코드가 존재하리라 나쁜 코드 나쁜 코드로 치르는 대가 __ 원대한 재설계의 꿈 __ 태도 __ 원초적 난제 __ 깨끗한 코드라는 예술? __ 깨끗한 코드란? 우리들 생각 우리는 저자다 보이스카우트 규칙 프리퀄과 원칙 결론 참고 문헌 2장 의미 있는 이름 들어가면서 의도를 분명히 밝혀라 그릇된 정보를 피하라 의미 있게 구분하라 발음하기 쉬운 이름을 사용하라 검색하기 쉬운 이름을 사용하라 인코딩을 피하라 __ 헝가리식 표기법 __ 멤버 변수 접두어 __ 인터페이스 클래스와 구현 클래스 자신의 기억력을 자랑하지 마라 클래스 이름 메서드 이름 기발한 이름은 피하라 한 개념에 한 단어를 사용하라 말장난을 하지 마라 해법 영역에서 가져온 이름을 사용하라 문제 영역에서 가져온 이름을 사용하라 의미 있는 맥락을 추가하라 불필요한 맥락을 없애라 마치면서 3장 함수 작게 만들어라! __ 블록과 들여쓰기 한 가지만 해라! __ 함수 내 섹션 함수 당 추상화 수준은 하나로! __ 위에서 아래로 코드 읽기: 내려가기 규칙 Switch 문 서술적인 이름을 사용하라! 함수 인수 __ 많이 쓰는 단항 형식 __ 플래그 인수 __ 이항 함수 __ 삼항 함수 __ 인수 객체 __ 인수 목록 __ 동사와 키워드 부수 효과를 일으키지 마라! __ 출력 인수 명령과 조회를 분리하라! 오류 코드보다 예외를 사용하라! __ Try/Catch 블록 뽑아내기 __ 오류 처리도 한 가지 작업이다. __ Error.java 의존성 자석 반복하지 마라! 구조적 프로그래밍 함수를 어떻게 짜죠? 결론 참고 문헌 4장 주석 주석은 나쁜 코드를 보완하지 못한다 코드로 의도를 표현하라! 좋은 주석 __ 법적인 주석 __ 정보를 제공하는 주석 __ 의도를 설명하는 주석 __ 의미를 명료하게 밝히는 주석 __ 결과를 경고하는 주석 __ TODO 주석 __ 중요성을 강조하는 주석 __ 공개 API에서 Javadocs 나쁜 주석 __ 주절거리는 주석 __ 같은 이야기를 중복하는 주석 __ 오해할 여지가 있는 주석 __ 의무적으로 다는 주석 __ 이력을 기록하는 주석 __ 있으나 마나 한 주석 __ 무서운 잡음 __ 함수나 변수로 표현할 수 있다면 주석을 달지 마라 __ 위치를 표시하는 주석 __ 닫는 괄호에 다는 주석 __ 공로를 돌리거나 저자를 표시하는 주석 __ 주석으로 처리한 코드 __ HTML 주석 __ 전역 정보 __ 너무 많은 정보 __ 모호한 관계 __ 함수 헤더 __ 비공개 코드에서 Javadocs __ 예제 참고 문헌 5장 형식 맞추기 형식을 맞추는 목적 적절한 행 길이를 유지하라 __ 신문 기사처럼 작성하라 __ 개념은 빈 행으로 분리하라 __ 세로 밀집도 __ 수직 거리 __ 세로 순서 가로 형식 맞추기 __ 가로 공백과 밀집도 __ 가로 정렬 __ 들여쓰기 가짜 범위 팀 규칙 밥 아저씨의 형식 규칙 6장 객체와 자료 구조 자료 추상화 자료/객체 비대칭 디미터 법칙 __ 기차 충돌 __ 잡종 구조 __ 구조체 감추기 자료 전달 객체 __ 활성 레코드 결론 참고 문헌 7장 오류 처리 오류 코드보다 예외를 사용하라 Try-Catch-Finally 문부터 작성하라 미확인unchecked 예외를 사용하라 예외에 의미를 제공하라 호출자를 고려해 예외 클래스를 정의하라 정상 흐름을 정의하라 null을 반환하지 마라 null을 전달하지 마라 결론 참고문헌 8장 경계 외부 코드 사용하기 경계 살피고 익히기 log4j 익히기 학습 테스트는 공짜 이상이다 아직 존재하지 않는 코드를 사용하기 깨끗한 경계 참고 문헌 9장 단위 테스트 TDD 법칙 세 가지 깨끗한 테스트 코드 유지하기 __ 테스트는 유연성, 유지보수성, 재사용성을 제공한다 깨끗한 테스트 코드 __ 도메인에 특화된 테스트 언어 __ 이중 표준 테스트 당 assert 하나 __ 테스트 당 개념 하나 F.I.R.S.T. 결론 참고 문헌 10장 클래스 클래스 체계 __ 캡슐화 클래스는 작아야 한다! __ 단일 책임 원칙 __ 응집도Cohesion __ 응집도를 유지하면 작은 클래스 여럿이 나온다 변경하기 쉬운 클래스 __ 변경으로부터 격리 참고 문헌 11장 시스템 도시를 세운다면? 시스템 제작과 시스템 사용을 분리하라 __ Main 분리 __ 팩토리 __ 의존성 주입 확장 __ 횡단(cross-cutting) 관심사 자바 프록시 순수 자바 AOP 프레임워크 AspectJ 관점 테스트 주도 시스템 아키텍처 구축 의사 결정을 최적화하라 명백한 가치가 있을 때 표준을 현명하게 사용하라 시스템은 도메인 특화 언어가 필요하다 결론 참고 문헌 12장 창발성(創發性) 창발적 설계로 깔끔한 코드를 구현하자 단순한 설계 규칙 1: 모든 테스트를 실행하라 단순한 설계 규칙 2~4: 리팩터링 중복을 없애라 표현하라 클래스와 메서드 수를 최소로 줄여라 결론 참고 문헌 13장 동시성 동시성이 필요한 이유? __ 미신과 오해 난관 동시성 방어 원칙 __ 단일 책임 원칙Single Responsibility Principle, SRP __ 따름 정리corollary: 자료 범위를 제한하라 __ 따름 정리: 자료 사본을 사용하라 __ 따름 정리: 스레드는 가능한 독립적으로 구현하라 라이브러리를 이해하라 __ 스레드 환경에 안전한 컬렉션 실행 모델을 이해하라 __ 생산자-소비자Producer-Consumer __ 읽기-쓰기Readers-Writers __ 식사하는 철학자들Dining Philosophers 동기화하는 메서드 사이에 존재하는 의존성을 이해하라 동기화하는 부분을 작게 만들어라 올바른 종료 코드는 구현하기 어렵다 스레드 코드 테스트하기 __ 말이 안 되는 실패는 잠정적인 스레드 문제로 취급하라 __ 다중 스레드를 고려하지 않은 순차 코드부터 제대로 돌게 만들자 __ 다중 스레드를 쓰는 코드 부분을 다양한 환경에 쉽게 끼워 넣을 수 있게 스레드 코드를 구현하라 __ 다중 스레드를 쓰는 코드 부분을 상황에 맞게 조율할 수 있게 작성하라 __ 프로세서 수보다 많은 스레드를 돌려보라 __ 다른 플랫폼에서 돌려보라 __ 코드에 보조 코드instrument를 넣어 돌려라. 강제로 실패를 일으키게 해보라 __ 직접 구현하기 __ 자동화 결론 참고 문헌 14장 점진적인 개선 Args 구현 __ 어떻게 짰느냐고? Args: 1차 초안 __ 그래서 멈췄다 __ 점진적으로 개선하다 String 인수 결론 15장 JUnit 들여다보기 JUnit 프레임워크 결론 16장 SerialDate 리팩터링 첫째, 돌려보자 둘째, 고쳐보자 결론 참고 문헌 17장 냄새와 휴리스틱 주석 __ C1: 부적절한 정보 __ C2: 쓸모 없는 주석 __ C3: 중복된 주석 __ C4: 성의 없는 주석 __ C5: 주석 처리된 코드 환경 __ E1: 여러 단계로 빌드해야 한다 __ E2: 여러 단계로 테스트해야 한다 함수 __ F1: 너무 많은 인수 __ F2: 출력 인수 __ F3: 플래그 인수 __ F4: 죽은 함수 일반 __ G1: 한 소스 파일에 여러 언어를 사용한다 __ G2: 당연한 동작을 구현하지 않는다 __ G3: 경계를 올바로 처리하지 않는다 __ G4: 안전 절차 무시 __ G5: 중복 __ G6: 추상화 수준이 올바르지 못하다 __ G7: 기초 클래스가 파생 클래스에 의존한다 __ G8: 과도한 정보 __ G9: 죽은 코드 __ G10: 수직 분리 __ G11: 일관성 부족 __ G12: 잡동사니 __ G13: 인위적 결합 __ G14: 기능 욕심 __ G15: 선택자 인수 __ G16: 모호한 의도 __ G17: 잘못 지운 책임 __ G18: 부적절한 static 함수 __ G19: 서술적 변수 __ G20: 이름과 기능이 일치하는 함수 __ G21: 알고리즘을 이해하라 __ G22: 논리적 의존성은 물리적으로 드러내라 __ G23: If/Else 혹은 Switch/Case 문보다 다형성을 사용하라 __ G24: 표준 표기법을 따르라 __ G25: 매직 숫자는 명명된 상수로 교체하라 __ G26: 정확하라 __ G27: 관례보다 구조를 사용하라 __ G28: 조건을 캡슐화하라 __ G29: 부정 조건은 피하라 __ G30: 함수는 한 가지만 해야 한다 __ G31: 숨겨진 시간적인 결합 __ G32: 일관성을 유지하라 __ G33: 경계 조건을 캡슐화하라 __ G34: 함수는 추상화 수준을 한 단계만 내려가야 한다 __ G35: 설정 정보는 최상위 단계에 둬라 __ G36: 추이적 탐색을 피하라 자바 __ J1: 긴 import 목록을 피하고 와일드카드를 사용하라 __ J2: 상수는 상속하지 않는다 __ J3: 상수 대 Enum 이름 __ N1: 서술적인 이름을 사용하라 __ N2: 적절한 추상화 수준에서 이름을 선택하라 __ N3: 가능하다면 표준 명명법을 사용하 __ N4: 명확한 이름 __ N5: 긴 범위는 긴 이름을 사용하라 __ N6: 인코딩을 피하라 __ N7: 이름으로 부수 효과를 설명하라 테스트 __ T1: 불충분한 테스트 __ T2: 커버리지 도구를 사용하라! __ T3: 사소한 테스트를 건너뛰지 마라 __ T4: 무시한 테스트는 모호함을 뜻한다 __ T5: 경계 조건을 테스트하라 __ T6: 버그 주변은 철저히 테스트하라 __ T7: 실패 패턴을 살펴라 __ T8: 테스트 커버리지 패턴을 살펴라 __ T9: 테스트는 빨라야 한다 결론 참고 문헌 부록A 동시성 II 클라이언트/서버 예제 __ 서버 __ 스레드 추가하기 __ 서버 살펴보기 __ 결론 가능한 실행 경로 __ 경로 수 __ 가능한 순열 수 계산하기 __ 심층 분석 __ 결론 라이브러리를 이해하라 __ Executor 프레임워크 __ 스레드를 차단하지 않는non blocking 방법 __ 다중 스레드 환경에서 안전하지 않은 클래스 메서드 사이에 존재하는 의존성을 조심하라 __ 실패를 용인한다 __ 클라이언트-기반 잠금 __ 서버-기반 잠금 작업 처리량 높이기 __ 작업 처리량 계산 - 단일스레드 환경 __ 작업 처리량 계산 - 다중 스레드 환경 데드락 __ 상호 배제Mutual Exclusion __ 잠금 & 대기Lock & Wait __ 선점 불가No Preemption __ 순환 대기Circular Wait __ 상호 배제 조건 깨기 __ 잠금 & 대기 조건 깨기 __ 선점 불가 조건 깨기 __ 순환 대기 조건 깨기 __ 다중 스레드 코드 테스트 __ 스레드 코드 테스트를 도와주는 도구 결론 자습서: 전체 코드 예제 __ 클라이언트/서버 - 단일스레드 버전 __ 클라이언트/서버 - 다중 스레드 버전 부록B org.jfree.date.SerialDate 부록C 휴리스틱의 교차 참조 목록 에필로그 용어 대역표 약어 목록 찾아보기 |
저자 소개 (3명)
출판사 리뷰 출판사 리뷰 보이기/감추기
나쁜 코드도 돌아는 간다. 하지만 코드가 깨끗하지 못하면 개발 조직은 기어간다. 매년 지저분한 코드로 수많은 시간과 상당한 자원이 낭비된다. 그래야 할 이유가 없다.
로버트 마틴은 이 책에서 혁명적인 패러다임을 제시한다. 그는 오브젝트 멘토(Object Mentor)의 동료들과 힘을 모아 ‘개발하며’ 클린 코드를 만드는 최상의 애자일 기법을 정제해 책 한 권에 담았고, 이 책은 소프트웨어 장인 정신의 가치를 심어 주며 프로그래밍 실력을 높여줄 것이다. 여러분이 노력만 한다면.
어떤 노력이 필요하냐고? 코드를 읽어야 한다. 아주 많은 코드를. 그리고 코드를 읽으면서 그 코드의 무엇이 옳은지, 그른지 생각도 해야 한다. 좀 더 중요하게는 전문가로서 자신이 지니는 가치와 장인으로서 자기 작품에 대한 헌신을 돌아보게 된다.
이 책은 세 부분으로 나뉜다. 처음 몇 장은 클린 코드를 작성하는 원칙, 패턴, 실천을 설명한다. 둘째 부분은 사례 연구를 몇 가지 소개하는데, 점점 더 복잡해진다. 각 사례 연구는 코드를 깨끗하게 고치는, 즉 문제가 있는 코드를 좀 더 튼튼하고 효율적인 코드로 바꾸는 연습이다. 셋째 부분은 결말이다 사례 연구를 만들면서 수집한 휴리스틱과 ‘냄새’를 마지막 장에서 열거한다. 그 결과로 코드를 읽고, 짜고 정리하는 과정에서 우리가 생각하는 방식을 묘사한 지식 기반을 얻는다.
이 책을 읽은 독자는 다음 내용을 알게 된다.
* 좋은 코드와 나쁜 코드를 구분하는 방법
* 좋은 코드를 작성하는 방법과 나쁜 코드를 좋은 코드로 바꾸는 방법
* 좋은 이름, 좋은 함수, 좋은 객체, 좋은 클래스를 작성하는 방법
* 가독성이 높아지도록 코드 형식을 맞추는 방법
* 코드 논리를 흩뜨리지 않고서 오류 처리를 완벽하게 구현하는 방법
* 단위 테스트와 테스트 주도 개발을 적용하는 방법
이 책은 더 나은 코드를 만들려고 애쓰는 프로그래머, 소프트웨어 공학도, 프로젝트 관리자, 팀 리더, 시스템 분석가가 반드시 읽어야 할 책이다.
로버트 마틴은 이 책에서 혁명적인 패러다임을 제시한다. 그는 오브젝트 멘토(Object Mentor)의 동료들과 힘을 모아 ‘개발하며’ 클린 코드를 만드는 최상의 애자일 기법을 정제해 책 한 권에 담았고, 이 책은 소프트웨어 장인 정신의 가치를 심어 주며 프로그래밍 실력을 높여줄 것이다. 여러분이 노력만 한다면.
어떤 노력이 필요하냐고? 코드를 읽어야 한다. 아주 많은 코드를. 그리고 코드를 읽으면서 그 코드의 무엇이 옳은지, 그른지 생각도 해야 한다. 좀 더 중요하게는 전문가로서 자신이 지니는 가치와 장인으로서 자기 작품에 대한 헌신을 돌아보게 된다.
이 책은 세 부분으로 나뉜다. 처음 몇 장은 클린 코드를 작성하는 원칙, 패턴, 실천을 설명한다. 둘째 부분은 사례 연구를 몇 가지 소개하는데, 점점 더 복잡해진다. 각 사례 연구는 코드를 깨끗하게 고치는, 즉 문제가 있는 코드를 좀 더 튼튼하고 효율적인 코드로 바꾸는 연습이다. 셋째 부분은 결말이다 사례 연구를 만들면서 수집한 휴리스틱과 ‘냄새’를 마지막 장에서 열거한다. 그 결과로 코드를 읽고, 짜고 정리하는 과정에서 우리가 생각하는 방식을 묘사한 지식 기반을 얻는다.
이 책을 읽은 독자는 다음 내용을 알게 된다.
* 좋은 코드와 나쁜 코드를 구분하는 방법
* 좋은 코드를 작성하는 방법과 나쁜 코드를 좋은 코드로 바꾸는 방법
* 좋은 이름, 좋은 함수, 좋은 객체, 좋은 클래스를 작성하는 방법
* 가독성이 높아지도록 코드 형식을 맞추는 방법
* 코드 논리를 흩뜨리지 않고서 오류 처리를 완벽하게 구현하는 방법
* 단위 테스트와 테스트 주도 개발을 적용하는 방법
이 책은 더 나은 코드를 만들려고 애쓰는 프로그래머, 소프트웨어 공학도, 프로젝트 관리자, 팀 리더, 시스템 분석가가 반드시 읽어야 할 책이다.
회원리뷰 (14건)
혜택 및 유의사항?
클린 코드 리뷰입니다. 클린 코드라고 하면 개발자라면 한 번쯤은 꼭 읽어보게 되는 책이라고들 하는데요, 이 리뷰를 작성하는 저는 이제 막 시작한 주니어라 이런저런 말을 얹을 수는 없지만 코드 작성의 기반을 다질 때 참고하기 좋은 책이라고 생각합니다. 이 책은 코드가 커뮤니케이션의 도구라는 전제를 가지고 다른 동료와 함께 협업할 때 코드를 어떻게 작성하면;
리뷰제목
클린 코드 리뷰입니다. 클린 코드라고 하면 개발자라면 한 번쯤은 꼭 읽어보게 되는 책이라고들 하는데요, 이 리뷰를 작성하는 저는 이제 막 시작한 주니어라 이런저런 말을 얹을 수는 없지만 코드 작성의 기반을 다질 때 참고하기 좋은 책이라고 생각합니다. 이 책은 코드가 커뮤니케이션의 도구라는 전제를 가지고 다른 동료와 함께 협업할 때 코드를 어떻게 작성하면 좋은 지에 관해 서술하고 있기에 그런 부분에 있어서 많은 도움이 되었습니다. 클린 코드가 뭔지 잘 모르겠고 알고 싶다, 가독성 좋은 코드를 작성하고 싶다 하시는 분들이라면 읽어보시는 것을 추천드립니다!
S/W 대가가 주석 챕터에서 언급하지 않은 부분이 있다.
그것은 외국인 프로그래머의 경우는 어찌 할 것인가?
나는 전산과 84학번으로 지금도 현업에서 프로그램을 개발한다.
내가 만나본 대부분의 개발자들은 영어를 잘 못한다. 영어문장으로 된 아래의 경우에서,
한국어로 주석을 달아 놓으면 직관적으로 이해가 쉽다.
책에 주석으로 한국인이 주석을 어찌 대해야 할지 추가해 놓;
리뷰제목
S/W 대가가 주석 챕터에서 언급하지 않은 부분이 있다.
그것은 외국인 프로그래머의 경우는 어찌 할 것인가?
나는 전산과 84학번으로 지금도 현업에서 프로그램을 개발한다.
내가 만나본 대부분의 개발자들은 영어를 잘 못한다. 영어문장으로 된 아래의 경우에서,
한국어로 주석을 달아 놓으면 직관적으로 이해가 쉽다.
책에 주석으로 한국인이 주석을 어찌 대해야 할지 추가해 놓지 않은 점이 아쉽다.
/**
* @class Existence : 존재에 대하여
*
* 데카르트
* Cogito, ergo sum (라틴어)
* 나는 생각한다. 그러므로 나는 존재한다.
* I think,therefore I am
*/
public class Existence {
// 1. 보통의 미국인 프로그래머
// I think, therefore I am --＞ 동어반복, 무의미한 주석
void iThinkThereforeIam() {
}
/**
* 2. 라틴어를 좋아하는 미국인 프로그래머
*/
// I think, therefore I am --＞ 외국어 이름이어서 유의미한 주석, 그러나 라틴어 매소드 이름은 영어로 바꾸어야 하겠다.
void cogitoErgoSum() {
}
/**
* 3. 보통의 한국인 프로그래머
*/
// 나는 생각한다. 그러므로 나는 존재한다. --＞ 외국어 매소드 이름이어서 유의미한 주석
void iThinkThereforeIam() {
}
}
인사이트(insight) 출판사에서 출간된 로버트 C. 마틴 작가님의 ＜Clean Code 클린 코드＞라는 작품을 읽고 작성하는 리뷰입니다. 처음 책 제목을 접했을 때부터 "클린 코드"라는 제목이 와닿았었는데, 책에 나와있는 "나쁜 코드"들도 정말 가슴에 와닿네요ㅋㅋㅋ 수많은 시간과 자원을 낭비하는 지저분한 코드라니... 그냥 좋은 코드에 대해서만 설명하는 게 아니라 나쁜 코드를 좋은 코;
리뷰제목
인사이트(insight) 출판사에서 출간된 로버트 C. 마틴 작가님의 ＜Clean Code 클린 코드＞라는 작품을 읽고 작성하는 리뷰입니다. 처음 책 제목을 접했을 때부터 "클린 코드"라는 제목이 와닿았었는데, 책에 나와있는 "나쁜 코드"들도 정말 가슴에 와닿네요ㅋㅋㅋ 수많은 시간과 자원을 낭비하는 지저분한 코드라니... 그냥 좋은 코드에 대해서만 설명하는 게 아니라 나쁜 코드를 좋은 코드로 바꿀 수 있는 방법들을 알려줘서 좋았어요. 코드 공부하다가 어려울 때 읽으면 도움이 될 것 같아요.
한줄평 (41건)
혜택 및 유의사항
?
좋은 책 감사합니다!!
이 한줄평이 도움이 되었나요?
공감
0
YES마니아 : 플래티넘
K*W
|
2023.04.09
추천받아서 구매했는데 제가 이걸 이해했으면 좋겠어요..
이 한줄평이 도움이 되었나요?
공감
0
YES마니아 : 로얄
c********7
|
2022.12.09
개발자 필수도서
이 한줄평이 도움이 되었나요?
공감
0
김*욱
|
2022.11.27
올해의 책 추천평 (8건) 올해의 책 추천평 이동
이 상품의 특별 구성
