3장. 오해할 수 없는 이름들 변수, 함수, 클래스의 이름을 지을 때 이 이름이 다른 의미로 해석될 수 있을까? 라는 고민을 해보아야 한다. 당연한 것은 없다. 누군가는 처음부터 시작한다고 생각할 수 있고, 누군가는 마지막부터 시작한다고 생각할 수 있다. 또한 일반적으로 사람들이 어떤 의미로 사용하는지도 고려해야 한다. 예를 들어, get 메서드는 일반적으로 내부 멤버를 반환한다고 생각한다. 만약 클래스 내에서 getMean 이라는 메서드를 만들었는데, 이 메서드가 내부 멤버 배열의 전체를 돌고, 중앙 값을 반환하는 메서드라면 get 대신 compute 라는 이름을 사용하는 것이 더 좋다. 오해를 발생시키지 않는 이름이 좋은 이름이다. 우리의 코드를 다른 사람이 읽을 때, 우리가 의도한 대로 이해할 수 ..
개발 도서
2장. 이름에 정보 담기 프로그래밍하면서 가장 고민 되는 부분 중 하나가 이름을 짓는 것이다. 언제나 창작의 고통은 큰 것 같다. 하지만 잘 지은 이름은 이후에 뿌듯함만 주는 것이 아니라 코드를 쉽게 이해할 수 있도록 도움을 준다. 기존에 코드 컴플리트에서는 tmp, result 와 같은 변수를 사용하지 말라고 추천했었는데, 이 책에서는 조금 관대한 모습을 보여준다. 좁은 범위의 코드 내에서는 위처럼 보편적인 변수명을 사용해도 문제되지 않고, 오히려 좋을 것이라고 말해준다. 하지만 범위가 커지고, 개인의 귀차니즘(?) 때문에 지은 보편적인 이름들은 에러를 발생했을 때, 문제를 발견하기 더 어렵게 만든다고 말한다. 반복문에 사용하는 i, j, k 와 같은 변수명들도 누구나 이 것이 반복문에서 사용되는 인덱..
1장. 코드는 이해하기 쉬워야 한다. 이번은 처음 시작하는 장으로 챕터가 1장 으로 표시된다. 다음 내용부터는 Part 1 의 형태로 파트 내부에 몇 개의 장으로 이루어진 형태로 표시될 예정이다. 가독성이 높은 코드가 소프트웨어의 효율성과 디자인 패턴에 주는 영향은 거의 없다. 이 책의 목표는 가독성이 높은 코드를 작성하는 것이다. return age >= 40 ? price * (1
8장. 실용주의 프로젝트 소제목 실용주의 팀 유비쿼터스 자동화 가차없는 테스트 결국은 모두 글쓰기 위대한 유산 오만과 편견 자동화 할 수 있는 모든 것들을 자동화하자. 그리고 그 시간에 새로운 코드(또는 버그)를 작성하는데 투자하자. 41. 실용주의 팀 실용주의 프로그래머가 실용주의 철학을 가진 팀에서 일하게 되면 생산력은 몇 배로 증가할 것이다. 코드의 품질을 중요시 여기는 문화를 장착하고, 그러한 정신을 갖추지 못한 개발자를 격려하는 문화를 만들자. 팀을 기능을 중심으로 조직하자. 팀을 만드는 것에도 직교성을 유지하도록 하여, 중복되는 일을 하지 않도록 하라. 42. 유비쿼터스 자동화 컴파일 하거나, 코드를 생성하는 일, 빌드 및 테스트를 자동화하는데 힘쓰라. 자동화 할 수 있는 모든 것들을 자동화하..
7장. 프로젝트 전에 소제목 요구사항의 구렁텅이 불가능한 퍼즐 풀기 준비가 되어야만 명세의 함정 동그라미와 화살표 프로젝트를 시작 하기 전에 정리해야 할 사항들에 대해 다룬다. 프로젝트 전에 무엇을 해야할까?? 일단 요구사항을 정리해야 한다. 그리고 어떻게 프로젝트를 진행할 것인지에 대한 계획을 세워야한다. 만약 이 두 가지의 작업이 선행되지 않는다면, 프로젝트가 시작하기도 전에 망할 것 같다는 의심이 들고, 이는 실제 결과로 이어질 가능성이 매우 크다. 36. 요구사항의 구렁텅이 요구사항을 수집하기 보다는 채굴할 줄 알아야 한다. 사용자가 말한 요구사항의 핵심이 무엇인지를 파악하고, 이를 구체화하자. 그렇게 하기 위해서는 사용자와 함께 일하면서 지속적인 요구사항 채굴 과정이 필요하다. 아래 두 개의 요..
6장. 코딩하는 동안 해야 할 일들 소제목 우연에 맡기는 프로그래밍 알고리즘의 속도 리팩터링 테스트하기 쉬운 코드 사악한 마법사 리팩터링 하는 방법과 코딩을 어떻게 하는지에 대해 설명하는 장이고, 정말 많은 도움이 되는 설명들이었다. 31. 우연에 맡기는 프로그래밍 왜 프로그램이 이렇게 동작하는지 설명할 수 없다면, 이 프로그램은 내 프로그램이 아니다. 지금은 이렇게 작동하지만 다른 환경에서는 다르게 동작할 수도 있다. 언제나 내 제어 안에 있는 코드를 작성하려고 노력해야 한다. 우리는 모두 우연에 맡기는 코딩을 하지 않는다고 생각할 수도 있으나, 항상 그렇게 하기는 어렵다. 의도적으로 프로그래밍 하는 방법 언제나 자기가 지금 무엇을 하고 있는지 알아야 한다. 맹목적으로 코딩하지 말라. 계획을 세우고 그..
5장. 구부러지거나 부러지거나 소제목 결합도 줄이기와 디미터 법칙 메타프로그래밍 시간적 결합 단지 뷰일 뿐이야 칠판 결합을 중이는 것의 중요성을 이전 장에서도 말하고 이 책의 전반적인 주제라는 생각이 든다. 왜 결합을 줄여아하는지와, 결합을 줄이는 방법에 대해서 이 책에서 알려주고 있다. 26. 결합도 줄이기와 디미터 법칙 결합도가 높은 프로그램은 유지보수하기 굉장히 힘들다. 한 부분을 수정했을 때, 해당 부분만 영향을 받아야하는데, 여러 부분에서 동시에 기존과 다른 동작을 한다면 유지보수 하는 것 보다 프로그램을 다시 만드는 것을 택하게 될 것이다. 디미터 함수 법칙은 프로그램에서 모듈간 결합도를 최소화하려 시도하는 것이다. 디미터 법칙에서 객체가 호출할 수 있는 메서드는 아래와 같다. 자신 메서드로 ..
4장. 실용주의 편집증 소제목 계약에 의한 설계 죽은 프로그램은 거짓말을 하지 않는다. 단정적 프로그래밍 언제 예외를 사용할까 리소스 사용의 균형 "완벽한 소프트웨어는 만들 수 없다." 라는 말로 이번 장이 시작한다. 지금까지 누구도 만든 적 없었고, 현재 누구도 만들 수 없는 것으로 보이기 때문에 우리는 방어적으로 프로그래밍 해야 한다. 어디서 문제가 발생할지 모르기 때문에 문제 발생 상황을 대비해야 한다. 21. 계약에 의한 설계 루틴을 실행 할 때 2가지의 상태가 있다. 선행 조건 후행 조건 선행 조건은 루틴이 실행되기 전에 참이어야 하는 조건들이다. 해당 조건이 아니면 루틴은 실행되지 않는 다는 것을 보장해야 한다. 후행 조건은 루틴의 실행 결과로 바뀌는 값들이다. 루틴의 실행 결과는 예측 가능해..
3장. 기본적인 도구 소제목 일반 텍스트의 힘 조개 놀이 파워 에디팅 소스코드 관리 디버깅 텍스트 처리 코드 생성기 이번 장에서는 개발자가 다루는 도구에 대해 설명한다. 개발자들은 주로 텍스트 에디터를 다루고, 나같은 경우 IDE를 사용해 개발을 하는데, IDE화 GUI에 익숙한 개발자들은 여기에서 벗어나야 할 필요성에 대해 말해주어서, 셸에 대해 조금 더 배워서 강력한 기능을 가진 셸 스크립트 언어를 사용해 자동 실행을 해보고 싶어졌다. 14. 일반 텍스트의 힘 우리가 알고 있는 지식을 일반 텍스트로 저장하면 언젠가는 이를 열어 봐야 하는 경우가 생길 것이다. 15. 조개 놀이 GUI는 굉장히 편리하다. 보이는 대로 실행되기 때문에 직관적이고, 배우기도 쉽다. 그리고 몇몇 과정들은 CUI 보다 더 빠르..
2장. 실용주의 접근법 소제목 중복의 해악 직교성 가역성 예광탄 프로토타입과 포스트잇 도메인 언어 추정 이번 장에서는 소프트웨어를 개발할 때 보편적으로 적용되는 부분에 대한 내용을 다룬다. 특히 '직교성'과 '가역성'에 대한 부분은 실제 소프트웨어의 생산성과 유지보수성에 크게 도움을 주므로 다시 한번 찾아보며 읽기 바란다. 7. 중복의 해악 DRY(Don't Repeat Yourself) 원칙에 대해 설명한다. 가끔 복사-붙여넣기를 통해 살짝만 코드를 수정하려는 유혹에 나는 쉽게 빠졌다. 하지만 조그만 부분을 수정하려 할 때에 모든 부분을 수정해야 하므로, 근본적인 부분을 모듈로 만든 후 한 부분에서만 수정하도록 만드는 것이 장기적인 관점에서 도움이 된다. 8. 직교성 직교성이란 두 벡터가 서로 직각으로..
