1장 - 코드 품질

우리가 고품질의 코드를 원하는 이유

• 요구 사항을 완전하게 충족한다.
• 요구 사항 변화에 대해 사소한 작업만 해도 유연하게 대응이 가능하다.
• 오류 발생 시 시스템이 복구되거나 부분적으로 작동한다.
• 예상되지 않은 상황도 처리한다.
• 시스템 공격에도 손상되지 않는다.

 

간단한 5줄이지만 사실 이것만 지키기에도 어려워 보입니다.

특히 예상하지 못한 오류 발생 시 데이터 정합성도 잘 지켜주어야 합니다.

 

우리가 작성한 코드가 소프트웨어가 되어가는 과정

• 개발자가 열심히 코드를 작성한다.
• 동료 개발자에게 코드 검토를 요청한다.
• 검토완료된 코드를 코드베이스로 병합한다.
• 프로덕션 서버에 배포한다.
• 테스트를 수행해 보고 문제가 발생하면 롤백하고, 그렇지 않으면 이제 코드가 소프트웨어가 된다.

 

코드를 작성할 때 네 가지 상위 수준의 목표

• 작동해야 한다.
• 작동이 멈추면 안 된다.
• 변화하는 요구 사항에 적응해야 한다.
• 이미 존재하는 기능을 또다시 구현해서는 안 된다. (어떻게 보면 "바퀴를 재발명하지 말자"와 비슷한 맥락)

 

우리는 항상 코드를 유지보수하면서 변경사항이 생길 때 이 변경이 다른 기능에 어떤 영향을 줄지에 대해 고민을 하며 시간을 많이 보냅니다. 이런 관점에서 2번째와 3번째 목표와 어느 정도 부합합니다.

예를 들어 변경 사항 때문에 다른곳의 작동이 멈추면 안 됩니다.

 

극단적인 케이스

• 앞으로 어떻게 변경될지를 예측하여 모든 잠재적 변화를 지원하기 위해서 노력하지만 이로 인해 개발기간이 1년으로 늘어나고 경쟁자가 몇 달 먼저 시장에 나온다.
• 변할 수 있는 사실을 완전히 무시하며, 3개월 이내에 첫 번째 버전을 출시하지만 새로운 요구사항을 반영하기 위해서는 3개월의 시간이 걸린다. 이로 인해 사용자의 요구 사항을 충족하는 소프트웨어를 만들 때쯤에는 경쟁사에 뒤쳐진다.

 

사실 극단적인 케이스들이지만 어떤 지점에 최적인지는 아무도 모르며 이는 진행하는 프로젝트와 조직 문화에 따라 다릅니다.

 

 

코드 품질의 핵심 요소

1. 코드는 읽기 쉬워야 한다.
2. 코드는 예측 가능해야 한다.
3. 코드를 오용하기 어렵게 만들라.
4. 코드를 모듈화 하라
5. 코드를 재사용 가능하고 일반화할 수 있게 작성하라.

6. 테스트가 용이한 코드를 작성하고, 제대로 테스트하라.

 

 

만약 코드가 읽기 어렵다면 동료 개발자가 코드를 이해하는 데 시간을 많이 들여야 합니다.

자연스럽게 중요한 세부 사항을 놓칠 가능성이 커집니다.

 

우리는 코드를 많이 작성하는 것에 대한 대가를 받는 것이 아니라 문제를 해결한 것에 대한 대가를 받는다.

최대한 코드를 적게 작성하면서 문제를 해결하는 것이 좋다.

 

고품질의 코드 작성은 일정을 지연시킬까?

처음에는 그렇게 느껴질 수도 있습니다.

하지만 중장기적으로는 개발시간을 단축시켜 줍니다.

 

떠오르는 대로 코딩하면 처음엔 시간을 절약할 수 있지만, 머지않아 취약하고 복잡한 코드베이스로 이어질 가능성이 높습니다.

그러면 이해하기 어렵고 추론할 수 없는 코드가 됩니다.

 

우리는 "서두른다고 빨리할 수 있다고 착각하지 말아야 한다"