코드에서 단순성을 어떻게 정의하고 측정 할 수 있습니까?

코드의 단순성에 대한 나의 정의와 이해가 틀렸을 가능성을 이해하는 데 도움이 되는 가독성과 관련된 단순성 에 대한 이전 질문에는 많은 답변이 있습니다 .

코드에서 단순성을 어떻게 정의 할 수 있습니까? 코드 단순성을 측정하기 위해 어떤 소프트웨어 측정 및 메트릭을 사용할 수 있습니까?

복잡성 (또는 단순성과 복잡성의 반대라고 생각하는 경우 단순성)을 측정하는 가장 일반적인 측정 기준은 McCabe의 Cyclomatic Complexity 및 Halstead Complexity Metrics 입니다.

순환 복잡도는 클래스에서 계산 될 수 있지만 주어진 단위, 일반적으로 메서드 또는 함수를 통해 고유 한 경로 수를 측정합니다. 경로 수가 증가함에 따라 작업 메모리 개념과 관련된 주어진 모듈을 통한 데이터 흐름을 기억하기가 더 어려워집니다 . 사이클로 메틱 복잡도가 높으면 모듈을 테스트하는 데 어려움이 있음을 나타냅니다. 시스템을 통한 다양한 경로를 다루기 위해서는 더 많은 테스트 사례가 필요합니다. 사이클로 메틱 복잡성이 높고 결함률이 높은 연구도있었습니다. 일반적으로 10의 순환 복잡도는 단위를 검토하고 리팩토링해야 함을 나타냅니다.

Halstead의 복잡성 측정은 전체 및 별개의 연산자 및 피연산자의 입력을 사용하여 코드의 양, 난이도 및 노력을 계산합니다. (고유 연산자 수 / 2) * (총 피연산자 수 / 고유 피연산자 수) 인 난이도는 시스템 학습 또는 코드 검토 수행과 같은 작업에 대한 코드를 읽고 이해하는 능력과 관련이 있습니다. 다시 시스템 레벨, 클래스 레벨 또는 메소드 / 함수 레벨에서이를 계산할 수 있습니다. 여기 와 여기에서 이러한 측정을 계산하는 방법에 대한 몇 가지 게시물이 있습니다 .

코드 줄을 세는 것만으로도 복잡한 아이디어를 얻을 수 있습니다. 더 많은 코드 줄은 모듈에서 읽고 이해해야 할 것이 더 많다는 것을 의미합니다. 이것을 독립형 측정으로 사용하는 것을 망설입니다. 대신 결함 밀도를 얻기 위해 주어진 모듈의 결함 수와 같은 다른 측정과 함께 사용합니다. 결함 밀도가 높으면 테스트 작성 및 코드 검토 수행에 문제가있을 수 있으며 이는 복잡한 코드로 인해 발생하거나 발생하지 않을 수 있습니다.

팬인 및 팬 아웃은 데이터 흐름과 관련된 두 가지 다른 메트릭입니다. 여기 에 정의 된 것처럼 fan in은 호출 된 프로 시저, 매개 변수 읽기 및 글로벌 변수 read 및 fan out은 지정된 프로 시저, 호출 된 매개 변수 (외부 사용자에게 노출, 참조로 전달)를 호출하는 프로 시저의 합계입니다. 그리고 전역 변수가 쓰여집니다. 다시 말하지만, 높은 팬인 및 팬 아웃은 이해하기 어려운 모듈을 나타냅니다.

특정 패러다임에는 유용한 다른 측정 또는 메트릭이있을 수 있습니다. 예를 들어, 객체 지향 세계에서 모니터링 커플 링 (욕망 낮음), 응집력 (욕망 높음) 및 상속 깊이 (욕망 낮음)를 사용하여 시스템이 얼마나 단순하거나 복잡한지를 평가할 수 있습니다.

물론 많은 측정 값과 측정 항목이 단순히 지표라는 것을 인식하는 것이 중요합니다. 단순성을 높이기 위해 리팩토링이 필요한지 또는 그렇게 할 가치가 없는지 판단하려면 판단을 사용해야합니다. 측정, 메트릭 계산 및 코드에 대해 배울 수 있지만 숫자로 시스템을 설계하고 싶지는 않습니다. 궁극적으로 말이되는 것을하십시오.

단순성을 정의하는 공식 모드를 보는 대신 단순성을 코드 작성 품질의 속성으로 정의하고 싶습니다.

나는 약간의 단순성을 측정하지는 않지만 언제 간단한 것을 호출합니까?

1. 코드 탐색 : 코드를 탐색
하는 것이 얼마나 쉬운가요? API 함수가 작성된 위치를 쉽게 파악할 수 있습니까? 예를 들어 어떤 메소드가 다른 메소드를 호출하는지 (그리고 왜)-호출 흐름을 이해하는 것이 쉬운가?

코드 탐색이 용이 할 때, 코드는 간단한 따라하기.

