[좋은 코드, 나쁜 코드 review] 1장 코드 품질

개발자라면 한 번쯤은 들어봤을 법한 책이다. 대부분의 개발자들은 모두 좋은 코드, 성능이 나오는 코드, 오류 없는 코드, 가독성 좋은 코드를 작성하고자 하는 마음이 있을 것이다. 나 또한 그런 생각을 하기 때문에 이 책을 통해 나의 코드의 품질이 보다 개선되길 바란다!

---

목차

1.1 코드는 어떻게 소프트웨어가 되는가
1.2 코드 품질의 목표
1.3 코드 품질의 핵심 요소
1.4 고품질 코드 작성은 일정을 지연시키는가?
요약

---

1장은 다음과 같은 내용을 다룬다.

• 코드 품질이 중요한 이유
• 고품질의 코드가 이루고자 하는 네 가지 목표
• 고품질 코드 작성을 위한 높은 수준에서의 여섯 가지 전략
• 고품질의 코드 작성이 어떻게 중장기적으로 시간과 노력을 절약할 수 있는지

1.1 코드는 어떻게 소프트웨어가 되는가

코드는 일반적으로 엔지니어가 작성하자마자 실제로 실행되는 소프트웨어가 되는 것이 아니다. 코드가 의도한 대로 작동하고 기존의 기능이 여전히 잘 작동한다고 확신하기 위한 다양한 과정과 점검이 이루어진다. 이러한 과정을 종종 소프트웨어 개발 및 배포 프로세스라고 부른다. 

코드로부터 실제 서비스되는 환경에서 실행되는 소프트웨어가 되기까지의 과정에는 많은 차이가 있지만, 주요 단게는 대개 다음과 같다.

1. 개발자가 코드베이스의 로컬 복사본을 가지고 작업하면서 코드를 변경한다.
2. 작업이 끝나면 코드 검토를 위해 변경된 코드를 가지고 병합 요텅을 한다.
3. 다른 개발자가 코드를 검토하고 변경을 제안할 수 있다.
4. 작성자와 검토자가 모두 동의하면 코드가 코드베이스에 병합된다.
5. 배포는 코드베이스를 가지고 주기적으로 일어난다. 얼마나 자주 배포되는지는 조직과 팀마다 다를 수 있음.
6. 테스트에 실패하거나 코드가 컴파일되지 않으면 코드베이스에 병합되는 것을 막거나 코드가 배포되는 것을 막는다.

 

1.2 코드 품질의 목표

고품질의 소프트웨어를 만들기 위해서는 소프트웨어가 잘 구축되어야 한다. 이것이 바로 코드 품질의 진정한 목적이다. 

'코드 품질'은 실제적인 관심 사항에 근거를 두는데 때에 따라 사소하거나 중요한 세부 사항에 관심을 가질 수 있지만 어느 경우나 목표는 동일한데, 그것은 바로 더 나은 소프트웨어를 만드는 것이다. 

그럼에도 불구하고 코드 품질은 여전히 파악하기 어려운 개념일 수 있다. 코드를 고품질 혹은 저품질로 정의하는 것은 본질적으로 주관적이고 다소 성급한 것이다. 본 책의 저자는 코드를 작성할 때 아래와 같은 네 가지 상위 수준의 목표를 달성하려 한다.

1. 작동해야 한다.
2. 작동이 멈춰서는 안 된다.
3. 변화하는 요구 사항에 적응해야 한다.
4. 이미 존재하는 기능을 또다시 구현해서는 안 된다.

1.2.1 코드는 작동해야 한다

우리가 코드를 작성하는 이유는 문제를 해결하기 위함이다. 코드의 첫 번째 목표는 그것이 애초에 작성된 목적대로 동작해야 한다는 것이다. 이것은 또한 버그가 없다는 것을 의미한다. 

코드가 '작동한다'라는 것을 정의할 때, 우리는 모든 요구 사항을 파악할 필요가 있다. (예를 들어 성능 향상에 관한 문제를 해결할 땐 코드가 그에 맞게 수행되도록 하는 것)

1.2.2 코드는 작동이 멈추면 안 된다.

코드는 고립된 환경에서 홀로 실행되는 것이 아니기 때문에 주변 상황이 바뀌면서 동작이 멈출 수 있다.

• 코드는 다른 코드에 의존할 수 있는데, 그 코드가 수정되고 변경될 수 있다.
• 새로운 기능이 필요할 때 코드를 수정해야 할 수도 있다.
• 우리가 해결하려고 하는 문제는 시간이 지남에 따라 변경된다.

1.2.3 코드는 변경된 요구 사항에 적응할 수 있어야 한다

요구 사항은 다음과 같이 변할 수 있다.

• 비즈니스 환경이 변한다.
• 사용자 선호가 변한다.
• 가정이 더 이상 유효하지 않다.
• 새로운 기능이 계속 추가된다.

1.2.4 코드는 이미 존재하는 기능을 중복 구현해서는 안 된다

이미 구현된 코드를 재사용하면 좋은 몇 가지 이유가 있다.

• 시간과 노력을 절약한다.
• 버그 가능성을 줄여준다.
• 기존 전문지식을 활용한다.
• 코드가 이해하기 쉽다.

