Clean Code

by

클린 코드란?

수많은 프로그래머들이 정의한 클린 코드란 무엇일까요?

프로그래머들이 인터뷰를 할 때 좋은 코드가 읽기도 쉽다고 말합니다.

하지만 코드를 쉽게 읽을 수 있는 것만으로

코드가 깨끗하고 올바르게 설계되었다고 말하기에는 충분하지 않습니다.

클린코드는 다음과 같은 특성이 있어야 합니다.

  • 모든 테스트 실행.
  • 중복제거.
  • 프로그래머 의도 표현.
  • 클래스와 메서드 수를 최소화.

* 코드는 안정적이고, 예측 가능하며, 안전하고, 신뢰할 수 있어야 합니다.

코드가 읽기 쉬워도 테스트에 의하여 검증되어야 합니다.

좋은 코드는 항상 테스트와 함께 하여야 합니다.

또한 중요한 것은 테스트의 수 뿐만 아니라 품질도 중요합니다.

코드의 실행 및 디버깅 시 문제가 없으며, 환경에 변화를 일으키지 않아야 합니다.

실무에서 클린 코드를 실천해야하는 이유는 유지보수 시간의 단축입니다.

동료 혹은 과거의 스스로 짠 코드를 빠르게 이해할 수 있다면 유지보수할 때 드는 개발 시간이 짧아집니다.

깔끔한 코드는 코드 리뷰, 코드 파악과 디버깅 시간을 단축시킵니다.

“시간=자원=돈” -> 시간을 줄이게되면 그만큼의 비즈니스 밸류를 창출합니다.

만약 클린 코드를 실천하지 않고 복사&붙여넣기와 같은 방법을 택한다면 * Technical dept가 생길것입니다.

*Technical dept이란 기술 부채를 의미합니다.

현 시점에서 더 나은 접근방식보다 더 쉬운 솔루션을 채택함으로써 발생되는 추가적인 재작업의 비용입니다.

클린 코드를 작성하는데 성공하는 방법은 무엇일까요?

Self-organization와 TeamWork의 두 가지 방법이 있습니다.

1. Self-organization

개별 코드 품질을 개선할 수 있는 몇 가지 방법을 살펴보겠습니다.

이 지침은 모든 개발자에 적합합니다.

1.1 Instruments.

사용되는 도구, 특히 주요 도구인 개발 환경에 주의하여야 합니다.

IDE(통합 개발 환경)는 코드를 즉석에서 보완할 뿐만 아니라 정리해야 할 곳도 제안합니다.

필요한 플러그인으로 IDE를 확장하면 가능한 한 편리하고 유연하게 만들 수 있습니다.

1.2 Participation in open source projects.

팀워크에서는 다른 사람의 코드로 작업하는 능력이 중요합니다.

다른 사람의 코드 스타일을 이해하고, 읽고, 작업하는 것이 항상 쉬운 것은 아닙니다.

다른 사람의 코드로 작업한다면 문제를 해결하기 위한 새로운 접근 방식에 대해 배우는 것이 가능합니다.

1.3 Strict framework.

특정 문제를 해결하는 작은 프로젝트 개발을 시작하세요.

아키텍처를 직접 설계하고 구현하면,

이를 통해 OOP만을 사용한 개발, 10개 이하의 방법의 순환적 복잡성, 주어진 언어의 모든 개발 권장 사항 준수, 디자인 패턴의 의식적인 사용 등과 같은 기술적 한계를 스스로 설정할 수 있습니다.

1.4 Development of abstract thinking.

프로그래밍 패턴을 읽고 사용합니다.

특정 언어에 얽매이지 않고 문제를 보다 효율적으로 해결하는 데 도움이 됩니다.

다른 개발자들과 함께 문제 해결 설계에 대해 동일한 이해를 갖게 될 것입니다.

타사 도구 및 라이브러리의 작동 방식을 더 잘 이해할 수 있습니다.

