📖 좋은 코드, 나쁜 코드

1. 코드 품질

코드 품질이 소프트웨어의 품질에 미치는 영향

• 최초 요구 사항을 완전하게 충족
• 요구 사항의 변화가 있을 때 사소한 추가 작업만이 필요
• 오류 발생 시 시스템이 복구되거나 부분적으로 작동

🔖 고품질 코드는 신뢰할 수 있고, 유지보수가 쉬우며, 버그가 적은 소프트웨어를 생산할 수 있다.

코드 품질의 목표

1. 코드는 작동해야 한다.
   • 코드의 첫 번째 목표는 그것이 애초 작성된 목적대로 동작해야 한다는 것이다.
2. 코드는 작동이 멈추면 안 된다.
   • 코드가 작동하지 않을 수도 있는 상황
     • 코드는 다른 코드에 의존할 수 있는데, 그 코드가 수정되고 변경될 수 있다.
     • 새로운 기능이 필요할 때 코드를 수정해야 할 수도 있다.
     • 우리가 해결하려고 하는 문제는 시간이 지남에 따라 변경된다. 소비자 선호, 비즈니스 요구, 고려해야 할 기술 등이 바뀔 수 있다.
   • 현재는 잘 돌아가지만 미래에 제대로 동작하지 않는다면 그 코드는 별로 유용한 코드가 아니다. 당장 돌아가는 코드를 만들기는 쉽지만, 변화하는 환경과 요구 사항에도 불구하고 계속 작동하는 코드를 만드는 것은 훨씬 더 어렵다.
   • 코드가 계속 작동하도록 보장하는 것은 소프트웨어 엔지니어가 직면하는 큰 과제 중 하나이며, 코딩의 모든 단계에서 고려해야 할 사항이다.
3. 코드는 변경된 요구 사항에 적응할 수 있어야 한다.
   • 코드나 소프트웨어가 시간이 지남에 따라 어떻게 변할지 완벽하고 정확하게 예측하는 것은 불가능하다. 하지만 변한다는 사실 자체를 완전히 무시해야 하는 것은 아니다.
4. 코드는 이미 존재하는 기능을 중복 구현해서는 안 된다.
   • 이미 있는 코드는 다시 작성하지 않는다는 개념은 양방향으로 적용된다. 어떤 하위 수준의 문제를 해결하기 위해 다른 개발자가 이미 코드를 작성했다면, 그것을 해결하기 위해 자신의 코드를 작성하기보다는 그들의 코드를 사용해야 한다. 마찬가지로 자신이 이미 코드를 작성했다면, 다른 개발자들이 동일한 문제를 해결하기 위해 자신만의 코드를 다시 작성하지 않도록 쉽게 재사용할 수 있는 방식으로 코드를 구성해야 한다.

코드 품질의 핵심 요소

1. 코드는 읽기 쉬워야 한다.
   • 코드의 가독성이 떨어진다면, 다른 개발자가 그 코드를 이해하는 데 많은 시간을 들여야 한다. 또한, 코드의 기능에 대해 잘못 이해하거나 몇 가지 중요한 세부 사항을 놓칠 가능성 역시 크다.
2. 코드는 예측 가능해야 한다.
   • 코드가 예상에서 벗어나는 일을 한다면, 그 코드를 사용하는 개발자는 그 상황을 알지 못하거나 그 상황에 대처할 생각을 하지 못할 것이다. 코드가 예상을 벗어나는 일을 수행하지 않는지 주의 깊게 살펴야 하고, 할 수 있다면 그런 코드를 작성하지 않도록 노력해야 한다.
3. 코드를 오용하기 어렵게 만들라.
4. 코드를 모듈화하라.
   • 모듈화된 시스템은 일반적으로 이해하기 쉽고 추론하기 쉬운데, 그닝이 관리 가능한 단위로 나누어지고 기능 단위 간 상호작용이 잘 정의되고 문서화되기 때문이다. 코드가 모듈화되어 작성되면 처음에 작동이 시작되고 그 후에도 계속해서 잘 작동할 가능성이 커진다. 왜냐하면 코드가 하는 일을 개발자들이 오해할 소지가 적기 때문이다.