이미 있는 코드는 다시 작성하지 않는다는 개념은 양방향으로 적용된다. 어떤 하위 수준의 문제를 해결하기 위해 다른 개발자가 이미 코드를 작성했다면, 그것을 해결하기 위해 자신의 코드를 작성하기 보다는 그들의 코드를 사용해야 한다. 

 

1.3 코드 품질의 핵심 요소

위에서 살펴본 네 가지 목표는 우리가 근본적으로 성취하고자 하는 것에 초점을 맞추는 데는 도움이 되지만, 일상적 업무로 하는 코딩 작업과 관련해서는 특별한 조언을 제공하지 않는다. 이러한 목표에 부합하는 코드에 작성하는 데 도움이 될 보다 구체적인 전략을 파악하는 것이 유용하다.

< 코드 품질의 여섯 가지 핵심 요소 >

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

1.3.1 코드는 읽기 쉬워야 한다

코드의 가독성이 떨어진다면, 다른 개발자가 그 코드를 이해하는 데 많은 시간을 들여야 한다. 또한, 코드의 기능에 대해 잘못 이해하거나 몇 가지 중요한 세부 사항을 놓칠 가능성 역시 크다. 이런 일이 일어난다면 코드 검토 중에 버그를 발견할 가능성이 작고, 새로운 기능을 추가하기 위해 다른 사람이 코드를 수정할 때 새로운 버그가 도입될 가능성이 크다. 그 코드가 무엇을 하는지 개발자가 이해하지 못하면, 소프트웨어 전체가 제대로 작동하는 것은 거의 불가능에 가깝다.

1.3.2 코드는 예측 가능해야 한다

우리의 코드를 사용하는 다른 개발자는 이름, 데이터 유형, 일반적인 관행과 같은 단서를 사용해 코드가 입력값으로 무엇을 예상하는지, 코드가 무슨 일을 하는지, 그리고 무엇을 반환하는지에 대한 정신 모델을 구축한다. 이 정신 모델과 어긋나는 어떤 일이 코드에서 일어나면, 이로 인해 버그가 아무도 모르게 코드 내로 유입되는 일이 너무도 많이 일어난다.

코드의 사용자는 그 코드에 의해 일어날 일을 예상하지 않기 때문에 그 일이 실제로 일어날 줄 알지 못한 채 작업을 진행한다. 잠시 동안은 문제가 없는 것처럼 보일 수 있지만 나중에 프로그램이 잘못된 상태에 놓으거나, 이상한 값이 사용자에게 반환되어 심각한 상황을 초래할 수 있다. 

1.3.3 코드를 오용하기 어렵게 만들라

자신이 작성하는 코드는 종종 다른 코드에 의해 호출되는데, 호출할 때 인수가 입력되거나 시스템이 특정 상태에 있을 것을 예상한다. 자신이  작성한 코드가 호출된 데는 이유가 있는데, 그 코드가 잘못 사용된다면 중요한 일이 수행되지 않거나, 이상하게 동작하지만 눈에 띄지 않는다는 것을 의미할 수도 있다.

코드를 오용하기 어렵거나 불가능하게 하면 코드가 작동할 뿐만 아니라 게속해서 잘 작동할 가능성을 극대화할 수 있다.

1.3.4 코드를 모듈화하라

모듈화는 개체나 시스템의 구성 요소가 독립적으로 교환되거나 교체될 수 있음을 의미한다. 모듈화된 시스템의 주요 특징 중 하나는 인터페이스가 잘 정의되어 서로 다른 구성 요소 간 상호작용하는 지점이 최소화된다는 점이다. 

코드를 외부에 의존하지 않고 실행할 수 있는 모듈로 나누는 것이 이로울 때가 많다. 이때 두 개의 인접한 모듈 사이의 상호작용은 한 곳에서 일어나고 잘 정의된 인터페이스를 사용한다. 이렇게 하면 한 가지 기능을 변경한다고 해서 다른 부분까지 변경할 필요가 없기 때문에 변화하는 요구 사항에 더 쉽게 적응할 수 있는 코드를 작성하는데 도움이 된다. 

모듈화된 시스템은 일반적으로 이해하기 쉽고 추론하기 쉬운데, 기능이 관리 가능한 단위로 나누어지고 기능 단위 간 상호작용이 잘 정의되고 문서화되기 때문이다. 코드가 모듈화되어 작성되면 코드가 하는 일을 개발자들이 오해할 소지가 적어지기 때문에 처음에 작동이 시작되고 그 후에도 계속해서 잘 작동할 가능성이 커진다. 

1.3.5 코드를 재사용 가능하고 일반화할 수 있게 작성하라

재사용성과 일반화성은 유사하지만 약간 다른 개념이다.

재사용성(reusability)
어떤 문제를 해결하기 위한 무언가가 여러 가지 다른 상황에서도 사용될 수 있음을 의미한다. 예를 들면 핸드 드릴은 벽, 바닥 판 등에 구멍을 뚫는 데 사용할 수 있기 때문에 재사용 가능한 도구이다. (동일한 문제, 다른 상황)

