메뉴 바로가기 검색 및 카테고리 바로가기 본문 바로가기

한빛출판네트워크

읽기 좋은 코드가 좋은 코드다: 더 나은 코드를 작성하는 간단하고 실전적인 테크닉

한빛미디어

번역서

판매중

  • 저자 : 더스틴 보즈웰 , 트레버 파우커
  • 번역 : 임백준
  • 출간 : 2012-04-26
  • 페이지 : 252 쪽
  • ISBN : 9788979149142
  • 물류코드 :1914
초급 초중급 중급 중고급 고급
4.5점 (6명)
좋아요 : 37
자신의 코드를 남에게 보여주기가 꺼려집니까?

프로그래머인 우리는 너무 엉망인데다가 버그투성이라서 머리가 지끈거리는 코드를 만나곤 한다. 이 책의 저자인 더스틴 보즈웰과 트레버 파우커는 지난 5년 동안 (자신들의 코드를 포함한) 수백 개의 "나쁜 코드"를 분석하고, 그러한 코드가 "왜 나쁜지", 그리고 코드를 "어떻게 개선할 수 있는지"를 연구했다. 그들이 내린 결론은 무엇일까? 그것은 바로 다른 사람들이 코드를 읽고 이해하는 데 걸리는 시간이 최소한이 되도록 작성해야 한다는 것이다. 여기에서 다른 사람이란 자기 자신도 포함된다!

체계적이고 효과적으로 코드를 작성하고 있나요?

이 책은 코드를 작성할 때 언제나 적용할 수 있는 기본적인 원리와 실전적인 기술에 초점을 맞추고 있다. 누구나 쉽게 이해할 수 있는 코드를 예제로 사용하고, 각 장은 코딩과 관련한 다양한 측면을 파고든다. 그리하여 여러분이 어떻게 이해하기 쉬운 코드를 작성할 수 있는지를 보여준다.
  • 딱 맞는 이름 짓기, 주석 달기, 포맷팅 등을 어떤 코드에도 적용할 수 있는 도움말과 함께 설명한다.
  • 프로그램의 루프, 논리, 그리고 변수를 정리해서 복잡성과 혼동을 감소시킨다.
  • 한 번에 하나의 일을 처리하도록 코드의 블록을 정리하는 등, 문제를 함수 수준에서 공략한다.
  • 철저하고 간결하면서 동시에 읽기 쉬운, 효과적인 테스트 코드를 작성한다.
추천평(추천사)

"자신이 작성한 코드가 나중에 그 코드를 읽게 될 사람에게 어떤 영향을 주는지 의식하는 일은 소프트웨어 개발의 중요한 일부다. 이 책은 독자로 하여금 바로 이러한 문제의식을 바탕으로 여러 측면을 경험하게 하고, 이러한 내용을 생생한 예를 통해서 효과적으로 설명한다"
- 마이클 헝거, 소프트웨어 개발자, 네오 데크놀로지

"이 책을 번역하기로 결정한 과정은 다소 우연이었지만, 번역을 하는 과정에서 내가 평소에 생각하던 부분들이 이렇게 책으로 정리되어 나왔다는 사실에 안도감과 고마움을 느꼈다. 내가 지금까지 경험한 바에 의하면, 이 책을 읽지 않아도 좋은, 원래부터 간결하고 효율적인 코드를 작성하는 능력을 가진 프로그래머는 열에 하나에 불과하다. 자신이 그 하나에 속한다는 확신이 없으면, 이 책을 꼭 읽어보기 바란다"
- 임백준, 소프트웨어 개발자 & IT 라이터

저자

더스틴 보즈웰

칼텍에서 컴퓨터 사이언스 학사학위를 받았고, UC 샌디애고에서 석사학위를 받았다. 5년 동안 구글에서 근무하면서 웹크롤링 인프라스트럭처를 비롯한 다양한 프로젝트를 경험했다. 수많은 웹사이트를 개발했고 "빅 데이터"와 "기계학습" 분야에 관심이 있다.
저자

트레버 파우커

