코딩하는 드래곤 🐲

개요 이번 챕터에서는 프로젝트가 진행됨에 따라 고려해야 하는 프로젝트 전체 차원의 문제들을 다룹니다. 8장에서 다루는 내용은 다음과 같습니다. 실용주의 팀 유비쿼터스 자동화 가차없는 테스트 결국은 모두 글쓰기 위대한 유산 오만과 편견 느낀점 및 정리 실용주의 팀 지금까지 이 책에서 다룬 내용은 개인이 실용주의 프로그래머가 되는데 도움이 되는 팁이었습니다. 그러나 이 팁은 개인뿐만이 아닌 팀 단위로도 적용이 가능한 팁으로, 개인이 실용주의 팀에서 일하게 된다면 개인이 실용주의적이 되는 것에 몇 배에 달하는 이득을 얻을 수 있다고 합니다. 지난 챕터들에서 다루었던 내용들을 팀 측면에서 생각하면 다음과 같습니다. 깨진 창문을 없애라: 품질은 팀의 이슈 -> 팀 전체가 깨진 창문을 용납하지 않아야 합니다. 삶은..

개요 이번 챕터에서는 프로젝트를 시작하기 전에 생각할만한 것들을 다룹니다. 요구사항 분석이라던지 제약 조건이라던지.. 프로젝트를 시작하기 전부터 우리를 옭아매는 것들을 어떻게 지혜롭게 처리할 수 있을지 알아보도록 하겠습니다. 이번 챕터에서 다루는 내용은 다음과 같습니다. 요구사항의 구렁텅이 불가능한 퍼즐 풀기 준비가 되어야만 명세의 함정 동그라미와 화살표 느낀점 & 정리 요구사항의 구렁텅이 프로젝트를 시작하기 전에 요구사항의 구렁텅이에 빠지는 경우가 많습니다. 요구사항을 발견하는 것은 어렵고, 찾아낸 요구사항이 실제로 요구사항이 맞는지 확신하기도 어렵습니다. 그리고 마치 우리의 시간만 끝없이 잡아먹는 것처럼 보이기도 합니다. 이럴 때, 명확한 요구사항을 찾기 위해 우리가 해볼 수 있는 방법 중 하나는 우..

개요 요구사항은 빠르고 지속적으로 바뀌기 때문에 이러한 변화에 맞추기 위해서는 가능한 느슨하고 유연한 코드를 작성해야합니다. 5장에서는 되돌릴 수 있는 의사 결정을 내릴 수 있는 구체적인 방법에 대해 설명하고 다룹니다. 5장에서 다루는 챕터는 다음과 같습니다. 결합도 줄이기와 디미터 법칙 메타프로그래밍 시간적 결합 단지 뷰일 뿐이야 칠판 느낀점 결합도 줄이기와 디미터 법칙 결합도는 모듈간의 의존 정도를 의미합니다. 해당 챕터에서는 서로 다른 개념들을 분리하여 결합도를 줄이는 방법을 다룹니다. 코드는 되도록 모듈로 구성하고 이들 간의 상호작용을 제한해야 합니다. 한 모듈이 변경되거나 교체된다 하더라도 다른 모듈들은 변경 없이 수행될 수 있기 때문입니다. 만약 결합도가 높아져 의존 관계가 복잡해진다면 다음과..

개요 완벽한 프로그램을 설계하는 것은 불가능합니다. 이 점을 명심하고, 실용주의 프로그래머는 어떻게 프로그램을 설계하고 작업하는지 알아봅시다. 목차는 다음과 같습니다. 계약에 의한 설계 죽은 프로그램은 거짓말을 하지 않는다. 단정적 프로그래밍 언제 예외를 사용할까 리소스 사용의 균형 느낀점 계약에 의한 설계 (Design By Contract) 계약에 의한 설계는 프로그램의 정확성을 높이기 위해서 프로그램이 갖춰야할 조건들을 계약서를 작성하듯이 문서화하고 검증하는 것을 말합니다. 예를 들어서 메소드 선언부 위에 주석으로 메소드에 대한 설명, 메소드의 조건, 실행 후 결과 등을 적는 것을 생각하면 쉬울 듯 합니다. 계약에 의한 설계를 하기 위해서는 고려해야할 것이 세가지 존재합니다. 선행 조건: 메소드가 ..

개요 3장에서 다루는 내용은 다음과 같습니다. 일반 텍스트의 힘 조개 놀이 파워 에디팅 소스코드 관리 디버깅 텍스트 처리 코드 생성기 느낀점 일반 텍스트의 힘 일반 텍스트란 사람이 읽고 이해할 수 있는 형태로 이루어진 문자를 의미합니다. 가장 쉬운 예를 들자면 "아무개 씨의 아이디는 dkanro입니다."라는 문장은 일반 텍스트로 이루어진 문장입니다. 그러나 위 예와 같이 비구조적인 형태를 가질 필요는 없습니다. "아무개: dkanro"라는 구조적 형태의 데이터도 우리가 여전히 쉽게 읽고 이해할 수 있는 일반 텍스트입니다. 실제로 개발 환경에서 많이 사용되는 데이터 포맷 중 html, xml , sgml은 구조적 형태의 훌륭한 일반 텍스트입니다. 그러나 일반 텍스트는 명심해야 할 단점이 두 가지 존재합니다..

개요 한 주에 1장씩 읽는 건 줄 알았는데 7개의 챕터를 읽고 정리해야 한다는 걸 오늘 알았습니다 ㅎㅎ 정리하지 못한 챕터 7을 이어서 정리하고 나머지는 천천히 읽고 정리하도록 하겠습니다. 2장은 실용주의 접근법으로 소프트웨어 개발에 도움이 될 팁 혹은 공리를 정리한 내용입니다~ 목차는 다음과 같습니다. 중복의 해악 직교성 가역성 예광탄 프로토타입과 포스트잇 도메인 언어 추정 느낀점 중복의 해악 소프트웨어를 개발하다 보면 중복을 마주 하는 건 필연적인 것 같습니다. 그러나 잦은 중복은 소프트웨어의 신뢰성을 낮추고 유지보수를 어렵게 만들기 때문에 마음속에 항상 DRY!(Dont Repeat Yourself)를 떠올리며 살아야 합니다. 중복이 생기는 원인을 크게 4가지로 정리할 수 있습니다. 1. 강요된 중..