5. 코드를 재사용 가능하고 일반화할 수 있게 작성하라.
   • 재사용성 : 어떤 문제를 해결하기 위한 무언가가 여러 가지 다른 상황에서도 사용될 수 있음
   • 일반화성 : 개념적으로는 유사하지만 서로 미묘하게 다른 문제들을 해결할 수 있음
   • 코드가 재사용할 수 있고 일반화되어 있으면 하나 이상의 상황에서 사용할 수 있고, 여러 가지 문제를 해결할 수 있다. 이런 코드는 시간과 노력을 절약해주고 더 신뢰할 수 있는데, 그 이유는 실제 서비스 환경에서 이미 시도되고 테스트된 논리를 재사용하기 때문이다.
6. 테스트가 용이한 코드를 작성하고, 제대로 테스트하라.
   • 코드의 테스트 용이성이 낮으면 제대로 테스트하는 것이 불가능할 수 있다. 현재 작성 중인 코드의 테스트 용이성을 확인하기 위해 코드를 작성하면서 어떻게 테스트할 것인가?를 계속 자문하는 것이 좋다. 즉, 코드를 다 작성하고 나서 테스트에 대해 생각해서는 안 된다. 테스트는 코드 작성의 모든 단계에서 필수적이고 기본적인 부분이다.

고품질 코드 작성은 일정을 지연시키는가?

• 단기적으로는 고품질 코드를 작성하는 데 시간이 더 걸릴 수 있다는 것이다. 하지만 중요한 소프트웨어를 개발하고 있다면, 일반적으로 고품질 코드를 작성하는 것이 중장기적으로는 개발 시간을 단축해준다.
• 코드 품질을 고려하지 않고 먼저 떠오르는 대로 코딩하면 처음에는 시간을 절약할 수 있다. 그러나 이런 코드는 머지않아 취약하고 복잡한 코드베이스로 귀결될 것이며, 점점 더 이해하기 어렵고 추론할 수 없는 코드가 된다.

2. 추상화 계층

왜 추상화 계층을 만드는가?

어떤 문제를 하위 문제로 계속해서 나누어 내려가면서 추상화 계층을 만든다면, 같은 층위 내에서는 쉽게 이해할 수 있는 몇 개의 개념만을 다루기 때문에 개별 코드는 특별히 복잡해 보이지 않을 것이다. 문제가 엄청나게 복잡할지라도 하위 문제들을 식별하고 올바른 추상화 계층을 만듦으로써 그 복잡한 문제를 쉽게 다룰 수 있다.

추상화 계층 및 코드 품질의 핵심 요소

1. 가독성
   • 개발자들이 코드베이스에 있는 코드의 모든 세부 사항을 이해하는 것을 불가능하지만 몇 가지 높은 계층의 추상화를 이해하고 사용하기는 상당히 쉽다.
2. 모듈화
   • 추상화 계층이 하위 문제에 대한 해결책을 깔끔하게 나누고 구현 세부 사항이 외부로 노출되지 않도록 보장할 때, 다른 계층이나 코드의 일부에 영향을 미치지 않고 계층 내에서만 구현을 변경하기가 매우 쉬워진다.
3. 재사용성 및 일반화성
   • 하위 문제에 대한 해결책이 간결한 추상화 계층으로 제시되면 해당 하위 문제에 대한 해결책을 재사용하기가 쉬워진다. 그리고 문제가 적절하게 추상적인 하위 문제로 세분화된다면, 해결책은 여러 가지 다른 상황에서 유용하게 일반화될 가능성이 크다.
4. 테스트 용이성
   • 코드가 추상화 계층으로 깨끗하게 분할되면 각 하위 문제에 대한 해결책을 완벽하게 테스트하는 것이 훨씬 쉬워진다.

코드의 계층

• API는 호출하는 쪽에 공개할 개념만 정의하면 되고 그 이외의 모든 것은 구현 세부 사항이기 때문에 코드를 API의 관점에서 생각하면 추상화 계층을 명확하게 만드는 데 도움이 된다. 코드의 일부를 작성하거나 수정할 때, API에 이 수정 사항에 대한 구현 세부 정보가 새어 나간다면 추상화 계층이 명확하게 구분되어 이루어진 것이 아니다.