10년 동안 마이크로소프트와 구글에서 대규모 소프트웨어를 개발했다. 지금은 구글에서 검색 인프라스트럭처의 엔지니어로 근무하고 있다. 여가 시간에는 게임 관련 컨벤션에 참석하고, 공상과학 소설을 읽고, 부인의 패션 관련 스타트업 회사에서 COO 일을 한다. 트레버는 UC 버클리에서 전기공학과 컴퓨터 사이언스 학사학위를 받았다.
역자

임백준

한빛미디어에서 『팟캐스트 나는 프로그래머다』, 『임백준의 아카 시작하기』, 『폴리글랏 프로그래밍』, 『누워서 읽는 퍼즐북』, 『프로그래밍은 상상이다』, 『뉴욕의 프로그래머』, 『소프트웨어 산책』, 『나는 프로그래머다』, 『누워서 읽는 알고리즘』, 『행복한 프로그래밍』을 출간했고, 로드북에서 『프로그래머 그 다음 이야기』를 출간했다. 삼성SDS, 루슨트 테크놀로지스, 도이치은행, 바클리스, 모건스탠리 등에서 근무했고 현재는 맨해튼에 있는 스타트업 회사에서 분산처리, 빅데이터, 머신러닝과 관계된 업무를 수행하고 있다. 지디넷코리아와 한겨레신문에 정기적으로 칼럼을 기고하고 있고, 〈나는 프로그래머다〉 팟캐스트 방송 호스트로 활약 중이다.

