코드가 얼마나 복잡한가에 대한 근거

코드가 얼마나 복잡한가에 대한 근거

출처

• https://www.youtube.com/watch?v=zMmoOuIG8Aw
• 죠니데브 유튜브

생각의 시작

• 함수를 덜 복잡하게 작성하고 싶다
• 코드리뷰 피드백을 줄 때 '복잡하다'라는 표현을 수치로 전달할 수 없을까

정성적 vs 정량적

• 정성적 - 응답자의 주관적 견해와 판단으로 분석(ex. 상품평)
• 정량적 - 수치를 토대로 분석
• 피드백은 최대한 객관적인 것이 중요
• "함수가 조금 복잡한거 같아요.."라는 두리뭉술한 의견을 최대한 객관적으로 표현하려면?

정성적일 수 있는 근거들

• 개발자의 역량에 따라 기준이 달라 애매함
• 모든 상황에 100% 쉽게 적용하기 어려움
• 개인 취향으로 생각하는 개발자도 있다.

1. 파라미터 갯수

   • 메서드 하나가 여러 동작을 하나? 의심갈 수 있음
   • 파라미터가 많으면 테스트하기도 힘들다.
   • 근데 굳이 파라미터 갯수 때문에 함수를 쪼개는건 의미없는 일이고 나중에 무슨 의도를 가지고 만든 함수인지 알기도 어려움

2. if문 중첩

   • 콜백헬이나 마찬가지이다. if문 헬
   • 주요 로직 실행 전에 예외처리 및 반환 가능한 상황을 미리 처리한다

3. Pure Function

   • 같은 입력값에 같은 출력을 하는 함수
   • 외부 값을 수정하지 않는 함수
   • 인자를 수정하지 않는 함수
   • 이게 순수함수고 반대가 비순수함수
   • 비순수함수는 입력값과 결과값을 예측할 수 없음.
   • 하지만 전혀 안쓸 수는 없다. DOM에도 접근하고 api에도 접근해야하니까.
   • 순수함수 일건 순수함수로 최대한 만들어서 그 부분에서라도 디버깅하기 쉽게 만들자.

그나마 정량적인 근거

1. Cyclomatic complexity 순환 복잡도

   • 소스코드의 복잡도를 나타내는 지표
   • eslint rule에 'complexity'로 존재함
   • 코드에서 각 문을 만날때마다 값을 증가시킴
   • 근데 이 방식은 예외사항이 많음

2. Cognitive Complexity 인지 복잡도

   • 이해하기 어려운 정도를 정확히 측정하기 위해 개발
   • eslint-plugin-sonarjs의 'cognitive-complexity'
   • 순환 복잡도와 측정 규칙이 좀 다름.
   • https://www.sonarsource.com/docs/CognitiveComplexity.pdf 여기서 확인할 수 있다.
3. Branch Coverage
   • 우리가 코드를 100줄 짰을 때 테스트를 돌려서 100줄이 모두 실행되면 Line Coverage는 100%임.
   • Branch Coverage는 코드의 분기에 따른 모든 실행 경로를 테스트 했는지 나타내는 지표.
   • if문 하나에 50%로 떨어지고, if문 중첩이면 25로 떨어지는 방식
   • Branch Coverage 경로 숫자를 줄이자.