• 코드는 요구사항을 표현하는 도구이다.
  • 고도로 추상화된 언어나 특정 응용 분야 언어로 기술하는 명세 역시 코드이다.
• 제대로 명시한 요구사항은 코드만큼 정형적이며 테스트 케이스로 사용해도 좋다!

나쁜 코드

잘나가던 회사를 망하게한 원인은 나쁜코드였다. 그들은 출시에 바빠 코드를 마구 짰다. 기능을 추가할수록 코드는 엉망이 되어갔고, 결국은 감당이 불가능한 수준에 이르렀다.

언급 되었던 회사는 20년 후 망했다. 장기적으로 살피지 않아도, 빠르게 진행되던 프로젝트가 1~2년 만에 정체되는 경우가 꽤 많이 일어난다.

이렇게 만들어진 나쁜 코드들은 생산성 악순환을 만든다.

나쁜 (더러운) 코드를 지속적으로 개선하지 않는다면 장기적으로 부정적인 결과를 가져오게 된다.

나중은 절대 오지 않는다 - Later == Never ( later equals never!)

나중은 절대 오지 않는다. 따라서 시간을 들여 깨끗한 코드를 만드는 노력이 비용을 절감하는 방법일 뿐만 아니라 전문가로서 꼭 필요하다.

좋은 코드가 나쁜 코드가 되는 이유

1. 요구사항 변경
2. 짧은 일정
3. 등등 외적인 요인들

💡 모두 변명임. 잘못은 사실 개발자 자신에게 있다.

기획, 사업 등 에게 적극적으로 정보를 제공하여 사전에 방지해야 한다.

• 커뮤니케이션을 통해 이러한 요인들을 예방하는 것도 개발자의 역량

나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가답지 못하다.

원초적 난제

개발자는 근본적인 가치에서 난제에 봉착한다.

기한을 맞추려면 나쁜 코드를 양산할 수 밖에 없다고 느끼지만, 오히려 엉망진창인 상태로 인해 속도가 늦어지고 기한을 놓치게 된다.

💡 기한을 맞추는 유일한 방법은, 즉 빨리 가는 유일한 방법은, 언제나 코드를 최대한 깨끗하게 유지하는 습관이다.

깨끗한 코드는 어떻게 작성할까?

코드감각

깨끗한 코드를 작성하려면 청결이라는 힘겹게 습득한 감각을 활용해 자잘한 기법들을 적용하는 절제와 규율이 필요하다.

깨끗한 코드란?

1. 비야네 스트롭스트룹 - Bjarne Stroustrup (C++ 창시자)

• 간단한 논리

• 낮은 의존성

• 성능을 최적화

• 깨끗한 코드는 한 가지 일을 제대로 한다.

• 나쁜 코드는 나쁜 코드를 유혹한다.

  • 나쁜 코드를 고치면서 오히려 더 나쁜 코드를 만든다.
  • 깨진 창문

  깨진 유리창 이론 - 위키백과, 우리 모두의 백과사전

2. 그래디 부치 - Grady Booch : UML 창시자

• 깨끗한 코드는 단순하고 직접적이다.
• 잘 쓴 문장처럼 읽힌다.
• 결코 설계자의 의도를 숨기지 않는다.
• 명쾌한 추상화와 단순한 제어문으로 가득하다.

가독성을 강조하고 있다.