코드 품질이란? (코드 품질 기준과 측정)

네부캠에서 그룹 프로젝트로 개발했던 프로젝트를 리팩토링하게 되며 가장 첫번째 목표로 코드 품질 개선을 목표로 잡았다.

 

근데 코드 품질이 정확히 뭘까?
어디가 코드 품질이 나쁜지 어떻게 측정하고 어떻게 개선할까?

 

이 궁금증을 먼저 해결해야 목표를 잡고 계획을 수립할 수 있을 것 같아서 코드 품질에 대해 알아봤다.

💡 코드 품질이란?

코드 품질은 코드의 효율성, 가독성, 유용성에 대해 설명하는 방법이다.

코드 품질의 기준

1. 유지보수성: 기존의 코드를 손상시키거나 새로운 버그를 발생시키지 않고 빠르게 코드를 수정하거나 추가할 수 있는가?
2. 가독성: 코드를 읽고 이해하기 얼마나 쉬운가?
   • 함수/변수 네이밍, 일관된 포맷팅과 코딩 스타일, 적절한 주석, 함수 하나의 크기가 적절한지, 모듈화, 응집도/결합도 등으로 가독성을 판단할 수 있다
3. 확장성: 기존 코드의 대량 수정 없이도 확장을 통해 새로운 기능을 추가하기 쉬운가?
4. 유연성: 다양한 상황에서 적용이 쉬운가?
   • 확장성이 수직적 확장(기능 추가)라면, 유연성은 수평적 확장(다양한 상황에 적용)
5. 간결성: 코드가 단순하고 명확한가?
   • KISS 원칙: “Keep It Simple, Stupid”
6. 재사용성: 코드를 재사용하기 쉬운가?
7. 테스트 용이성: 단위 테스트를 작성하기 쉬운가?

이 기준들은 독립적으로 존재하는 것이 아니라 서로서로 밀접하게 연관되어 있다.

• 간결성 ↔ 가독성: 간단하고 명확한 코드는 자연스럽게 가독성이 향상된다.
• 가독성 ↔ 유지보수성: 읽기 쉬운 코드가 수정도 쉽다.
• 확장성 ↔ 유연성: 확장이 쉬운 코드는 다양한 상황에 적용하기도 쉽다.
• 재사용성 ↔ 유연성: 유연한 코드는 재사용이 용이하다.
• 테스트 용이성 ↔ 유지보수성: 테스트 하기 쉬운 코드가 유지보수도 쉽다.

그러니까 코드 품질 향상을 위해서는 통합적인 시선으로의 접근이 필요하다.

🤔 근데 코드 품질 개선이 왜 필요해?

고품질의 코드는 많은 장점이 있다.

1. 비용 절감
   • 유지보수가 쉬운 코드는 버그 수정과 기능 추가에 드는 시간과 비용을 감소시킨다.
   • 가독성이 좋은 코드는 새로운 팀원의 온보딩 시간을 단축시킨다.
   • 재사용 가능한 코드는 중복 개발을 방지하여 개발 비용을 절감한다.
2. 생산성 향상
   • 잘 구조화된 코드는 개발 속도를 높인다.
   • 테스트가 용이한 코드는 버그를 빨리 발견하고 수정할 수 있게 한다.
   • 확장성이 좋은 코드는 새로운 기능 추가가 쉽다.
3. 리스크 관리
   • 고품질 코드는 버그와 보안 취약점의 위험을 줄인다.
   • 테스트가 용이한 코드는 예상치 못한 장애를 예방하기 쉽다.
   • 유지보수가 쉬운 코드는 핵심 개발자가 떠나도 지속적인 개발이 가능하다.
4. 팀 협업 개선
   • 가독성 좋은 코드는 팀원 간 코드 리뷰를 효율적으로 만든다.
   • 표준화된 코드 품질은 일관된 개발 문화를 만든다.

결국 코드 품질 개선은 단기적으로 손해처럼 보일 수 있지만, 장기적으로는 프로젝트의 성공과 팀의 효율성을 높여줄 수 있는 것이다.

📏 코드 품질을 어떻게 측정하지?

