깨끗한 코드
-
그들(관리자들)이 일정과 요구사항을 강력하게 밀어붙이는 이유는 그것이 그들의 책임이기 때문이다. 좋은 코드를 사수하는 일은 바로 우리 프로그래머들의 책임이다.
-
나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가답지 못하다.
공통 적으로 이야기하는 내용
- 가독성
- 되도록이면 작은 단위로
- 이름의 중요성
- 기능은 한가지만 실행하도록
그 외
- 의존선을 최대한 출여야 한다. (Bjarne Stroustrup)
- 세세한 사항까지 꼼꼼하게 신경써야 한다. = 세세한 오류 처리 (Bjarne Stroustrup)
- 깨끗한 코드는 잘 쓴 문장처럼 읽힌다. (Grady Booch)
- 코드는 추측이 아니라 사실에 기반해야 한다. 반드시 필요한 내용만 담아야 한다. 코드를 읽는 사람에게 프로그래머가 단호하다는 인상을 줘야 한다.(Grady Booch)
- 깨끗한 코드란 다른 사람이 고치기 쉽다고 단언한다.(Dave Thomas)
- 깨끗한 코드는 언제나 누군가 주의 깊게 짰다는 느낌을 준다. 고치려고 살펴봐도 딱히 손 댈 곳이 없다.(Micheal Feathers)
- Ron Jeffries
- 중복 줄이기, 표현력 높이기, 초반부터 간단한 추상화 고려하기
- 모든 테스트를 통과한다.
- 중복이 없다.
- 시스템 내 모든 설계 아이디어를 표현한다.
- 클래스, 메서드, 함수 등을 최대한 줄인다.
우리는 저자다
- … 우리는 저자다. 저자에게는 독자가 있다. 그리고 저자에게는 독자와 잘 소통할 책임도 있다. 다음에 코드를 짤때는 자신이 저자라는 사실을, 여러분의 노력을 보고 판단을 내릴 독자가 있다는 사실을 기억하기 바란다.
- …급하다면, 서둘러 끝내려면, 쉽게 짜려면. 읽기 쉽게 만들면 된다.
결론
- 예술과 관련된 책을 읽었다고 해서 예술가가 될 수 있는 것은 아니다. 책을 읽는 것만으로 끝나는 것이 아니라 습관을 들이려고 노력하고 많은 시간동안 공들여 연습해야 좋은 코드를 작성 할 수 있다.
의미있는 이름
권장하는 이름 짓기
- 분명한 의도
- 의미있는 구분
- 검색하기 쉬운 이름 사용
- 한 개념에는 한 단어만
- 해법 영역에서 가져온 이름 사용
- 문제 영역(전문가 영역)에서 가져온 이름 사용
- 의미있는 맥락 추가
- 클래스 이름(or 객체 이름)
- 명사나 명사구가 적합. 동사는 사용하지 않는다.
- 메서드 이름
하지 말아야 하는 이름 짓기
- 그롯된 정보 피하기
- 인코딩 피하기
- 기억력을 믿지 않기
- 기발한 이름 피하기
- 말장난 금지
- 불필요한 맥락 삭제