프로그래밍 기술을 향상시키고 선택한 언어의 복잡성을 배울 수 있는 좋은 방법입니다.

1.5 Decision analysis.

시니어 개발자에게 질문하고 스스로에게도 질문하십시오.

특정 결정의 인과 관계를 이해하는 것은 항상 중요합니다.

문제를 잘 이해하면 효과적으로 해결할 수 있습니다.

좋은 개발자는 코드를 작성하는 장인이 아니라 자신의 코드에 응용, 계획 및 디자인을 결합하는 엔지니어입니다.

1.6 Reading the documentation.

문서를 읽을 수 있다는 것은 코드를 읽는 것만큼 중요합니다.

1.7 Practice.

모든 경험은 경험이 없는 것보다 낫습니다.


2. TeamWork

대부분의 작업은 한 팀으로 진행됩니다.

팀원들 사이에 품질에 대한 책임을 공유하는 것은 매우 중요합니다.

팀이 클수록 제품의 컨디션을 좋게 유지하기가 더 어렵습니다.

위에서 언급한 조건에서 코드를 유지하기 위한 몇 가지 접근 방식을 살펴보겠습니다.

2.1 Code review.

이것은 이해하고 따라야 하는 간단한 원칙입니다.

코드 작성자를 포함하여 최소 2명이 코드를 검토합니다.

코드를 검토할 때 염두에 두어야 할 몇 가지 사항이 있습니다.

  • 하나는 코드가 코딩 규칙을 위반하는지 확인하는 것입니다.

– 이것은 CI(지속적 통합)의 정적 분석기를 사용하여 자동화할 수 있고 자동화해야 하는 프로세스입니다.

  • 나머지는 자동으로 확인할 수 없는 코드 유지 관리 및 오류 처리입니다.
  • 마지막으로 코드의 완성도를 확인해야 합니다.

2.2 Continuous integration.

지속적인 통합의 핵심은 코드의 현재 상태에 대한 많은 피드백을 빠르게 얻을 수 있다는 것입니다.

지속적인 통합은 빠른 피드백을 제공하여 코드 품질을 향상시킵니다.

테스트가 실패하면 빌드가 실패하고 즉시 알림을 받습니다.

코딩 규칙을 확인하고, 코드 품질을 개선하고, 보안을 확인하는 정적 분석기를 빌드 스크립트에 추가합니다.

2.3 Coding Conventions.

코딩 규칙을 갖는 것이 중요합니다.

코딩 규칙의 작성을 시작하기 전에 팀의 모든 사람이 이 코딩 규칙의 중요성을 이해해야 합니다.

이러한 합의가 채택되기 위해선 많은 논의가 필요 합니다.

변수 선언 방법, 명명 규칙 등을 정의하는 코딩 규칙 목록을 만들어야 합니다.

이 목록에는 각기 다른많은 규칙을 포함할수 있습니다.

팀이 만족한다면 코딩 규칙 목록에 새 규칙을 자유롭게 추가하십세요.

목록에서 코딩 규칙을 제거하는 경우에도 마찬가지입니다.

또한 코딩 규칙 목록이 있으면 이를 실행하는 것이 중요합니다.

수동으로 확인 하지 않기 위하여 정적 분석기 및 지속적 통합을 사용하여

코딩 규칙을 확인하는 것 이 좋습니다.

좋은 코드는 장기적인 소프트웨어 개발 속도를 높일 수 있습니다.

재사용 가능하며 개발자는 오래된 버그를 수정하는 데 시간을 낭비할 필요가 없습니다.

또한 새로운 사람들이 프로젝트에 더 쉽게 참여할 수 있습니다.

2.4 Tests.

코드의 오류가 적을수록 품질이 높아집니다.

엄격한 테스트는 중요한 오류를 걸러내고 코드가 의도한 대로 작동하는지 확인합니다.