• 정적 코드 분석
  • 실행하지 않은 소스 코드의 텍스트만을 보고 코딩 컨벤션 준수 여부, 버그, 코딩 중복 등을 검사
  • 자바스크립트를 위한 주요 정적 분석 도구에는 ESLint, Prettier 등이 있다.
• 순환 복잡도(Cyclomatic Complexity)
  • 코드의 논리적 복잡도를 수치화
  • 코드의 분기문(if, switch, for 등)의 수로 측정 출처: https://pass25.com/wp-content/uploads/2024/04/소공\_제11장\_1\_순환복잡도.pdf
  • 높은 순환 복잡도는
    • 테스트 어려움
    • 버그 발생 가능성 증가
    • 유지보수 어려움
  • 일반적으로 10 이하가 권장됨 출처: https://blog.naver.com/suresofttech/220811189835?photoView=3
• 코드 라인 수(LOC: Line of Code)
  • 함수나 모듈의 크기를 측정
  • 말 그대로 코드의 라인 수를 세면 됨
  • 파일이 너무 길면
    • SOLID 원칙 중 단일 책임 원칙(SRP, Single Responsiblity Principle)을 위반할 가능성이 높음
    • 가독성 저하
    • 유지보수 어려움
  • 일반적으로 함수는 2030줄 이내, 파일은 200300줄 이내를 권장
  • React 코드도 개인마다 편차가 있기는 하지만, 대부분 250줄 이하를 선호하는 것 같음
• 테스트 커버리지
  • 수행한 테스트가 얼마나 테스트 대상을 커버했는지
  • 커버리지가 100%라고 버그 없는 소프트웨어인 것을 보장할 수는 없음
  • 기준
    • 구문 커버리지(Statement Coverage): 라인 커버리지라고도 하며 코드 한 줄이 한 번 이상 실행된다면 충족
    • 결정 커버리지(Decision Coverage): 조건식이 True/False를 가지는 경우 충족
    • 조건 커버리지(Condition Coverage): 모든 내부 조건에 대해 True/False를 가지게 되면 충족
• 의존성 분석
  • 코드 간의 의존 관계를 분석
  • 측정 항목: 결합도(coupling), 응집도(cohesion)
  • 의존성이 높을수록
    • 변경의 영향도 증가 ⇒ 코드 수정에 필요한 리소스 증가, 기능 추가 어려움
    • 테스트 어려움
    • 재사용성 저하코드 품질이란?코드 품질의 기준

⚒️프로젝트 FE 코드 품질 개선 어떻게 하지???!

현재 상황

• 사용 기술 스택
  • Front-end: React, Vite
  • CSS: Tailwind CSS, shadcn/ui
  • 라우팅: react-router-dom
  • 미디어 송출/수신: mediasoup-client
  • 텍스트 양방향 통신: socket.io
  • http 요청: axios
  • form: react-hook-form

생각한 방향

• 코딩 컨벤션 재정리하고 그 코딩 컨벤션에 맞도록 코드 정리
  • ESLint 설정 다시 확인
• 컴포넌트 분리 및 구조화
  • 긴 컴포넌트 적절한 크기로 분리(순환 복잡도, 코드 라인 수 고려)
    • ex. Broadcast.tsx
  • 로직과 UI 관심사 분리
  • mediasoup 관련 로직 모듈화
• 의존성 관리
  • mediasoup 관련 커스텀 훅 간 의존성 낮추기
  • props drilling 최소화
  • 공통 로직 확인하여 분리

🔗 참고 자료

• https://m.post.naver.com/viewer/postView.naver?volumeNo=36022962&memberNo=22097819
• https://aws.amazon.com/ko/what-is/code-quality/
• https://linearb.io/blog/why-code-quality-is-important-to-measure?r=1
• https://blog.jetbrains.com/ko/qodana/2024/01/top-6-code-quality-metrics-to-empower-your-team/#cyclomatic-complexity-cyc
• https://yummy0102.tistory.com/329
• https://blog.naver.com/suresofttech/220811189835
• https://pass25.com/wp-content/uploads/2024/04/소공_제11장_1_순환복잡도.pdf