1장. 코드는 이해하기 쉬워야 한다   01. 무엇이 코드를 "더 좋게" 만드는가?     02. 가독성의 기본 정리     03. 분량이 적으면 항상 더 좋은가?     04. 이해를 위한 시간은 다른 목표와 충돌하는가?     05. 어려운 부분  PART I. 표면적 수준에서의 개선2장. 이름에 정보 담기   01. 특정한 단어 고르기     02. tmp나 retval 같은 보편적인 이름 피하기     03. 추상적인 이름보다 구체적인 이름을 선호하라     04. 추가적인 정보를 이름에 추가하기     05. 이름은 얼마나 길어야 하는가?     06. 이름 포메팅으로 의미를 전달하라     요약  3장. 오해할 수 없는 이름들   01. 예: Filter()     02. 예: Clip(text, length)     03. 경계를 포함하는 한계값을 다룰 때는 min과 max를 사용하라     04. 경계를 포함하는 범위에는 first와 last를 사용하라     05. 경계를 포함하고/배제하는 범위에는 begin과 end를 사용하라     06. 불리언 변수에 이름 붙이기     07. 사용자의 기대에 부응하기     08. 예: 이름을 짓기 위해서 복수의 후보를 평가하기     요약  4장. 미학   01. 미학이 무슨 상관인가?     02. 일관성과 간결성을 위해서 줄 바꿈을 재정렬하기     03. 메소드를 활용하여 불규칙성을 정리하라     04. 도움이 된다면 코드의 열을 맞춰라     05. 의미 있는 순서를 선택하고 일관성 있게 사용하라     06. 선언문을 블록으로 구성하라     07. 코드를 "문단"으로 쪼개라     08. 개인적인 스타일 대 일관성     요약  		5장. 주석에 담아야 하는 대상   01. 설명하지 말아야 하는 것     02. 생각을 기록하라     03. 코드를 읽는 사람의 입장이 되어라     04. 마지막 고찰 - 글 쓰는 두려움을 떨쳐내라     요약  	6장 명확하고 간결한 주석 달기   01. 주석을 간결하게 하라     02. 모호한 대명사는 피하라     03. 엉터리 문장을 다듬어라     04. 함수의 동작을 명확하게 설명하라     05. 코너케이스를 설명해주는 입/출력 예를 사용하라     06. 코드의 의도를 명시하라     07. 이름을 가진 함수 파라미터 주석     08. 정보 축약형 단어를 사용하라     요약  	PART II. 루프와 논리를 단순화하기7장. 읽기 쉽게 흐름제어 만들기   01. 조건문에서 인수의 순서     02. if/else 블록의 순서     03. (삼항 연산자로 알려진)?:를 이용하는 조건문 표현     04. do/while 루프를 피하라     05. 함수 중간에서 반환하기     06. 악명 높은 goto     07. 중첩을 최소화하기     08. 실행 흐름을 따라올 수 있는가?     요약  	8장. 거대한 표현을 잘게 쪼개기   01. 설명 변수     02. 요약 변수     03. 드모르간의 법칙 사용하기     04. 쇼트 서킷 논리 오용하기     05. 예: 복잡한 논리와 씨름하기     06. 거대한 구문 나누기     07. 표현을 단순화하는 다른 창의적인 방법들     요약  	9장. 변수와 가독성   01. 변수 제거하기     02. 변수의 범위를 좁혀라     03. 값을 한 번만 할당하는 변수를 선호하라     04. 마지막 예     요약  	PART III. 코드 재작성하기10장. 상관없는 하위문제 추출하기   01. 소개를 위한 예: findClosestLocation()     02. 순수한 유틸리티 코드     03. 일반적인 목적의 코드     04. 일반적인 목적을 가진 코드를 많이 만들어라     05. 특정한 프로젝트를 위한 기능     06. 기존의 인터페이스를 단순화하기     07. 자신의 필요에 맞춰서 인터페이스의 형태를 바꾸기     08. 지나치게 추출하기     요약  	11장. 한 번에 하나씩   01. 작업은 작을 수 있다     02. 객체에서 값 추출하기     03. 더 큰 예제     요약  	12장. 생각을 코드로 만들기   01. 논리를 명확하게 설명하기     02. 라이브러리를 알면 도움이 된다     03. 논리를 쉬운 말로 표현하는 방법을 더 큰 문제에 적용하기     요약  	13장. 코드 분량 줄이기   01. 그 기능을 구현하려고 애쓰지 마라 - 그럴 필요가 없다     02. 요구사항에 질문을 던지고 질문을 잘게 나누어 분석하라     03. 코드베이스를 작게 유지하기     04. 자기 주변에 있는 라이브러리에 친숙해져라     05. 예: 코딩 대신 유닉스 도구를 활용하기     요약  PART IV. 선택된 주제들	   14장. 테스트와 가독성   01. 읽거나 유지보수하기 쉽게 테스트를 만들어라     02. 이 테스트는 어떤 점이 잘못되었을까?     03. 이 테스트를 더 읽기 쉽게 만들기     04. 읽기 편한 메시지 만들기     05. 좋은 테스트 입력값의 선택     06. 테스트 함수에 이름 붙이기     07. 이 테스트 코드는 무엇이 잘못되었는가?     08. 테스트에 친숙한 개발     09. 지나친 테스트     요약  	15장. "분/시간 카운터"를 설계하고 구현하기   01. 문제     02. 클래스 인터페이스 정의하기     03. 시도1: 순진한 해결책     04. 시도2: 컨베이어 벨트 설계     05. 시도3: 시간-바구니 설계     06. 3가지 해결책 비교하기     요약  	Appendix 추가적인 도서목록   01. 높은 수준의 코드를 쓰는 방법을 다루는 책들     02. 다양한 프로그래밍 주제에 대한 책들     03. 역사적 사례를 담고 있는 책들     찾아보기

  • 책은 얇은 편이다.
    책의 내용이나 구성도 어려운 편은 아니어서
    재미있게 읽어내려간거 같다.

    책의 내용은
    읽기 좋은 코드 즉,
    가독성이 좋은 코드를 작성하기 위한 방법에 대해서 다루고 있지만
    그러한 가독성을 위한 과정에서
    여러 다른 개념도 복합적으로 다루고 있다.

    지금까지 프로젝트를 하면서
    다른 사람이 봤을때 읽기 쉬운 코드라기 보단
    내가 프로그램 개발에 있어 내가 일정이나 관리를 보다 쉽게 하기 위해
    쓰던 그런 방법들이
    많이 나와 있어서 재미있었던거 같다.

    현재는 프로젝트를 할때
    모든 용어를 메타로 관리하기에
    필드 하나하나도 메타에 있는 용어로 쓰도록 제한하는 경우가 많다.

    사실 이러한 부분도 좋은 점도 있지만 현실적으로 힘든점도 있다.

    그러한 부분을 떠나서
    좋은코드 에 대해 보다 실제적으로 다루고 있어
    좋았던거 같다.

    이러한 가독성이 좋은 코드 방식에 대한
    책이 요새 0여러권 나오는거 같은데
    시간이 되면 한번 읽어봐야 겠다.

  • 소프트웨어 개발자에게 있어서 소프트웨어가 폐기되는 것보다 더 무서운 것은 무엇일까? 개인적인 생각은 소프트웨어 유지보수가 소프트웨어 폐기보다 더 무서운 일이 아닐까 생각해본다.

    지난 시간에 열심히 코드를 만들어서 기껏 동작하게 해놨더니 오류 투성이에 동작도 제대로 안한다. 밤을 새든, 주말 출근을 하든 코드가 동작하게 해도 더욱이나 중요한 것은 내가 다시 그 코드를 볼 때다.

    하루도 아니고 조금이라도 시간이 흐른 다음 본 코드는 광역시 쓰레기 매립장과 그 모습이 흡사하다.

    비단, 내가 만든 코드가 아니라 할지라도 그건 변함 없는 사실이다.

    그러면 소프트웨어는 어떻게 해야 잘 개발할 수 있을까? 아니 그 보단 어떻게 해야 만들기도 쉽고 유지보수도 쉽게 하게 할 수 있을까?

    "읽기 좋은 코드가 좋은 코드다"의 저자인 더스틴 보즈웰과 트레버 파우커는 자신들이 경험한 나쁜 코드와 좋은 코드를 어떻게 구분하는지 그 해결책은 무엇인지 찾아본다.

    이 코드를 누가 볼꺼야?

    소프트웨어는 개발하는 사람과 유지보수 하는 사람이 작은 회사의 경우에는 같다. 하지만 회사의 규모가 커지고 개발하는 인력이 많아지면 자연스럽게 개발 인력과 유지보수 인력이 나뉘어진다.

    물론 이런 구조가 조직 운영의 측면에선 훌륭한 운용 방법이겠으나 소프트웨어 개발에 있어서도 정말 행복한 운용 방법일까?

    사람에 따라서 이 질문에 대한 대답은 다를 수 밖에 없을 것 같으니 쓸데없이 진 빼지 말고 코드를 누가 볼것인지 생각해봐야 한다.

    내가 생각하는 대답은 이렇다.

    자신이 소프트웨어 개발자라면 자신이 만든 코드는  자신이 볼 가능성이 70% 이상이다.

    근데 내가 만드는 코드를 내 맘대로 만들면 되지. 왜 읽기 편하게 만들어야 하느냐고 묻는다면 코드는 온전히 본인의 것이기 때문이다.

    코드는 미학이다!

    코드를 읽기 좋게 만든다면서 자신만 알아볼 수 있는(심지어 자신도 잊어먹는) 코드를 만들어놓고 와! 이건 완전 예술이야! 라고 자신이 감탄하는 코드를 만들어 놓고 나 잘났다~

    독자는 이런 종류의 행동을 하면 안된다! 물론 읽기 좋은 코드는 보기에 아름다워야 하니 미학적인 모습을 가지고 있어야 하기는 하지만 그렇다고 해서 무슨 미술관의 추상화 그림처럼 코드를 만들라는건 아니다.

    읽기 좋은 코드는 명확한 이름들을 가지면서 코드 정렬을 맞추고 의미있는 순서로 재배치하며 명확한 주석을 기록해야 한다. 그러면서도 소프트웨어 개발에 정해져있는 코딩 규칙이 있으면 그를 따라줘야 한다.

    잘 동작하는 코드 vs 명확한 코드

    나도 코드를 만들다 보면 명확한 코드보단 그저 잘 동작하는 코드에 집중하게 된다. 그런데 잘 동작하는 코드가 항상 명확한 것은 아니다. 오히려 명확한 코드가 잘 동작하는 코드인 경우가 많다.

    잘 동작하는 코드에서 명확한 코드로의 변경은 코드의 제어흐름의 조정과 거대한 표현은 잘개 쪼갠다. 그리고 무엇보다 변수는 말 그대로 자주 변할 수 있으니 그 사용범위가 제한되어야 한다.

    이 코드 다른데서도 쓸 수 있을까?

    리팩토링에서도 나올 수 있는 이 주제는 코드에 있어서도 프로그램에 완전히 종속하는 기능인지 다른 코드에서도 쓸 수 있는지 확인해보아야 한다. 

    이와 같은 이유로 코드에서 분리될 필요가 있는 문제를 찾아서 코드를 분리하는 작업이 필요하다. 또한 작업은 한 번에 하나씩 하도록 코드를 만들어야 한다.

    개발자들이 항상 하는 일 중 하나는 있는 라이브러리를 다시 생성한다거나 하는 일인데 우리가 만드는 프로그램은 항상 작은 코드 크기를 유지해야 한다. 그럼으로서 우리는 코드를 조금 더 쉽게 유지보수하고 명확한 문제 해결책을 가지게 된다.

    코드만 읽기 쉬워선 안된다 - 선택된 주제들

    많은 경우 우리는 소프트웨어 개발에 있어서 기능은 개발하지만 기능에 대한 면밀한 테스트는 잘 해보지 않는다. 그리고 하나의 잘 독립된 소프트웨어를 개발하는 경우도 별로 없다.

    많은 경우의 소프트웨어 개발자들은 하나의 잘 설계된 소프트웨어 개발이 아닌 시간에 쫓기는 개발을 하기 때문인데, 이와 관련해서 저자는 한 가지의 해결방법을 제시했다.

    테스트 케이스 작성을 통한 테스트를 해결책으로 제시했는데 많은 경우 소프트웨어 개발에서 테스트는 겉

  • 읽기 좋은 코드가 좋은 코드다.(한빛미디어)
    책 제목 그대로 코딩을 어떻게 해야 하는지를 설명하는 책이다. 누구나가 프로그램 코드를 봤을 때, 우선 읽기 편하고 실행이나 디버깅이 없이 프로그램의 작은 파트 또는 전체 프로그램의 흐름을 눈으로만 파악하도록 코드를 만드는 방법에 대해서 설명하고 있는 책이다. 특히 한국에서 프로그램을 개발하는 사람들이라면 반드시 읽고 넘어가야 하고, 자신의 코딩 스타일에 대해서 다시 한번 생각을 할 수 있도록 만들어주는 책인 동시에, 코딩 스킬을 한 단계 업그레이드 하도록 만들어 주는 가장 기본기를 가르쳐주는 유익한 책이다.
    책의 앞부분을 읽을 때, 학교에서 배운 프로그래밍 코딩 작성 방법에서 조금 더 구체적으로 설명하겠지 라는 나의 생각을 완전히 뒤 엎어버렸다. 책의 두께에 비해 중요한 정보들을 가득 담고 있을 줄은 전혀 예상하지도 못했다. 코딩은 단순히 내가 요구하는, 내가 목표로 하는 결과만을 동작시키거나 만들어 내면 된다는 나의 생각을 완전히 부셔버렸다. 변수나 함수 하나의 이름을 붙이는 것에서부터, 전체 프로그램의 개발 방법까지를 어떤 방식으로부터 시작해서 어떻게 마무리를 해야지만 버그가 적고 유지 보수를 쉽게 할 수 있는 지를 깨우쳐 준다. 이 책의 저자가 말한 대로, 원래부터 간결하고 효율적으로 코드를 작성하는 능력을 가진 사람이라면야 굳이 이 책을 읽을 필요는 없다. 하지만, 한국에서 저자가 말한 이상형의 개발자는 극히 찾기 드물다. 엄청난 작업량과 바쁜 스케줄 때문에 모든 개발자들이 좀더 좋은 코드를 만들기 보다는 단순히 돌아가기만 하면 되는 코드들을 양산해 낸다. 얼마 전 나 자신만 하더라도 프로젝트 스케쥴에 쫓겨 우선 돌아가기만 하면 된다라는 생각을 갖고 코드 작성하였고, 지금에 와서는 내가 왜 이렇게 코드를 만들었는지, 또 이 함수는 어떻게 돌아가는지 등 유지 보수에 엄청난 시간을 재투자 하고 있고 다시 코드를 만들어 냈다. 이게 얼마나 어리석은 짓이고 낭비인지를 이 책을 읽으면서 나 자신에 대해 반성을 했고, 좀 더 일찍 이 책을 접했더라면 이라는 아쉬움이 밀려왔다.
    비록 책의 두께는 얼마되지 않지만, 개발자들이 고쳐야 하는, 또 개선시켜야 하는 내용들이 가득 담겨져 있다. 나 자신을 위해서, 그리고 내 코드를 읽고 유지 보수해야 하는 다른 사람들을 위해서도 반드시 읽어보고 또한 이 책에서 말한 전부는 아니지만 코드를 작성할 때 좀 더 깊이 생각을 하게 만든다. 변수 명명에서부터 주석까지, 누구나 코드를 읽어도 이해하기 쉽도록 어떻게 하면 가독성과 어떤 식으로 생각을 해야 거대한 함수를 하나의 작은 기능을 갖는 단위로 쪼갤 수 있고 및 코드의 양을 줄이는 방법까지 경험을 통해 설명하는 괜찮은 책이다.
    책을 읽다 보니, 어느날 선배 중에 한 명이 역시 저자와 마찬가지로 한국인 아닌 서양에서는 하루에 10줄을 코드를 작성하더라도 디버깅 및 테스트 등의 여러 가지 사항들을 모두 확인하여 보기 좋게 코드를 만든다고 했던 말이 기억이 난다. 과연 한국 실정에서는 가능한 얘기일까 반문 하고 싶지만, 그래도 아름답고 간결하게, 누구나 읽어도 코드 작성자의 생각을 싶게 파악하는 코드를 만들어야 하지 않을까 하는 생각이 든다.

  • 좋은 프로그래머가 되기 위한 좋은 습관들은 읽기 쉽고 통일되게 코딩 원칙을 준수하는 것을 들 수 있을 것이다.
    하지만 현재 프로그램의 대부분은 팀의 공동 산출물로서 한 명 및 다수의 잘못된 코딩 습관은 프로젝트 전체에 영향을 주게된다.

    "읽기 좋은 코드가 좋은 코드다"는 Part 별로 "① 표면적 수준에서의 개선, ② 루프와 논리를 단순화하기, ③ 코드 재작성하기, ④ 선택된 주제들" 단계를 두고 예제를 활용하여 현재의 상태와 변화되는 상태를 간접적으로 경험이 가능하게 작성되어 프로그래머가 조금씩 변화를 느낄 수 있게 된다.
    또한 컴파일러 및 개발도구의 변화로 불필요한 과거의 코딩 방법에 대하여 예제를 들어 이러한 문법의 부자연스러움을 강조하고 가독성을 높이는 방법를 자세히 설명하고 있다.

    내가 읽지 못하는 코드는 남도 읽지 못한다는 생각과 올바른 프로그래밍 습관 및 원칙을 가지게 도와주는 가장 기본적인 서적으로 활용이 가능할 것이다.

    하지만 이 책의 내용을 무조건 적으로 맹신하여 무리하게 적용한다면 무엇보다 "아무리 좋은 것도 과하면 아니한 것만 못하다"는 속담처럼 전체(및 본인)의 이상과 현실에서 적당히 타협하여 실천해 나가야할 것이다. 또한 설명에 강조를 하기 위함인지 일부 예제 코드들이 현실성이 떨어지는 부분들이 있기도 하다.

  • "읽기 쉬운 100줄의 코드는 읽기 어려운 50줄의 코드에 비해서 훨씬 낫다"

    회사의 프로젝트를 수행하면서 직접 개발을 하는 경우가 많지만, 이에 못지않게 이미 개발된 소스코드를 분석하는 일도 많다.
    남의 소스코드를 분석하다보면 잘 이해가 되는 소스가 있는 반면, 여러번 봐야하고, 심지어 필기를 해가며 분석을 해가야 이해가 되는 소스가 있다. 함수가 어떤 동작을 수행하는지 알기 위해 코드 한줄 한줄을 다 읽어야 이 함수가 무슨 일을 하는 지 알수 있다면 이 코드의 분석은 정말 끔찍하고 피하고 싶은 일이 될것이다.
    이 책을 읽고 난 뒤, "이 코드는 이 부분 때문에 가독성이 참 떨어지네" 라고 잡아낼 수 있는 감이 생긴 것 같다. 물론 직접 코딩을 할 때도 많은 도움이 될 것이다.

    이 책은 얇다. 삽화, 소스코드, 글 들이 잘 배치가 되어있어서 지루하지않고 재미있게 읽을 수 있고, 250페이지 정도여서 짧은 시간에 읽을 수 있는 분량이다.
    저자들은 예제를 통해서 이 코드는 왜 나쁜지, 어떻게 하면 읽기 좋은 코드가 되는지를 설명하고 있다. 저자들이 직접 개발했던 코드들, 오픈소스 코드들(크로미움 프로젝트 등)에서 어떠한 부분이 읽기 좋지 않았고, 어떻게 개선이 되서 읽기 좋은 코드가 되었는지 잘 설명을 해주고 있다. 설명을 위해 만든 코드가 아닌, 문제가 있었던 코드들을 찾아서 사용하고 있어서 그런지 예제들이 참 좋았던 것 같다.

    이 책은 총 네 파트로 구성 되어있다.
    첫번째 파트 (표면적 수준에서의 개선) - 파트 이름대로 표면적 수준에서의 개선할 수 있는 내용들을 설명하고 있다. 변수명, 함수명, 주석등을 통해 코드를 접했을 때 바로 보이는 부분들을 다루고 있다.
    두번째 파트 (루프와 논리를 단순화하기) - 조건문, 루프 (do/while, goto)를 분석하기 쉽게 구성하는 방법, 큰 논리를 단순한 작은 논리로 단순화하여, 읽는 사람이 쉽게 소화할 수 있는 방법을 제시하고 있다.
    세번째 파트 (코드 재작성하기) - 큰 흐름과 관계없는 작은 문제들로 쪼갠다음 분리하고, 작업은 한번에 하나씩이라는 원리를 토대로 작업을 재정리하는 방법을 다루고 있다.
    네번째 파트 (선택된 주제들) - 이 파트에서는 테스트 코드의 가독성에 대해 다루고, 분/시간 카운터 설계 및 구현과정을 진행하면서 어떻게 가독성을 높여가는지 보여주고 있다.

    소프트웨어 엔지니어라는 직업을 가지고도 변수 명, 변수 선언 위치 등에 대해 고민하고 구현을 했었던 적이 과연있었나 싶고, 부끄럽기까지하다. 이 책의 내용들을 통째로 머릿속에 집어넣고 다니고 싶다. 코드를 작성하는 사람이 아닌 코드를 읽는 사람의 입장에서 구현을 하라는 말을 명심한다면 읽기 좋은 코드를 작성할 수 있을 것이다.

    자신의 코드를 남에게 보이기 부끄러웠다면, 당장 이 책을 사서 보길 바란다.

  • 이 책은 좋은 코드를 작성하기 위한 친절한 가이드입니다.

    읽기 좋은 코드가 좋은 코드다. 그러면 읽기 좋은 코드가 왜 좋은지 그리고, 어떻게 해야 읽기 좋은 코드가 되는지를 기술하고 있습니다.
    이런책이 나왔으면 좋겠다 하고 있었는데 마침 IT쪽으로 쉽고 재미있는 글을 쓰시는 임백준님의 번역으로 출간되어서 기대감을 갖고 읽기 시작했는데 역시 100% 만족시켜주었습니다.


    코딩작업에서는 끊임없는 변화가 일어납니다. 기존코드에 새로운 기능을 추가한다든지 기존 기능을 변경한다든지 할 때 문제가 없으려면 기존코드에서 로직을 잘 파악하고, 코드를 추가후 제대로 동작하는지 테스트를 해야합니다.
    작업시간의 대다수가 코드를 읽으면서 자신이 오래전에 작성해서 기억이 가물하거나, 동료나 남이 작성해서 잘 모르는 기존 로직을 파악하는데 사용됩니다. 시간이 많이 소요되며 이 단계가 잘못되면 나중에 큰 문제가 발생할 수 있습니다.

    그래서 이 책은 언어와 상관없이 일반적인 코드의 가독성이라는 측면에서 코드 읽기를 개선시키는 방법들을 설명해줍니다.

    Naming부터 주석달기, indentation등 쉽게 적용할 수 있는 표면적인 수준에서의 개선에서부터
    루프 논리를 단순화하기 단계, 코드 재작성단계 를 거쳐
    최종적으로 책에서 설명한 원리들을 적용시키는 예제를 통해 설명을 마무리 짓습니다.

    각각의 팁들은 짧게 설명은 개선 전 코드와 개선 후 코드의 비교를 통해, 그림을 통해 , 때때로 충실한 본문을 통해 잘 전달되고 있습니다.
    물론 코드를 보기 좋게 포맷팅해주는 것은 요즘 이클립스같은 통합 IDE들에서 단축키를 통해서도 무의식적으로 할 수 있지만, 어떤 원리를 통해 코드 다듬기를 하는지를 알고 하는것과 모르고 코딩하는것은 큰 차이가 있다고 생각됩니다.

    하나하나 적용해가면서 내가 작성한 코드가 남에게 조금 더 보기 좋고, 이해가 잘되게 한다면 회사내에서 일이 더 즐거워질테고, 팀이 생산성 및 품질이 증대될것이라 생각됩니다.

    그리고 마지막에 나온 Appendix의 도서들은 코드를 작성하는데 도움이 되는 주옥같은 책들입니다. 번역된 책들도 있으니 읽어보시면 좋을것입니다.