2. 이름 지정
다른 코딩 표준은 코드를 더 깔끔하게 보이도록 도와줍니다. 가장 중요한 것은 클래스 / 객체 인스턴스 / 변수 / 방법의 이름 지정입니다. 명확하고 모호 이름을 사용 명확하게는에 큰 영향이 단순 코드를. 단순한 이름을 식별하기 어려운 경우, 해당 변수 / 방법이라는 아이디어를 다시 생각할 수 있습니다.

3. 해석 및 참조
각 분석법이 명확한 역할을 수행합니까? 각 변수 / 속성들이 그들이 담당하는 역할을 쉽게 결정할 수 있습니까? 코드가 가정을 암시하거나 관련없는 변수 세트에 영향을 미치는 작업을 수행하면 유지 관리의 악몽이 될 수 있습니다.

4. 의존성 또는 결합
코드를 살펴 보는 것만으로 판단하기는 어렵지만 누군가 버그를 고치려고하면 매우 분명해집니다. 다른 객체에서 다른 것들이 변경 되면 여기의 작업이 변경됩니까? 그러한 변화가 명백합니까? 물건을 수용하기 위해 API를 너무 자주 변경해야합니까? 이것은 모듈 간 관계가 간단 하지 않다는 것을 암시합니다

5. 입력 사용자 또는 애플리케이션
마지막으로 API / UI에서 사용자 입력 또는 애플리케이션이 얼마나 간단하게 받아 들여 집니까? 여러 가지 가능한 사용자 / 응용 프로그램 (다른 목적으로)이 귀하에게 제공해야하는 경우 – 분명합니까? 더 높은 추상화와 관련이 없지만 여전히 인터페이스의 앞뒤로가는 상태 / 세부 사항이 있습니까?

내가 일반적으로 묻는 간단한 질문은 다음과 같습니다. 프로그램 대신 사람이 수행하는 동일한 기능을 요청한 경우이 정보를 종이 양식으로 채웠 습니까? 그렇지 않다면, 나는 여기서 충분히 단순 하지 않다.

이 목록이 완전한 것은 아니지만, 기준은 소프트웨어를 사용하고 수정하는 것이 얼마나 쉬운 지 또는 어려운 것 같습니다. 간단합니다.

코드 단순성에 대한 기존의 좋은 메트릭을 알지 못합니다 (존재하지 않는다는 의미는 아닙니다. 단지 알지 못합니다). 나는 몇 가지를 제안 할 수 있습니다. 어쩌면 일부는 도움이 될 것입니다.

• 사용 된 언어 기능의 단순성 : 언어에 "고급"및 "간단한"것으로 간주되는 기능이있는 경우 고급 기능의 발생 횟수를 계산할 수 있습니다. "고급"을 정의하는 방법이 조금 더 주관적 일 수 있습니다. 나는 이것이 프로그램의 "영리함"을 측정하는 것과 같다고 말할지도 모른다. 일반적인 예 : ?:운영자가 "고급"기능이어야 한다고 말하고 다른 사람들은 동의하지 않을 수 있습니다. 이것을 테스트 할 수있는 도구를 작성하는 것이 얼마나 쉬운 지 모르겠습니다.

• 프로그램 내 구성의 단순성 : 함수가 수용 할 매개 변수 수를 측정 할 수 있습니다. > m 매개 변수를 가진 모든 함수의 > n % 가있는 경우 n 및 m 을 정의하는 방법 (n = 3 및 m = 6?)에 따라 단순 하지 않은 것으로 계산할 수 있습니다 . 나는 이것을 측정 할 수있는 정적 분석 도구가 있다고 생각합니다 .JTest는 단순히> m 매개 변수로 함수를 측정했다고 생각 합니다.

• 중첩 루프 또는 제어 구조의 수를 세어 볼 수 있습니다. 이것은 실제로 나쁜 메트릭이 아니며 이름이 있다고 생각합니다 (머리 꼭대기를 기억할 수는 없습니다). 다시 말하지만, 이것을 측정 할 수있는 도구 (JTest와 같은 도구)가 어느 정도 있다고 생각합니다.

• "리팩토링"을 측정 할 수 있습니다. 코드에 리팩토링 할 수 있지만 그렇지 않은 많은 코드가 포함되어 있다면 간단하지 않을 수 있습니다. 나는 또한 JTest와 함께 일했을 때부터 이것을 측정하려고 시도한 것을 기억하지만,이 경우에는 종종 그것에 동의하지 않았으므로 YMMV를 기억합니다.

• 시스템의 다른 부분들 사이의 계층 수를 측정하려고 시도 할 수 있습니다. 예를 들어, 데이터베이스에 저장되기 전에 웹 양식에서 가져온 데이터를 몇 개의 다른 코드 조각으로 만날 수 있습니까? 이것은 제대로 측정하기 까다로운 것일 수 있습니다 ...