코드 품질을 향상시킬 때 명확한 테스트 전략을 갖는 것이 중요합니다.

최소한 코드는 모듈식이어야 합니다.

통합 또는 회귀 테스트와 같은 다른 방법을 사용하려는 경우 더욱 좋습니다.

소프트웨어 프로젝트에서 가장 많은 수의 테스트는 단위 테스트여야 합니다.

저렴하고 빠릅니다.

단위 테스트 및 코드 검사 보고서를 만드는 데 도움이 되는 다양한 도구가 있습니다.

테스트 스위트를 실행하고 코드 커버리지 보고서를 생성하는 것은 지속적인 통합을 통해 자동으로 수행될 수 있습니다.

코드 적용 범위가 필요한 비율을 충족하지 않으면 빌드가 실패할 수도 있습니다.

2.5 Error analysis.

코드에 버그가 있는 것은 아마도 불가피할 것입니다.

따라서 이러한 오류를 분석하고 처리하는 것이 매우 중요합니다.

기술을 향상시키고 싶다면 실수로부터 배우는 것이 중요합니다.

오류가 발생하면 몇 가지 질문으로 오류를 분석해야 합니다.

  • 이것은 낮거나 높은 우선 순위 버그입니까?

– 우선 순위가 높으면 즉시 수정해야 합니다.

– 버그가 경미하고 제품이 큰 문제 없이 작업을 완료할 수 있는 경우 버그는 향후 반복에서 수정될 수 있습니다.

  • 뭐가 잘못된 걸까요?
  • 왜 우리는 이것을 확인하지 않았습니까?
  • 또 어디서 이런 일이 벌어지죠?
  • 그리고 가장 중요한 것은, 어떻게 하면 미래에 이런 일이 일어나지 않도록 막을 수 있을까요?

물론 오류를 추적하는 데 도움이 되는 도구도 있습니다.

필요에 따라 시중에서 구입할 수 있는 트래커를 선택할 수 있습니다.

2.6 Collecting metrics.

코드 품질을 수량화하는 데 사용할 수 있는 몇 가지 메트릭이 있습니다.

SonarQube는 이 작업을 쉽게 대처할 수 있습니다.

필요한 모든 중요한 측정항목을 쉽게 수집하는 데 도움이 됩니다.

  • Potential errors

결함의 수와 심각도는 전반적인 품질의 중요한 지표입니다.

오류를 찾는것은 자동화될 수 있고 자동화되어야 하지만 부분적으로만 가능합니다.

코드 검토는 코드 논리 자체의 더 깊은 오류를 식별하는 데 유효합니다.

  • Repetitions of code sections

각 시스템 내에서 단일 표현 원칙을 가져야 합니다.

  • Complexity metrics

복잡성은 종종 순환 복잡성 메트릭을 사용하여 측정됩니다.

프로그램 코드에서 선형 독립 경로의 수를 나타내는 지표입니다.

순환 복잡도의 수와 결함률 사이에는 상관 관계가 있습니다.

이론적으로 코드를 단순화하면 결함이 줄어듭니다.

  • Availability of required comments

적절한 간격의 주석 몇 줄, 모듈, 클래스 또는 메서드에 대한 주석만으로도 코드를 훨씬 더 명확하게 만들 수 있습니다.

  • Test coverage

소프트웨어를 테스트할 때 사용됩니다.

테스트 중에 실행된 프로그램 소스 코드의 백분율을 보여줍니다.

테스트 비율이 떨어지지 않는 기준을 설정해야 합니다.


* 결론

실무에서 클린 코드의 의미는 유지보수 시간을 단축할 수 있는 것입니다.

단순히 읽기 좋고 짧은 코드가 깨끗한 코드는 아닙니다.

코드를 작성한 의도와 목적이 명확하며 다른 사람이 쉽게 읽을 수 있어야 합니다.

참고사이트

참고서적

  • Clean Code (로버트 C. 마틴)

Leave a Comment