Medium - Things That You Can Do to Improve Code Quality
in Trend
Trend 파악을 Medium 기고문 요약 포스팅 - 코드의 질을 향상시키기 위해 여러분이 할 수 있는 것들; 분당 실수를 줄이는 방법
Photo by Clem Onojeghuo on Unsplash
형편없이 작성된 코드는 정말로 큰 재앙이 될 수 있습니다. 코드의 복잡도가 증가하면 유지보수에 걸리는 시간도 증가합니다. 가장 나쁜 시나리오는 코드가 더 이상 유지보수 될 수 없어서 프로젝트가 천천히 죽어가는 것이죠.
이런 상황을 막기위해서 여러분은 코드의 퀄리티를 신경써야합니다. 코드의 퀄리티에 시간을 투자해야 합니다. 장기적인 관점에서 좋은 코드는 그만한 가치가 있습니다.
퀄리티는 모두의 작업입니다. 여러분이 테스터나 관리자, 개발자에 상관없이 말이죠. 동작하는 수준높은 퀄리티의 코드는 개발 프로세스 전체의 목표가 되어야 할 것입니다.
다음의 리스트는 코드의 퀄리티를 향상시키기 위해 수행되어야 할 6가지의 것들입니다. 몇가지는 개인적으로 수행되어야 하고 나머지는 팀의 노력이 필요합니다.
1. Four-Eyes Principle
four-eyes 원리는 이해하기도 쉽고 실행하기도 쉬운 원칙입니다. 그것은 코드의 작성자를 포함하여 최소 2명이 코드를 리뷰하는 것이죠. 요즘 가장 유명한 방법은 PR 메소드 입니다.
PR은 다른사람에게 여러분이 깃헙 저장소의 브랜치에 변경사항에 대하 알려줄겁니다. 한번 PR이 열리면 여러분은 동료들과 토론 및 변경사항의 가능성에 대해 리뷰를 할 수 있으며 기본 브랜치에 여러분의 변경사항을 통합하기 전에 보충 커밋을 추가할 수 있습니다.
코드 리뷰 중에는 몇가지 요소들이 꼭 평가되어야 합니다. 그런 것들 중 하나는 코드가 컨벤션 규칙을 준수하는 지 확인하는 것입니다. 이것은 linter의 파이프라인을 통해 자동적으로 수행될 수도 있지만 수동으로 체크하기도 합니다.
자동으로 수행될 수 없는 다른 체크요소로는 코드의 유지보수성과 에러처리입니다. 마지막으로 코드의 완전성을 확인해야 합니다. 이 코드가 의도대로 피처의 모든 영역을 담고 있는지 확인해야합니다.
2. Continuous Integration
“개발용 서버에서는 동작했어요”, 더욱 심각한건 “제 컴퓨터에서는 동작했어요”
이런 일이 토론이나 이슈가 되는 것ㅇ을 여러분은 막고싶을 것입니다. 여기서는 정확히 continuous integration(CI)가 큰 역할을 할 것입니다.
CI는 소프트웨어 개발 관습으로 팀 멤버들이 그들의 작업을 수시로 통합하는 것입니다. 대개는 각자의 작업을 매일 통합합니다. 각 통합은 자동화된 빌드(테스트를 포함한)를 통해 통합 에러를 가능한한 빠르게 탐지하며 이를 통해 검증됩니다.
CI의 관점에서 개발자들은 많은 피드백을 빠르게 받을 수 있습니다. CI는 여러분이 두가지 간단한 규칙을 지킬 때 동작합니다.
- 빠른 빌드를 유지하세요. 빌드에 한시간이나 걸리는 것만큼 의욕저하 시키는 것은 없습니다.
- 빌드 고장을 즉시 고치세요. 전체적인 CI관점에서 여러분은 항상 알려진 안정된 기반에서 개발을 해야합니다.
CI는 코드의 질을 향상시키는데 개발자들에게 빠른 피드백을 주기 때문입니다. 테스트가 실패하면 빌드가 실패할 것이고 개발자에게 바로 알려질 것입니다. 게다가 코딩 컨벤션을 확인하기 위한 linter 빌드 스크립트를 작성하는 게 좋습니다. 이것또한 코드의 퀄리티를 향상시켜 줄 것입니다. 명백하게요.
3. Coding Conventions
코딩 컨벤션의 리스트를 가지고 있는 것이 중요합니다. 코딩 컨벤션의 리스트를 만들기 전에 팀의 모든 구성원이 같은 페이지에 있어야 합니다. 이것은 아마 각자 선호하는 컨벤션에 대해 종이에 손으로 쓰게 될 것이고 많은 토론이 필요할 것입니다.
코딩 컨벤션의 리스트를 만드는 것은 변수를 어떻게 선언할 지와 네이밍 컨벤션에 관한 문서화입니다. 규칙의 수는 무제한이고 매우 다양할 수 잌씁니다. 그냥 여러분의 팀에 맞는 것을 사용하세요. 팀원이 좋아한다면 컨벤션 리스트에 해당 규칙을 추가하는 데 거리낌이 없어야합니다. 컨벤션 리스트에서 항목을 삭제하는 것도 마찬가지 입니다.
한번 여러분이 코딩 컨벤션을 갖추게 되면 실제로 팀에 적용하는게 가장 가장 가장 중요합니다. 제가 언급했듯이 가장 좋은 방법은 코딩 컨벤션을 확인하는 linter 파이프라인을 사용하는 것입니다. 게다가 아무런 수동 작업을 요구하지 않습니다. 만약 선택지가 없다면 linter를 여러분의 로컬 환경에 설치하세요. 그냥 커밋이 매번 수행되기 전에 linter를 정기적으로 사용하기만 하세요. 이것은 코드가 더욱 규격화 되어 가독성과 유지보수성을 향상시켜 줄 것입니다.
높은 퀄리티의 코드는 장기적인 소프트웨어 개발 관점에서 재사용 될 수 있고 나쁜 코드에 대해 시간을 많이 소비하지 않으므로 더욱 개발 속도가 빨라지게 됩니다. 또한 새로운 사람이 프로젝트에 참가하는 것도 쉽게 만듭니다.
4. Test, Test, Test
적은 버그를 가지고 있을 수록 코드의 퀄리티가 높은 것입니다. 테스트가 심각한 버그를 걸러내면 코드는 의도대로 동작한다고 보장할 수 있습니다.
명확한 테스트 전략을 가지는 것이 코드의 퀄리티를 향상시키는 데 도움이 됩니다. 아주 최소한 여러분의 코드는 단위테스트가 수행되어야 합니다. 여러분이 통합 테스트나 회귀테스트 같이 다른종류의 테스트를 하고 싶다면 더욱 나아지겠죠.
테스트 피라미드에 따르면 소프트웨어 프로젝트 테스트의 가장 큰 부분은 유닛테스트가 되어야 합니다. 그 이유는 단위테스트가 저렴하고 빠르기 때문입니다. 유닛 테스트와 코드 커버리지 보고서들을 만드는데 도움이 될 수 있는 많은 도구들이 있습니다.
적절히 테스트를 수행하고 코드 커버리지 보고서를 만드는 것은 CI를 통해 자동화가 될 수 있습니다. 코드 커버리지가 요구된 퍼센트지를 달성하지 못하면 빌드에 실패하도록 할 수도 있습니다.
5. Analyze Bugs
여러분의 코드에는 버그가 있을 수 밖에 없습니다. 이런 버그들을 처리하는 것이 매우 중요합니다. 개발자로서 더욱 성장하고 싶다면 여러분의 실수로부터 배우는 것이 중요합니다. 그래서 버그를 분석해야만 합니다.
버그가 일어나면 버그의 영향을 분석하세요. 높은 위험도의 버그인지 아닌지, 높은 위험도의 버그라면 즉시 수정되어야 할 것입니다.
버그를 분석할 때는 스스로 몇가지 질문을 던지는게 좋습니다. 뭐가 잘못되었을까, 왜 이것을 적절하게 테스트하지 않았을까, 어떤 다른 장소에서 이런게 발생할까, 그리고 가장 중요한 것은 어떻게 해야 다시 이런일이 발생하는 것을 막을까 하는 것입니다.
물론 도구를 사용하는 것이 버그를 추적하는 데 도움이 됩니다. 시장에 사용가능한 버그 트래커가 매우 많습니다. 여러분의 요구사항에 맞는 것을 고르세요. 진짜 우리가 하는 실수는 아무것도 배운게 없을 때 입니다.
6. Start Measuring
여러분의 코드의 질을 측정하는데 도움이 되는 기준이 몇가지 있습니다.
Defect metric
결함의 수와 결함의 위험도는 전체적인 퀄리티의 중요한 기준입니다. 결함들을 계속 추적하고 싶다면 버그 하강 차트를 사용할 수 있습니다. 버그 하강 차트는 애자일 소프트웨어 개발팀에서 사용하는 일반 하강 차틍입니다. 다른 점은 사용자 스토리 관점이 아니라 고쳐지지 않은 버그의 수를 차트가 나타낸 다는 것이죠.
Complexity metrics
복잡도는 순환 복잡도 기준으로 측정됩니다. 프로그램 소스코드에 선형적으로 독립적인 패스가 몇 개인지 측정한 양입니다. 잦은 결함과 순환 복잡성의 수에는 상관관계가 있습니다. 따라서 낮은 코드 복잡성이 적은 결함을 만듭니다.
Summary
- 좋은 코드를 만드는 6가지 방법
- 코드의 컨벤션을 확인하는 linter 스크립트를 CI에 작성하면 팀적으로 규격화된 코드를 유지할 수 있다!
- 발생한 버그로부터 배우지 않으면 좋은 개발자가 될 수 없다.
