1. 깨끗한 코드

1장 깨끗한 코드

코드는 사라지지 않는다

• 시간이 갈수록 프로그래밍 언어에서 추상화 수준은 점차 높아질 것으로 예상.
  • ex) DSL(Domain Specific Language) : 도메인 특화 언어로 특정 문제를 해결하기 위해 만든 프로그래밍 언어나 명세 언어
• But, 기계에게 요구사항을 이해시키려면 어느 수준에서는 하나하나 상세한 요구사항을 알려줘야 한다.

→ 코드는 요구사항을 표현하는 언어, 기계를 원하는 목적으로 작동하게 하려면 어느 순간에는 상세한 요구사항(명확한 코드)이 필요

나쁜 코드

• 당장 돌아가는 코드를 짜는 것에 급급하면 나중에 프로그램 유지/보수에 분명 큰 어려움을 만들게 된다.

  "지금은 일단 돌아가게 하고 나중에 고치자.."

  → 지금 짠 코드를 나중에 고칠 시간은 오지 않는다. 코드를 짜는 순간에 고치자

나쁜 코드로 치르는 대가

• 쓰레기 코드 → 한 곳을 고치려면 엉뚱한 곳에서 문제가 생김 → 코드 일부분을 고칠수록 나쁜 코드는 점점 쌓인다.
• 나중에 대대적으로 리팩토링하자는 생각?? → 당연히 오래 걸린다

태도

• 다른 팀의 요구나 클라이언트의 요구로 인해 일정이 촉박했기 때문이라고 핑계댈 수 있다.
  • 하지만 개발 전문가인 개발자가 남 핑계 대는 것은 스스로 전문가가 아님을 자처하는 것이라 볼 수밖에 없다.
  • 개발 전문가로서 나쁜 코드의 위험성을 깨닫고 설득하는 것이 중요

원초적 난제

• 나쁜 코드가 업무 속도를 늦춘다는 사실은 모든 개발자가 안다.
  • 그럼에도 업무 기한을 맞추려면 나쁜 코드를 만들 수 밖에 없다고 생각하는 경우가 많음.

But, 나쁜 코드를 양산하면 후에 코드를 짜는 속도가 느려질 수 밖에 없으므로 오히려 업무 기한 맞추기가 어려워진다.

깨끗한 코드라는 예술?

• 앞의 모든 걸 깨닫고 깨끗한 코드를 짜려 한다 해도 그게 쉬운 일은 아니다.
  1. 우선은 깨끗한 코드와 나쁜 코드를 구분할 줄 알아야 하고,
  2. 절제와 규율을 통해 나쁜 코드를 좋은 코드로 바꾸는 전략도 파악해야 한다.
• '코드 감각'을 통해 좋은 코드를 위한 최고 방안을 선택하고 깨끗한 코드를 작성하자.
  • '코드 감각'이 없으면 노력해서 익히자.

깨끗한 코드란?

유명 프로그래머들에게 물었다.

비야네 스트롭스투룹(Bjarne Stroustrup)

• '우아한' → '보기에 즐거운' : 깨끗한 코드는 보는 사람에게 즐거움을 선사해야 함
• '효율' → 속도/공간적으로 효율적이지 못한 코드도 우아하지 못함
• '유혹' → 나쁜 코드는 유지 보수를 위해 나쁜 코드를 만들고 싶게 하는 유혹을 낳는다.
• '철저한 오류 처리' → 세세한 사항을 꼼꼼히 처리해서 메모리 누수, race condition, 일관성 없는 명명법 등을 막자.
  • '한 가지에 집중' → 나쁜 코드는 너무 많은 일을 하려 애쓰다가 의도가 뒤섞이고 목적이 흐려진다. 깨끗한 코드는 한 가지에 '집중'한다. 각 함수, 클래스, 모듈은 한 길만 걷는다.

그래디 부치(Grady Booch)

• '가독성'을 강조

  • → 해결할 문제와 해법이 명확해야 한다.

• '명쾌한 추상화'

  • → '명쾌'와 '추상화'는 모순적. 코드의 추상

⇒ 코드는 추측이 아니라 사실에 기반해야 함. 반드시 필요한 내용만 담아야 한다.

(추상화가 뇌피셜이 되지 않게 하자)

'big' 데이브 토마스(Dave Thomas)

• 가독성에 더해서 '다른 사람이 고치기 쉽다'는 점을 강조.
  • 읽기 쉬워도 고치기 어려운 코드일 수 있다.
• '테스트 케이스'가 있어야 깨끗한 코드
• '문학적'인 코드 → 인간이 읽기 좋은 코드를 작성하라는 의미

마이클 페더스(Michael Feathers)

• '주의'깊게 작성한 코드

  • → 누군가 시간을 들여 깔끔하고 단정하게 정리한 코드가 깨끗한 코드
    (깨끗한 코드는 거저 얻어지지 않는다)

론 제프리스(Ron Jeffries)

• '중복 줄이기' → 여러 문제를 관통하는 아이디어를 찾자
• '표현력 높이기' → 이름을 의미 있게 짓자 / 여러 기능 수행하는 객체나 메서드는 여러 객체로 나누거나, 메서드 추출 리팩터링을 통해 기능을 명확히 기술하는 메서드 하나와 기능을 실제로 수행하는 메서드 여러 개로 나누자.

워드 커닝햄(Ward Cunningham)

• 너무 당연한 말이지만 그 말대로 코드를 짜는 것이 쉽지는 않다.

우리들 생각(저자의 생각)

• 책의 뒤에서 깨끗한 변수 이, 깨끗한 함수, 깨끗한 클래스 만드는 방법을 소개할 것.

우리는 저자다

• Javadoc에서 @author필드는 저자를 소개. 코드를 짜는 사람은 저자다.

  • → 독자와 잘 소통하자

• 대부분의 노력은 코드를 읽는 것보다 코드를 짜는 과정에 들어가지 않는가?

  • → No. 코드를 짜는 과정에서 많은 시간은 코드를 읽는 시간에 사용된다.

보이스카우트 규칙

• 처음 잘 짜도 시간이 갈수록 엉망이 되는 코드도 많다.
• 코드의 퇴보를 막자!
• 보이스카우트 룰 :
  • 캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라.
  • 한꺼번에 많은 시간과 노력 투자해서 코드 정리할 필요는 없다.
  • 그러면 시간이 지날수록 코드는 좋아질 것

프리퀄과 원칙

• 이 책은 Agile Software Development: Principles, Patterns, and Practices(PPP)의 프리퀄.
• PPP는 이 책에서 하는 이야기를 이어나가므로 나중에 읽어봐라.

결론

이 책을 읽는다고 뛰어난 프로그래머가 된다는 보장은 없다.
→ 실천해야 발전한다!

---