코드 메트릭: 코드의 좋고 나쁨을 판단하는 지표

코드의 좋고 나쁨을 판단하는 지표

코드 복잡성과 가독성 등의 품질 지표를 코드 메트릭 또는 소프트웨어 메트릭이라고 부릅니다.

---

실행되는 코드의 줄 수 

주석을 제외하고, 실행되는 로직을 포함하는 코드의 줄 수를 의미합니다. 줄 수가 많으면 많을수록, 너무 많은 일을 하고 있을 가능성이 높습니다. 메서드 내부의 줄 수 가 늘어나면, 메서드 내부에서 다루는 변수와 조건 분기가 많을 것입니다. 변수가 많아지고, 조건 분기로 인해 내부 로직이 복잡해지면 코드를 읽고 이해하기 힘들어질 것입니다.

---

순환 복잡도(cyclomatic complexity)

코드의 구조적인 복잡함을 나타내는 지표입니다. 조건 분기, 반복 처리, 중첩은 복잡도를 높입니다. 이 책에서 다룬 조기 리턴, 전략 패턴, 일급 컬렉션 등의 테크닉을 활용하면 복잡도를 줄일 수 있습니다.

 

데이터 클래스는 로직이 따로 없으므로 복잡도가 0입니다. 하지만 다른 클래스의 복잡도에 영향을 줄 수 있으므로 주의해야 합니다.

---

응집도

모듈 내부에서 데이터와 로직이 관련되어 있는 정도를 나타내는 지표입니다. 

모듈은 클래스, 패키지, 레이어 등 다양하게 해석할 수 있습니다. 클래스로 해석하면, 클래스 내부에서 데이터와 로직의 관계가 얼마나 강한지 나타내는 지표라고 생각할 수 있습니다. 구체적으로 인스턴스 변수와 그 인스턴스 변수를 사용하는 로직이 같은 클래스에 구현되어 있으면 응집도가 높다고 할 수 있습니다.

응집도가 높을수록 변경 용이성이 높고 좋은 구조입니다. 응집도를 나타내는 메트릭으로 LCOM(Lack of Cohension in Methods)이 있습니다. 설계 도구도 있습니다.

---

결합도 

결합도는 모듈 간의 의존도를 나타내는 지표입니다.

모듈을 무엇으로 해석할지는 조금 전 응집도를 설명할 때와 같습니다, 예를 들어 클래스로 해석하면 결합도는 '어떤 클래스가 호출하는 다른 클래스의 수'라고 볼 수 있습니다. 클래스를 변경하면 해당 클래스를 호출하고 있는 다른 클래스도 영향을 받을 수 있습니다. 따라서 이런 영향 때문에 버그가 발생하지 않는지 검증을 해야 합니다. 결국 의존하고 있는 클래스가 많으면 많을수록 즉 결합도가 높으면 높을수록 더 넓은 범위를 고려해야 하므로 유지 보수와 사양 변경이 어렵습니다.

 

결합도는 분석 도구를 사용해서 계측할 수 있습니다. 도구가 없어도, 호출하는 클래스의 수를 세거나 클래스 다이어그램을 그려 보면 어느 정도인지 알 수 있습니다. 결합도가 너무 높으면 클래스가 너무 많은 일을 하고 있을 수 있습니다. 즉, 단일 책임 원칙을 위배하고 있을 수 있습니다. 이때는 의존을 더 줄일 수 없는지, 클래스를 더 작게 분할할 수 없는지 검토해 보는 것이 좋습니다.

---

청크

청크는 코드 메트릭이 아니지만 제가 자주 사용하는 지표이므로 소개하겠습니다. 

인간의 기억은 단기 기억과 장기 기억으로 분류할 수 있습니다. 최근 인지심리학 연구 결과에 따르면 인간의 단기 기억은 한 번에 4+-1개의 개념 정도만 파악할 수 있다고 합니다. 그래서 이 숫자를 매지컬 넘버 4라고 부릅니다. 또한 기억할 수 있는 정보 덩어리의 단위를 청크라고 부릅니다.

예를 들어 안녕하세요는 영어로 Hello입니다. 이는 H,E,L,L,O라는 5개의 문자로 구성됩니다. Hello를 처음 배우는 사람은 이를 5-청크로 인식합니다.(참고로 반복 학습을 통해 기억에 정착되면 Hello가 하나의 덩어리로 기억되어 1-청크가 됩니다.)

 

프로그래밍은 굉장히 많은 종류의 데이터/로직을 보는 직업입니다. 데이터와 사양 변경이 어디에 영향을 주는지 버그가 발생하지 않는지 등 다양한 요소를 보고 검증해야 합니다.

그런데 수많은 변수를 사용하며 수천~수만 줄로 이루어진 거대한 클래스를 보고 각각의 변수와 로직을 파악할 수 있을까요? 제대로 파악할 수 없고 오히려 혼란스러울 것입니다 거대한 클래스에서 다루는 개념의 수가 매지컬 넘버 4를 넘기 때문입니다. 물론 구현 담당자처럼 관련 개념을 오랫동안 생각해 온 사람이라면 장기 기억으로 정착되어 이해할 수도 있습니다. 하지만 후임 담당자처럼 코드를 처음 접하는 사람에게는 단기 기억에 굉장한 과부하가 걸려, 이해하기 힘들 것입니다.

 

클래스를 설계할 때도 매지컬 넘버 4를 염두에 두고 뇌가 쉽게 받아들일 수 있는 구조인지 생각해보세요. 클래스에서 다루는 개념이 4+-1정도가 되도록 설계하고 이보다 큰 클래스는 작은 클래스로 분할하는 것이 좋습니다.

 

클래스의 크기와 관계없이 다루는 개념의 개수는 시스템 전체적으로 보았을 때 그대로이니 큰 차이가 없는 것 아닐까?라고 생각할 수도 있습니다. 하지만 중요한 것은 밀접한 개념끼리 응집하는 것입니다. 거대한 클래스에서는 어떤 개념과 어떤 개념이 서로 밀접한지 구분하기 힘듭니다. 강하게 연결된 개념끼리 응집시켜서 각각을 작은 클래스로 분할해 두면 개념들의 관계를 훨씬 쉽게 파악할 수 있습니다. 

 

클래스 설계의 기본, 단일 책임 원칙을 준수하면 쉽게 매지컬 넘버에 맞출 수 있을 것입니다.

 

 

https://learn.microsoft.com/ko-kr/dotnet/csharp/fundamentals/coding-style/coding-conventions

.NET 코딩 규칙 - C#