1장. 깨끗한 코드
코드가 존재하리라
- 기계가 실행할 정도로 상세하게 요구사항을 명시하는작업이 프로그래밍이다.
- 제대로 명시한 요구사항은 코드만큼 정형적이며, 테스트케이스로 사용해도 좋다.
- 코드는 요구사항을 표현하는 언어이다.
나쁜코드
왜 나쁜코드를 짰는가?
- 급해서
- 제대로 짤 시간이 없다생각해서
- 코드를 다듬을 시간이 없어서
- 빨리끝내려고
- 다른업무가 너무 밀려있어서
...
...
'나중에 고쳐야지' 하고 주석을 써놓지만,
나중은 결코 오지 않는다 (르블랑의 법칙)
*기술부채
나쁜코드로 치르는 대가
나쁜코드는 개발 속도를 크게 떨어뜨린다
초반에는 빠른 속도로 진행되더라도 1-2년만에 굼뱅이처럼 기어가는 팀도 많다.
얽히고 설킨 코드엔 간단한 변경은 없다.
나쁜 코드가 쌓일 수록 팀 생산성은 떨어지고 마침내 0에 근접한다.
추가인력투입, 재설계를 시도하지만 나쁜코드는 또다른 나쁜코드를 양산한다.
깨끗한 코드를 만드는 노력이 비용을 절감하는 방법일 뿐만 아니라 전문가로서 살아남는 길이다.
태도
- 몇시간이면 될 업무가 몇주로 늘어진 경험
- 한 줄만 고치면 되리라 예상했다가 수백개의 모듈을 건드린 경험
왜 좋은 코드가 순식간에 나쁜 코드로 전락할까?
- 원래의 설계를 뒤집는 방향으로 요구사항이변해서?
- 일정이 촉박해서?
- 멍청한 관리자, 조급한 고객, 쓸모없는 마케팅부서
...
좋은코드가 나쁜코드로 전락한 잘못은 전적으로 프로그래머에게 있다.
대다수의 관리자는 진실을 원한다.
일정에 쫓기더라도 좋은 코드를 원하다.
좋은 코드를 사수하는 일은 프로그래머들의 책임이다.
나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가답지 못하다.
원초적 난제
프로그래머라면 나쁜 코드가 업무 속도를 늦춘다는 사실을 안다. 그럼에도 기한을 맞추려면 나쁜 코드를 양산할 수밖에 없다고 느낀다.
하지만, 나쁜 코드를 양산하면 속도가 곧바로 늦어지고 결국 기한을 맞추지 못한다.
빨리가는 유일한 방법은, 언제나 코드를 최대한 깨끗하게 유지하는 습관이다.
깨끗한 코드라는 예술?
깨끗한 코드와 나쁜 코드를 구분할 줄 안다고 깨끗한 코드를 작성할 줄 안다는 뜻은 아니다.
깨끗한 코드를 작성하려면 '청결'이라는 감각을 활욜해 자잘한 기법들을 적용하는 절제와 규율이 필요하다.
'코드 감각'이 있으면 좋은 코드와 나쁜 코드를 구분하고, 정제와 규율을 적용해 나쁜 코드를 좋을 코드로 바꾸는 전략도 파악한다.
'코드 감각'을 타고나는 사람도 있겠지만, 나는 투쟁해서 얻어야한다.🦾
깨끗한 코드란?
비야네 스트롭스트룹
"깨끗한 코드는 한 가지를 제대로 한다."
- 깨끗한 코드는 보기에 즐거운 코드
- 효울적인 코드
속도뿐만 아니라 CPU자원을 낭비하지 않는 코드 - 나쁜 코드는 나쁜 코드를 '유혹'한다
나쁘 코드를 고치면서 더 나쁜 코드를 만든다
(깨진 창문_데이브토마스,앤디헌트) - 철저한 오류처리 _ 디테일하게
메모리누수, 경쟁상태, 일고나성 없는 명명법 - 나쁜 코드는 너무 많은 일을 하려다 의도가 뒤섞이고 목적이 흐려진다.
깨끗한 코드는 한 가지에 '집중'한다
그래디 부치
"깨끗한 코드는 잘 쓴 문장처럼 읽히며, 결코 설계자의 의도를 숨기지 않는다."
- 가독성
- '명쾌한 추상화'
- 코드는 추측이 아니라 사실에 기반해야 한다.
- 반드시 필요한 내용만 담아야 한다.
데이브 토마스 (big)
- (다른 사람도) 읽기쉽고 고치기 쉬운코드
- 단위 테스트 케이스와 인수 테스트 케이스가 존대
- 의미 있는 이름
- 의존성 최소화
마이클 페더스
- 주의 깊게 작성한 코드 _ 깔끔,단정, 세세한사항까지 꼼꼼하게 신경쓴 코드
론 제프리스
- 중복줄이기
- 표현력 높이기 _ 의미 있는 이름, 클래스/메서드는 한가지 일만
- 클래스, 메서드, 함수 등을 최대한 작게 줄이고 작게 추상화
워드 커닝햄
- 짐작했던 기능을 각 루틴이 그대로 수행하는 코드
- 명백하고 단순한 코드
우리들 생각
위의 오브젝트 멘토 진영이 생각하는 깨끗한 코드를 실천한다면
깨끗하고 수준높은 코드를 작성할 수 있다.
하지만 전대적으로 '옳다'라고 단정짓지않는다.
우리는 저자다
프로그래머는 저자이자 독자이다. 코드를 짤때는 저자라는 사실을 인지하고, 내 코드를 읽을 독자와 잘 소통할 잭임이 있다는것을 기억하자.
새 코드를 짜면서 끊임없이 기존 코드를 읽기도 한다.
읽기 쉬운 코드를 짜기 쉽지 않더라고, 읽기 쉬운 코드르 짜는 것은 중요하다.
(기존 코드를 읽어야 새 코드를 짜므로, 읽기 쉽게 만들면 짜기도 쉬워진다)
급하다면, 서둘러 끝내려면, 쉽게 짜려면 "읽기 쉽게" 만들면 된다
보이스카우트 규칙
잘 짠 코드가 전부는 아니다. 시간이 지나도 언제나 깨끗하게 유지해야 한다.
캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라.
체크아웃할 때보다 좀 더 깨끗한 코드를 체크인한다면 코드는 절대 나빠지지 않는다.
- 변수이름 하나 개선
- 조금 긴 함수 하나를 분할
- 약간의 중복 제거
- 복잡한 if문 하나 정리
...시간이 지날수록 코드가 좋아지는 프로젝트를 만들자!
프리퀄과 원칙
PPP (Principles, Patterns, Preactices)
객체 지향 설계의 다섯가지 원칙 (SOLID)
결론
이 책을 읽는다고 뛰어난 프로그래머가 된다는 보장은 없다. '코드 감각'을 확실히 얻는다는 보장도 없다. 단지 하나의 교본으로 다른 프로그래머가 생각하는 방식과 그들이 사용하는 기술과 기교와 도구를 소개할 뿐이다.
"연습해 연습!"
나의 생각
얼마나 많은 핑계를 대며 코드를 대충 짰는지 다시금 생각해보게 된다.
분명 내가 짠 코드인데 반복해서 읽어야했고, 간단한 수정이라는것은 없었다.
나아가 불편함을 인지하면서도 작은것부터 수정하려는 노력도 부족했다.
바꿔야지 바꿔야지 하면서도 항상 나중이라는 단어를 붙였다.
'나중은 오지않았다'
세세한 것까지 꼼꼼하게 주의를 기울이며
단순히 코드를 적고 끝나지 않고, 나 또한 내 코드를 읽어야한다는 것을 항상 생각해야겠다.
