[Clean Code] Ⅰ. 깨끗한 코드

cleancode

Clean Code 3판을 읽고 정리한 글입니다

Ⅰ. 깨끗한 코드

오프닝

사소한 곳에서 발휘하는 정직은 사소하지 않다.
신은 세세함에 깃들어 있다
SW는 80%가 유지보수

코드는 언제나 존재

코드는 사라지지 않음

코드 : 요구사항 상세히 표현하는 수단
하위 어느 수준에 다르면 코드 없이 요구사항 표현이 불가능
기계가 실행할 정도의 상세하게 요구사항을 명시하는 작업 : coding
추상화가 아무리 높아져도 코드가 사라지진 않음
요구사항을 모호하게 주어도 정확한 프로그램 생성? : 절대 불가능
인간도 고객의 감정으로는 성공적인 시스템 구현 불가
제대로 명시한 요구사항 : 코드만큼 정형적 → 테스트 케이스로 사용가능

bad code

이 책은 좋은 코드가 중요하다는 다소 미약한 전제에 기반한다

Kent BeckImplementation Patterns

밥아저씨 : 미약하지 않으며 아주 아주 중요하다
wading(고행) : 나쁜 코드를 헤쳐나가는 작업 → 나쁜 코드는 회사가 문을 닫을 수 있을 정도의 치명적
르블랑의 법칙 : 나중은 결코 오지 않는다
- 일단 급하게 짜고 나중에 손본다고 생각하지 말고 처음 짤 때부터 잘 해야한다

나쁜 코드로 치르는 대가

나쁜 코드는 개발 속도 저하 유발
나쁜 코드가 쌓일 수록 팀 생산성 저하되며 나중에 0에 수렴
인력을 추가 투입?
- 추가 인력은 기존 설계와 히스토리를 잘 모름
- 설계를 잘 모름 → 의도에 맞는 변경과 반하는 변경 구분 못함
- 추가 인력은 생산성 향상 푸쉬 압박 시달림
- 결론 : 나쁜 코드를 더 많이 양산 → 다시 생산성 0

원대한 재설계의 꿈

팀이 재설계 요청, 관리층은 싫지만 어쩔수 없이 허락
두팀의 경주 시작 : 타이거팀-유능하고 똑똑한 TF팀, 기존팀-현재 시스템 유지보수팀
경주는 10년넘게 걸리는 경우도 있음
어마어마한 비용

태도

관리자의 일정과 요구사항을 강력히 푸쉬 → 그들의 책임
프로그래머들의 책임 : 좋은 코드를 사수하는 것
나쁜 코드가 초래하는 프로젝트 실패는 프로그래머들의 큰 책임이 있음
의사 비유: 환자(상사)가 요구해도 의사는 위험한 부분 단호히 거부
프로그래머도 마찬가지 : 나쁜 코드의 위험을 이해 못하는 관리자 말을 그대로 따르는 것은 전문가가 아님

원초적 난제

빨리 가려고 클린 코드 유지 X → 나쁜 코드 양산 → 생산성 저하, 기간 늘어남 → 결국 늦게 감

클린코드라는 예술?

클린 코드 구현 행위 = 그림을 그리는 행위와 비슷
- 그림을 보면 대부분의 사람은 잘 그려졌는지 엉망으로 그려졌는지 안다
- 그림을 잘 구분한다고 그림을 잘 그리진 않는다
- clean code 와 bad code를 구분하더라도 clean code를 작성할 수 있다는 것은 아님
clean code는 ‘코드 감각’을 필요로 함
- ‘청결’이라는 습득한 감각을 이용해 자잘한 기법들을 적용하는 절제와 규율 필요
- 절제와 규율을 적용해 클린 코드로 바꾸는 전략도 파악
코드 감각이 있는 프로그래머는 나쁜 모듈을 보면
- 좋은 모듈로 개선할 방안을 떠올린다
- ‘코드 감각’으로 최고 방안을 선택
- 여정을 계획

클린 코드의 정의

밥 아저씨들이 인터뷰한 수많은 guru들의 클린코드에 대한 주옥같은 정의와 주석들

보이스카우트 규칙

미국 보이스카우트 규칙 : 캠프장은 처음 왔을 떄보다 더 깨끗하게 해놓고 떠나라
이를 반영 : 체크아웃을 할 때 보다 (아주 작게라도) 더 깨끗한 코드를 체크인 해라

정리

bad code

성능이 나쁜 code : 불필요한 연산이 들어가서 개선의 여지가 있는 코드
의미가 모호한 코드 : 이해하기 어려운 코드, 네이밍과 내용이 다른 코드
중복된 코드 : 비슷한 내용인데도 중복된 코드 → 버그 양산

clean code

성능이 좋은 코드
의미가 명확한 코드 : 가독성 좋은 코드
중복이 제거된 코드