previous

<aside> 💡 코드는 항상 존재한다.

</aside>

• 비정형적이거나, 모호한 고객의 요구사항과 감정을 읽고 기계가 실행할 수 있을정도로 요구사항을 명세 코드를 기계가 대체하기는 어렵다.

나쁜 코드

<aside> 💡 나중은 결코 오지 않는다. — 르블랑의 법칙(leblanc's Law)

</aside>

• 일정에 쫒겨 나쁘게 구현한 코드는 개발자의 발목을 잡는다.

• 바쁠때는 나중에 다시 리팩토링하겠다고 다짐하지만 다음은 오지 않는다.

• 나쁜코드와 생산성은 반비례한다.

  

• 재설계를 꿈꾸지만 이미 늦었다. 왜?

  • 새로운 프로젝트는 기존 시스템의 모든 기능을 제공해야한다.
  • 개발 도중 추가/변경되는 기존 시스템의 기능도 따라잡아야한다.
  • 레거시 프로젝트가 크면 클수록 재설계의 길은 기하급수적으로 어려워진다.

나쁜코드의 책임에서 개발자는 벗어날 수 없다.

<aside> 💡 일정 문제를 조율하지 못하는 개발자는 아마추어다.

</aside>

<aside> 💡 나쁜 코드의 위험을 애하지 못하는 관리자 말을 그대로 따르는 행동은 프로가 아니다

</aside>

• 개발자: 고객사가 일정을 너무 적게주고, 설계를 뒤집는 요구사항을 준다.
• CleanCode: 고객사와 PM(프로젝트 관리자)이 요구사항과 일정을 잡으며 개발자에게 요구를 하지만, 프로젝트에 깊숙히 관여한건 개발자도 포함된다. 고객사와 PM은 자신의 임무를 다한 것이고 우리는 우리의 임무와 책임(좋은 코드를 사수하는 일)를 다해야 한다.

바쁘다는건 핑계다.