결재하기
• 문화비 소득공제 가능
• 배송료 : 0원배송료란?

배송료 안내

  • 책, 아이템 등 상품을 3만원 이상 구매시 무료배송
  • 브론즈, 실버, 골드회원이 주문하신 경우 무료배송

무료배송 상품을 포함하여 주문하신 경우에는 구매금액에 관계없이 무료로 배송해 드립니다.

닫기

리뷰쓰기

닫기
* 도서명 :
읽기 좋은 코드가 좋은 코드다: 더 나은 코드를 작성하는 간단하고 실전적인 테크닉
* 제목 :
* 별점평가
* 내용 :

* 리뷰 작성시 유의사항

글이나 이미지/사진 저작권 등 다른 사람의 권리를 침해하거나 명예를 훼손하는 게시물은 이용약관 및 관련법률에 의해 제재를 받을 수 있습니다.

1. 특히 뉴스/언론사 기사를 전문 또는 부분적으로 '허락없이' 갖고 와서는 안됩니다 (출처를 밝히는 경우에도 안됨).
2. 저작권자의 허락을 받지 않은 콘텐츠의 무단 사용은 저작권자의 권리를 침해하는 행위로, 이에 대한 법적 책임을 지게 될 수 있습니다.

오탈자 등록

닫기
* 도서명 :
읽기 좋은 코드가 좋은 코드다: 더 나은 코드를 작성하는 간단하고 실전적인 테크닉
* 구분 :
* 상품 버전
종이책 PDF ePub
* 페이지 :
* 위치정보 :
* 내용 :

도서 인증

닫기
도서명*
읽기 좋은 코드가 좋은 코드다: 더 나은 코드를 작성하는 간단하고 실전적인 테크닉
구입처*
구입일*
부가기호*
부가기호 안내

* 회원가입후 도서인증을 하시면 마일리지 500점을 드립니다.

* 한빛 웹사이트에서 구입한 도서는 자동 인증됩니다.

* 도서인증은 일 3권, 월 10권, 년 50권으로 제한됩니다.

* 절판도서, eBook 등 일부 도서는 도서인증이 제한됩니다.

닫기

해당 상품을 장바구니에 담았습니다.이미 장바구니에 추가된 상품입니다.
장바구니로 이동하시겠습니까?

자료실