함수 관점에서의 추상화

• 단일 업무 수행
• 잘 명명된 다른 함수를 호출해서 더 복잡한 동작 구성
• 일단 함수를 작성했으면 작성된 코드를 문장으로 만들어보면 좋다. 문장을 만들기 어렵거나 너무 어색하면 함수가 너무 길다는 것을 의미하고 더 작은 함수로 나누는 것이 유익할 것이다.
• 함수를 작게 만들고 수행하는 작업을 명확하게 하면 코드의 가독성과 재사용성이 높아진다.

클래스 관점에서의 추상화

• 응집력 : 한 클래스 내의 모든 요소들이 얼마나 잘 속해 있는지를 보여주는 척도로, 좋은 클래스는 매우 응집력이 강하다.
  • 순차적 응집력 : 한 요소의 출력이 다른 요소에 대한 입력으로 필요할 때 발생한다.
  • 기능적 응집력 : 몇 가지 요소들이 모여서 하나의 일을 성취하는 데 기여할 때 발생한다.
• 관심사의 분리 : 시스템이 각각 별개의 문제를 다루는 개별 구성 요소로 분리되어야 한다고 주장하는 설계 원칙
• 단일 클래스 내에 얼마나 다른 개념이 들어가 있는지, 그리고 어떤 로직이 재사용이나 재구성에 적합한지에 대해 개발자가 신중하게 생각하지 않으면 클래스는 종종 너무 커진다.
• 한 클래스는 오직 한 가지 일에만 관심을 가져야 한다 혹은 클래스는 응집력이 있어야 한다와 같은 경험칙은 개발자들이 더 높은 품질의 코드를 작성하기 위해 존재한다.

인터페이스 관점에서의 추상화

• 추상화 계층을 깔끔하게 구현하는 코드를 만드는 데 있어 인터페이스는 매우 유용한 도구다. 주어진 하위 문제에 대해 둘 이상의 서로 다른 구체적인 구현이 가능하고 이들 구현 클래스 사이에 전환이 필요할 때는 추상화 계층을 나타내는 인터페이스를 정의하는 것이 가장 좋다.
• 주어진 추상화 계층에 대해 한 가지 구현만 있고 향후에 다른 구현을 추가할 계획이 없더라도 여전히 인터페이스를 사용할 것을 권고한다.
• 장점
  • 퍼블릭 API를 매우 명확하게 보여준다.
  • 한 가지 구현만 필요하다고 잘못 추측한 것일 수 있다.
  • 테스트를 쉽게 할 수 있다.
  • 같은 클래스로 두 가지 하위 문제를 해결할 수 있다.
• 단점
  • 더 많은 작업이 필요하다.
  • 코드가 복잡해질 수 있다.

층이 너무 얇아질 때

• 클래스를 정의하거나 의존성을 새 파일로 임포트하려고 반복적으로 사용하는 코드(보일러 플레이트)로 인해 코드의 양이 늘어난다.
• 로직의 이해를 위해 파일이나 클래스를 따라갈 때 더 많은 노력이 필요하다.
• 인터페이스 뒤에 계층을 숨기게 되면 어떤 상황에서 어떤 구현이 사용되는지 파악하는 데 많은 노력이 필요하다. 이로 인해 로직을 이해하거나 디버깅하는 것이 더 어려워질 수 있다.
• 코드를 서로 다른 계층으로 분할해서 얻는 장점과 비교하면 이 비용이 상당히 낮은 것이지만, 분할을 위한 분할은 의미가 없다는 것을 명심해야 한다.
• 일반적으로 너무 많은 일을 하는 계층은 너무 적은 일을 하는 계층보다 더 문제가 될 수 있다. 따라서 어떤 것이 더 나을지 확실하지 않다면, 너무 많은 계층을 남용하는 결과를 가져오더라도 계층을 여러 개로 나누는 것이 한 계층 안에 모든 코드를 집어넣는 것보다 낫다.
• 최선의 조언은 자신이 만든 계층이 코드의 가독성을 높이고, 재사용할 수 있고, 일반화할 수 있으며, 모듈화되고, 테스트를 용이하게 하는지를 스스로 판단하고 신중하게 생각하는 것이다.