previous
코드는 항상 존재한다.
•
비정형적이거나, 모호한 고객의 요구사항과 감정을 읽고 기계가 실행할 수 있을정도로 요구사항을 명세 코드를 기계가 대체하기는 어렵다.
나쁜 코드
나중은 결코 오지 않는다.
— 르블랑의 법칙(leblanc's Law)
•
일정에 쫒겨 나쁘게 구현한 코드는 개발자의 발목을 잡는다.
•
바쁠때는 나중에 다시 리팩토링하겠다고 다짐하지만 다음은 오지 않는다.
•
나쁜코드와 생산성은 반비례한다.
•
재설계를 꿈꾸지만 이미 늦었다. 왜?
◦
새로운 프로젝트는 기존 시스템의 모든 기능을 제공해야한다.
◦
개발 도중 추가/변경되는 기존 시스템의 기능도 따라잡아야한다.
◦
레거시 프로젝트가 크면 클수록 재설계의 길은 기하급수적으로 어려워진다.
나쁜코드의 책임에서 개발자는 벗어날 수 없다.
일정 문제를 조율하지 못하는 개발자는 아마추어다.
나쁜 코드의 위험을 애하지 못하는 관리자 말을 그대로 따르는 행동은 프로가 아니다
•
개발자: 고객사가 일정을 너무 적게주고, 설계를 뒤집는 요구사항을 준다.
•
CleanCode: 고객사와 PM(프로젝트 관리자)이 요구사항과 일정을 잡으며 개발자에게 요구를 하지만, 프로젝트에 깊숙히 관여한건 개발자도 포함된다. 고객사와 PM은 자신의 임무를 다한 것이고 우리는 우리의 임무와 책임(좋은 코드를 사수하는 일)를 다해야 한다.
바쁘다는건 핑계다.
•
바쁘다고 나쁜 코드를 짜는 것은 바쁘다고 무단횡단을 하는것과 유사하다.
•
언제나 코드를 최대한 깨끗하게 유지하는 습관이 기한을 맞추는 유일한 방법이다.
깨끗한 코드란 무엇인가?
1. 우아하고 효율적인 코드를 작성하자.
•
나쁜 코드는 나쁜 코드를 불러온다. (나쁜코드를 고치면서 더 나쁜코드를 작성한다.)
깨진 유리창 이론(broken windows theory)
-깨진 유리창 하나를 방치해두면 그 지점을 중심으로 범죄가 확산되기 시작한다는 이론
•
오류처리를 철저하게 하라.
⇒메모리 누수, 경쟁 상태(race condition), 일관성 없는 명명법
•
한 가지를 잘하는 코드를 작성하라.
⇒ 하나의 메소드에 여러가지 로직이 들어가는것은 좋지 않다.
2. 가독성이 좋은 코드를 작성하자.
•
깨끗한 코드는 잘 쓴 문장처럼 읽혀야 한다.
•
코드는 추측이 아닌 사실 기반으로 반드시 필요한 내용만 담아야 한다.
◦
설계자의 의도를 한 눈에 볼 수 있도록 하자.
3. 다른 사람이 고치기 쉬운 코드를 작성하자.
•
의미가 있는 이름을 짓자.(메소드명)
•
의존성은 최소한으로 해 객체(메소드)간 결합도를 낮추자.
•
테스트케이스가 있는 코드를 작성하자.
4. 코드를 주의깊게 작성하라.
•
시간을 들여 깔끔하고 단정하게 정리해서 작성하라.
5. 중복이 없는 코드를 작성하라.
•
메서드가 여러 기능을 수행한다면 기능을 명확히 기술하는 메서드 하나와 기능을 실제로 수행하는 메소드 여러개라 분리하라.
•
중복을 피하라
•
한 기능만 수행하라
•
제대로 표현해라(가독성)
•
작게 추상화해라.
보이스카우트 규칙
캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라.
—로버트 스테펜슨 스미스 바덴-파웰이 스카우트에게 남긴 작별인사
•
한 번에 너무 많은 노력을 하기보다는 작은 것 하나씩 고쳐보자.
◦
중복제거, 메소드 분리, 복잡한 if문 정리
결론
책은 레시피에 불과하고 정보수집이다. 이를 실제로 구현하고 적용하기위해선 '연습'을 해야한다.
1.
나쁜 코드를 가만두지 말아라.
2.
중복은 제거하라
3.
메소드의 기능은 잘개 쪼개라
4.
네이밍은 명확하게 지어라
5.
테스트케이스를 작성하라.
6.
오류 처리를 철저하게 하라
