1. 코드가 존재하리라
1) 코드는 요구사항을 상세히 표현하는 언어
- 코드없이 요구사항을 상세하게 표현과 추상화가 불가능하다.
2) 고도의 추상화된 언어나 특정 응용 분야 언어로 기술하는 명세도 코드
3) 요구사항에서 정형구조를 뽑아낼 수 있게 하는 것도 코드
4) 코드는 정밀한 표현이며, 코드 없이 요구사항을 뽑을 수가 없음
2. 나쁜코드
1) 우리 모두는 좋은 코드가 왜 중요한지 알고 있음
- 오랫동안 개발하면서 나쁜 코드에 시달려왔기 때문
2) 나쁜코드로 인하여 회사가 망함
- 출시일에 맞추기 위해 코드를 마구 작성했고, 기능이 추가 될수록 코드가 엉망이 되었음,
그로 인해 감당이 불가능한 수준이됨 -> 프로그램 시동시간이 길어지고, 오류로 인해 종료되는 횟수 증가
3) 나쁜 코드에 발목잡혀 고생하는 것을 '고행'이라고 표현
- 엉킹 덩굴과 숨겨진 함정으로 가득한 늪지대를 헤쳐나가지만, 단서나 실마리가 없어 발버둥만 친다는 의미에서 비롯
4) 르블랑의 법칙
- 나중은 결코 돌아오지 않는다는 의미
- 쓰레기 코드를 작성하고, 나중에 손보겠다고 하지만 프로그램이 정상적으로 동작된다는 안도감을 느끼고 고치지 않음
- 처음 코드를 작성할 때 깨끗한 코드로 작성하자!
3. 나쁜코드로 치르는 대가
1) 나쁜코드는 개발속도를 크게 떨어뜨림
- 수정할 때 마다 엉뚱한 곳에서 문제가 발생하고, 간단한 수정이 없음
- 매번 얽히고 설킨 코드를 '해독'해서 얽히고 설킨 코드를 더함
- 이로 인해 나쁜코드가 쌓이고, 팀 생산성을 떨어뜨림
2) 원대한 재설계의 꿈
- 나쁜 코드로 인해 팀 생산성이 바닥이되어, 관리층에 재설계를 요구하는 경우가 생김
- 이를 허락한 관리층이 가장 유능하고, 똑똑한 사람들로 이루어진 타이거팀을 구축
* 타이거팀: 새로운 소프트웨어 또는 하드웨어 등에서 보안상의 취약점을
찾아내기 위해 만들어진 각 분야의 전문가로 구성된 '전문가 팀'
- 타이거팀은 기존 시스템기능을 모두 제공하며, 가해지는 변경들도 모두 잡아야됨
- 새 시스템이 기존 시스템을 따라 잡을 때 즈음 시스템 재설계
- 초창기 멤버들이 모두 떠나고, 새로운 멤버들이 재설계하고자 함 -> 새 시스템도 설계가 엉망
- 처음 코드를 작성할 때 부터 깨끗한 코드로 작성하는것이 바람직
3) 전문가로서의 태도
- 요구사항 변경 등으로 인하여 코드가 나쁜 코드로 전락된다면 그 잘못은 프로그래머의 책임
- 요구사항의 변경, 촉박한 일정, 관리자 고객마케팅에 대한 불평은 프로그래머로써 계획에 실패 한 것
- 좋은 코드를 사수하는 것은 프로그래머의 책임
4) 원초적 난제
- 프로그래머는 근본적인 가치에 봉착 -> 나쁜 코드가 업무 속도를 늦춘다는 사실을 알고 있음
- 일정 기한을 맞추기 위해 나쁜코드를 양산할 수 밖에 없다고 느낌 -> 빨리가려고 코드에 대해 시간을 들이지 않음
- 나쁜코드를 양산하면 기한을 맞추지 못함 -> 기한을 못추는 유일한 방법은 언제나 코드를 최대한 깨끗하게
유지하는 습관
4.깨끗한 코드라는 예술?
1) 깨끗한 코드를 구현하는 것은 그림 그리는 것과 흡사
- 사람들이 잘그린 그림과 못그린 그림을 구분한다고 해서 그림을 잘 그리지 못하는 것처럼,
깨끗한 코드와 나쁜 코드를 구분한다고해서 깨끗한 코드를 작성할 줄 아는 것은 아님
2) 깨끗한 코드를 작성하기위해 필요한 요소는 코드감각, 절제와 규율
- 코드감각이 있으면 깨끗한 코드와 나쁜코드를 구분하게 되고, 절제와 규율을 적용하여, 나쁜 코드를
좋은 코드로 바꾸는 전략도 파악 가능
- 코드감각이 없는 사람은 구분만 할줄 아는 반면 코드감각이 있는 사람은 나쁜 모듈을
좋은 모듈로 개선할 방법을 모색
5. 깨끗한 코드란?
1) 전문가들이 생각하는 깨끗한 언어의 정의
2) 비야네 스트롭스트룹 - '우아하고 효율적인 코드를 좋아한다.'
- 우아하다라는 표현은 다른 사람이 보기 즐거운 코드를 의미
- 효율적인 코드는 단순히 속도 기준이 아닌, 메모리 누수, 일관성없는 명명법 등
세세한 사항까지 꼼꼼하게 처리된 코드를 의미
3) 그래디 부치 - '가독성이 좋고, 잘 쓰여진 문장처럼 읽혀야 된다.'
- 깨끗한 코드는 단순하고 직접적이어야되고, 소설을 읽는 것처럼 코드가 잘 읽혀야되는 것을 의미
- 설계자의 의도를 숨기지 않고, 추측이 아닌 사실에 기반한 명쾌한 추상화와 단순한 제어문을 사용한 코드
4) 데이브 토마스 - '테스트케이스가 없는 코드가 아니다.'
- 즉, 다른사람이 고치기 쉬운 코드를 의미
- 의미 있는 이름을 붙이고, 특정 목적 달성하는 방법을 한가지만 제공
- 의존성은 최소화하고, 각 의존성을 명확히 정의
- 우아하고, 가독성이 좋은 코드라도 테스트케이스가 없으면 깨끗한 코드가 아님을 의미
- 인간이 읽기 좋은 코드 작성 -> 코드만으로 모든 정보를 명확히 표현할 수없기에 코드는 문학적으로
작성되야됨
5) 마이클 페더스 - '깨끗한 코드는 주의깊게 작성한 코드이다.'
- 누군가 시간을 들여 깔끔하고 단정하게 정리한 코드, 꼼꼼하게 신경을 쓴 코드
- 고치려고해도 손댈 곳이 없는 코드를 의미
6) 론 제프리스 - '중복이 없으며 간단한 코드, 단순한 코드 규칙으로 시작하고 끝낸다.'
- 의미 있는 이름으로 명명하며, 객체나 메소드가 여러 기능을 수행할 경우 객체나 메소드 등을 찾아 여러 객체로
나눔
- 모든 테스트를 통과해야함
7) 워드 커닝햄 - '코드가 그 문제를 풀기위한 언어처럼 보인다면 아름다운 코드라 불러도된다.'
- 코드를 읽으면서 짐작했던 기능이 각 루틴 그대로 수행한다면 깨끗한 코드임
6. 우리들 생각
1) 깨끗한 변수, 메소드, 클래스를 만드는 것을 깨끗한 코드임
7. 보이스카웃 규칙
1) 보이스카웃 규칙 중 '캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라'라는 규칙에서 비롯된 규칙
2) 소스코드를 처음 받았을 때보다 더 깨끗하게 소스코드를 작성하라는 의미
- 복잡한 로직과 조건문, 변수 이름 등을 작은 것부터 변경해서 차차 깨끗한 프로젝트로 완성해 나가는 것을 목표로 함
- 코드가 긴 함수를 분할하고, 약간의 중복을 제거하고, 복잡한 조건문 하나를 정리하면 그걸로 충분