일반화성(generalizability)
개념적으로 재사용성과 유사하지만 미묘하게 다른 문제들을 해결할 수 있음을 의미한다. 예를 들어 핸드 드릴은 구멍을 뚫는 데 사용될 뿐만 아니라 나사를 박을 때도 사용될 수 있어 일반화성을 갖는다.

코드가 재사용할 수 있고 일반화되어 있으면 그 코드를 코드베이스의 여러 부분에서, 그리고 하나 이상의 상황에서 사용할 수 있고, 여러 가지 문제를 해결할 수 있다. 이런 코드는 시간과 노력을 절약해주고 더 신뢰할 수 있는데, 그 이유는 실제 서비스 환경에서 이미 시도되고 테스트된 논리를 재사용하기 때문이다. 모듈화된 코드 역시 더 높은 재사용성과 일반화성을 갖는다.

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

테스트는 프로세스에서 두 가지 핵심 사항에 대한 주된 방어 수단이 될 때가 많다.

• 버그나 제대로 동작하지 않는 기능을 갖는 코드가 코드베이스에 병합되지 않도록 방지
• 버그나 제대로 동작하지 않는 기능을 갖는 코드가 배포되지 않도록 막고 서비스 환경에서 실행되지 않도록 보장

테스트는 다음과 같은 이유에서 정말 중요하다.

• 소프트웨어 시스템과 코드베이스는 너무 크고 복잡해 한 사람이 모든 세부 사항을 알 수 없고,
• 사람은 실수를 하는 존재다.

테스트와 테스트 용이성은 서로 관련은 있지만 고려하는 사항이 다르다.

• 테스트: 코드 혹은 소프트웨어 전체를 테스트하는 것과 관련있다. 테스트는 수동이나 자동으로 수행된다. 개발자는 일반적으로 테스트 코드를 통해 "실제" 코드를 돌려보고, 모든 것이 정상적으로 작동하는지 확인하고, 이것을 자동화하기 위해 노력한다.
  • 단위 테스트(unit test): 일반적으로 개별 함수나 클래스와 같은 작은 단위의 코드를 테스트한다.
  • 통합 테스트(integration test): 시스템은 일반적으로 여러 구성 요소, 모듈, 하위 시스템으로 구성된다. 이러한 구성 요소와 하위 시스템을 함께 연결하는 과정을 통합이라고 한다. 통합 테스트를 통해 이러한 여러 구성 요소들이 제대로 멈추지 않고 계속 실행하는 지 확인할 수 있다.
  • 종단간(end-to-end) 테스트: 처음부터 끝까지 전체 소프트웨어 시스템에서 작동의 흐름(또는 워크플로우)을 테스트한다. 
• 테스트 용이성(testability): 테스트 대상이 되는 '실제' 코드를 가리키며 해당 코드가 얼마나 테스트하기 적합한지를 나타낸다. 테스트 용이성은 서브시스템이나 시스템 수준에도 적용될 수 있다. 테스트 용이성은 모듈화와 깊은 관련이 있으며, 모듈화된 코드는 테스트 용이성이 더 좋다. 코드의 테스트 용이성이 낮으면 제대로 테스트하는 것이 불가능할 수 있다. 현재 작성 중인 코드의 테스트 용이성을 확인하기 위해 코드를 작성하면서 '어떻게 테스트할 것인가?'를 계속 자문하는 것이 좋다.

 

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

단기적으로는 고품질 코드를 작성하는 데 시가닝 더 걸릴 수 있다. 높은 품질의 코드를 작성하는 것은 보통 우리 머릿속에 떠오르는 것을 바로 코딩하는 것보다 조금 더 많은 생각과 노력이 필요하다. 하지만 한번 사용하고 버릴 사소한 유틸리티성 프로그램이 아닌 좀 더 중요한 소프트웨어를 개발하고 있다면, 일반적으로 고품질 코드를 작성하는 것이 중장기적으로는 개발 시간을 단축해준다.

코드 품질을 고려하지 않고 먼저 떠오르는 대로 코딩하면 처음에는 시간을 절약할 수 있다. 그러나 이러 코드는 새로운 기능을 추가하거나 버그를 수정하는 것이 점점 더 어려워지고 시간도 더 많이 걸리는데, 작동하지 않는 코드를 처리하고 재설계해야 하기 때문이다. 

 

1장 요약

• 좋은 소프트웨어를 만들려면 고품질 코드를 작성해야 한다.
• 실제 서비스 환경에서 실행되는 소프트웨어가 되기 전에 코드는 일반적으로 여러 단게의 검사와 테스트를 통과해야 한다.
• 버그나 제대로 동작하지 않는 기능이 사용자에게 제공되거나 비즈니스에 중요한 시스템에서 실행되는 것을 이러한 검사를 통해 막을 수 있다.
• 테스트는 코드를 작성하는 모든 단계에서 고려하는 것이 좋다. 코드를 다 작성하고 난 후에 고려하는 것이 아니다.
• 고품질 코드를 작성하면 처음에는 시간이 오래 걸리지만, 중장기적으로는 개발 시간이 단축되는 경우가 많다.