유지 관리 성을 의미있게 측정하는 방법은 무엇입니까?

컨텍스트 : 저는 모든 MS 상점의 엔터프라이즈 개발자입니다.

누구나 코드 또는 응용 프로그램의 유지 관리 성 을 객관적으로 측정 하는 좋은 방법을 추천 할 수 있습니까 ?

유지 관리 성 이유 : 그룹의 "품질"지표에 수 많은 버그와 코드 적용 범위 만 관련되어 있습니다. 특히 유지 관리 성을 측정하지 않는 경우 두 가지 지표 모두 게임하기 쉽습니다. 근시안과 마감일은 실제로 해결되지 않은 막대한 양의 기술 부채를 초래합니다.

객관적으로 측정하는 능력 : 대기업 그룹에서 일합니다. 객관적으로 측정 할 수없는 경우 사람들이 책임을 지거나 더 나아질 수 없습니다. 주관적 측정은 일어나지 않거나 지속적으로 일어나지 않습니다.

VS2010 코드 메트릭을 보고 있지만 다른 권장 사항이 있는지 궁금합니다.

유지 보수성 측정의 단점은 미래를 예측하려고한다는 것입니다. 코드 커버리지, 버그 수, LOC, 순환 복잡성 모두 현재와 관련이 있습니다 .

실제로 코드를 그대로 유지 관리 할 수 ​​없다는 구체적인 증거가 없으면 버그를 수정하면 유지 관리 할 수없는 코드로 인해 N 시간의 불필요한 시간이 발생했습니다. 다리를 세우는 것은 본질적으로 어렵습니다. 이 예제에서는 훨씬 간단한 방법으로 충분할 때 지나치게 복잡한 방법론이 사용 되었기 때문일 수 있습니다. 방법론, 패러다임 및 모범 사례를 측정하려고하는 영역으로 들어가는 것은 장기적인 이득없이 거의 점점 어려워집니다.

이 길을 내려가는 것은 불행히도 아무데도 갈 수없는 길입니다. 실질적인 장점이 있고 코드 기반의 명명 규칙 부족과 같은 문제에 대한 개인적인 감정과 관련이없는 근본 문제를 발견하는 데 중점을두고 해당 근본 문제와 관련된 성공 및 실패를 측정하는 방법을 찾으십시오. 그러면 솔루션을 공식화 할 수있는 일련의 빌딩 블록을 구성 할 수 있습니다.

글쎄, 내가 사용하거나 생각한다고 생각하는 척도는 다음과 같습니다.

각각의 독립적 인 단일 한 줄 테이크 아웃 기능 요구 사항에 대해 구현하기 전에 코드베이스를 스냅 샷하십시오. 그런 다음 프로세스에 도입 된 버그를 찾아서 수정하는 등이를 구현하십시오. 그런 다음 diff코드베이스 전후에 코드를 실행하십시오 . 은 diff당신에게 변화를 구현하는 모든 삽입, 삭제 및 수정의 목록이 표시됩니다. (10 줄의 연속 된 코드를 삽입하는 것처럼 하나의 변경 사항이 있습니다.) 몇 개의 변경 사항이 있습니까? 이 숫자가 작을수록 일반적으로 코드를 유지 관리하기가 더 쉽습니다.

소스 코드의 중복성은 오류 수정 코드의 중복과 유사하기 때문에이를 중복 이라고 부릅니다 . 정보는 1 청크에 포함되어 있지만 일관성을 유지하기 위해 모두 함께 수행해야하는 N 청크로 인코딩되었습니다.

나는 이것이 DRY의 아이디어라고 생각하지만 조금 더 일반적입니다. 그 수를 줄이는 것이 좋은 이유는 일반적인 요구 사항을 구현하기 위해 N 변경이 필요하고 오류가 많은 프로그래머로 N-1 또는 N-2 만 올바르게 수행하기 때문입니다. 1 개 또는 2 개의 버그. O (N) 프로그래밍 노력 외에도 이러한 버그를 찾아서 찾아서 수정해야합니다. 그것이 작은 N이 좋은 이유입니다.

유지 관리 가능은 코드 작동 방식을 배우지 않은 프로그래머에게 반드시 읽을 수있는 것은 아닙니다. N을 최적화하려면 프로그래머를위한 학습 곡선을 만드는 몇 가지 작업이 필요할 수 있습니다. 다음은 예입니다. 프로그래머가 향후 변경을 예상하고 프로그램 설명에 방법 지침을 남길 경우 도움이됩니다.

N이 충분히 줄어들면 (최적 1) 소스 코드는 DSL (Domain-Specific-Langage)과 같이 더 많이 읽습니다. 이상적으로는 각 요구 사항이 단일 코드로 복원되기 때문에 프로그램은 문제를 "상태"로 표시하기 때문에 문제를 "해결"하지 않습니다.

불행히도, 나는 사람들이 이것을하는 방법을 많이 배우는 것을 보지 못합니다. 오히려 그들은 정신적 명사가 수업이되어야하고 동사는 방법이되어야한다고 생각하는 것 같습니다. 내 경험에 따르면 N이 30 이상인 코드가 생성됩니다.

유지 보수성이 실제로 측정 가능한 것은 아닙니다. 그의 경험과 선호도에 근거한 개인의 주관적인 견해입니다.

주어진 코드 조각은 완벽한 디자인 아이디어를 제시합니다 .

그런 다음 실제 코드에서 실제 코드와의 편차가 발생하면 100의 값을 일부 숫자만큼 줄입니다. 선택한 비 완전 접근 방식의 결과에 정확히 의존하는 것은 무엇입니까?

예를 들면 :

일부 코드는 일부 데이터 형식을 읽고 가져 오며 문제가있는 경우 오류 메시지를 표시 할 수 있습니다.

완벽한 솔루션 (100)은 하나의 공통 위치에 오류 메시지가 유지됩니다. 솔루션에 코드에서 직접 문자열 상수로 하드 코딩 된 경우 15를 말하십시오. 따라서 유지 관리 성 지수는 85가됩니다.

유지 관리하기 어려운 코드의 한 가지 결과는 버그를 수정하는 데 더 오래 걸리는 것입니다 ( "평균"). 따라서 언뜻보기에 하나의 메트릭은 버그가 할당 될 때 (즉, 수정이 시작될 때)에서 "테스트 준비"일 때까지 버그를 수정하는 데 걸리는 시간 인 것으로 보입니다.

이제는 "평균"(무엇이든) 시간을 얻기 위해 합리적인 수의 버그를 수정 한 후에 만 ​​작동합니다. 추적하는 것이 얼마나 어려운지는 코드의 "유지 보수성"에만 의존하지 않기 때문에 특정 버그에 대해서는 그림을 사용할 수 없습니다.

물론, 더 많은 버그를 수정하면 코드가 "더 쉬워"져서 코드를 더 잘 만들거나 최소한 친숙해지면서 유지 관리하기가 더 쉬워집니다. 즉, 버그가 더 모호 해져서 추적하기가 더 어려워 질 것입니다.

또한 사람들이 버그 수정을 서두르면 점수가 낮아져 새로운 버그가 발생하거나 기존 버그를 올바르게 수정하지 않아 더 많은 작업과 코드가 더 나빠질 수 있습니다.

Visual Studio Code Metrics는 빠른 "유지 관리 성"메트릭을 제공하는 데 매우 적합합니다. 5 가지 기본 메트릭이 캡처됩니다.

• 순환 복잡성
• 상속의 깊이
• 클래스 쿠링
• 코드 라인 (롤업 수준에 따라 방법, 클래스, 프로젝트, 무엇이든 상관 없음)

유지 관리 성 지수는 내가 찾은 것입니다. 다음을 기반으로하는 복합 인덱스입니다.

1. 총 크기 (코드 라인)
2. 클래스 또는 파일 수
3. 방법 수
4. 20 이상의 순환 복잡성 (또는 10-구성 가능, 10이 선호)
5. 복사

간혹 유지 보수성 지수가 낮은 방법을 살펴 보겠습니다 (낮음 =이 방법에는 좋지 않습니다). 거의 확실하게, 유지 관리 성 지수가 가장 낮은 프로젝트의 방법은 다시 쓰기가 가장 필요한 방법이며 읽기 또는 유지하기가 가장 어려운 방법입니다.

참고 항목 백서를 계산에 대한 자세한 내용은.

의미있는 것은 순환 복잡성 과 클래스 커플 링입니다. 복잡성을 제거 할 수는 없으며 관리 할 수있는 부분으로 분할하면됩니다. 이 두 가지 방법을 사용하면 유지 관리하기 어려운 코드를 찾을 수있는 위치 또는 가장 어려운 위치를 파악할 수 있습니다.

순환 복잡도는 코드에 몇 개의 경로가 있는지를 측정 한 것입니다. 각 경로를 테스트해야합니다 (아마도 그렇지는 않습니다). 약 20보다 복잡한 것은 작은 모듈로 나눠야합니다. 순환 복잡도가 20 인 모듈 (이것은 20 개의 연속 if then else블록 으로 이것을 복제 할 수 있음 )은 테스트 할 경로의 상한이 2 ^ 20입니다.

클래스 커플 링은 클래스가 얼마나 밀접하게 바인딩되어 있는지 측정합니다. 이전 고용주에서 작업 한 일부 불량 코드의 예에는 생성자에 약 30 개의 항목이있는 "데이터 계층"구성 요소가 포함됩니다. 해당 구성 요소에 대한 "책임있는"사람은 비즈니스 및 UI 계층 매개 변수를 생성자 / 공개 호출에 실제로 큰 진흙 투성이가 될 때까지 계속 추가했습니다. 메모리가 제대로 작동하면 매개 변수 집합이 약간 다른 약 15 개의 서로 다른 신규 / 개방 통화 (일부는 더 이상 사용되지 않음)가있었습니다. 우리는 그와 같이 더 많은 일을하는 것을 막기위한 유일한 목적으로 코드 리뷰를 제정했습니다. 우리가 그를 부르는 것처럼 보이게하지 않기 위해 팀에서 모든 사람의 코드를 검토 했으므로 4-6 일 동안 반나절을 낭비했습니다. 우리가하지 않았기 때문에 매일 사람들이

맨 아래 줄에, 유지 보수는 정말에서만 측정 할 수 후 하지 요구 하기 전에 . 즉, 코드를 유지 관리해야 할 때 코드 조각을 유지할 수 있는지 여부 만 알 수 있습니다.

변화하는 요구 사항에 코드 조각을 적용하는 것이 얼마나 쉬운 지 측정하는 것이 비교적 분명합니다. 사전에 측정이 불가능하고 요구 사항의 변화에 ​​어떻게 대응할 것인가에 가깝습니다. 즉, 요구 사항의 변화를 예측해야합니다. 그렇게 할 수 있다면 노벨 가격을 받아야합니다.)

SOLID 원칙과 같은 일련의 구체적인 규칙에 따라 일반적으로 유지 관리 성이 향상된다고 생각하는 팀과 합의하는 것이 유일한 방법입니다.
원칙을 잘 선택했다면 (SOLID를 사용하는 것이 우선 선택하는 것이 좋을 것입니다), 원칙을 위반하고 있음을 분명히 보여주고 저자가 책임을지게 할 수 있습니다.
유지 보수성에 대한 절대적인 조치를 장려하면서 팀이 합의 된 일련의 원칙 솔기를 현실적으로 유지하도록 점차적으로 설득하는 것은 매우 어려운 일입니다.

실제로 해결되지 않은 엄청난 양의 기술 부채

"사건으로 인한"기술적 부채는 어떻습니까?

나는 엉터리 코드를 작성하여 프로덕션에 몰두한다.

제대로 유지 관리 할 수없는 것을 관찰했습니다.

그러나이 코드는 법적 컨텍스트가 변경되고 제품 라인에 미래가 없기 때문에 제품 라인에 대한 마지막 기능 라운드입니다.

"기술 부채"는 입법 변경으로 인해 모두 폐기되었습니다.

"유지 보수성"메트릭은 외부 고려 사항으로 인해 "나쁜"에서 "무의미한"메트릭으로 바뀌 었습니다.

어떻게 측정 할 수 있습니까?

피어 코드 검토에서 다음으로 가장 좋은 것은 단위 또는 제품을 코딩하기 전에 실행 가능한 아키텍처를 만드는 것입니다. 빨강 녹색 리 팩터 는 그것에 대해 꽤 깔끔한 방법입니다. Sr. 녀석에게 작업 가능한 인터페이스를 함께 던져 작업을 나누도록하십시오. 누구나 퍼즐 조각을 가져다가 적을 green 수 있습니다. 그 후, 피어 코드 검토 및 리 팩터가 순서대로 이루어집니다. 이것은 내가 일했던 과거의 주요 제품에서 꽤 잘 작동했습니다.

질문 사항

한 달에 한 번 정도 채우기 위해 개발자를위한 익명 설문지를 작성하는 것은 어떻습니까? 질문은 다음과 같습니다.

• 지난 달에 프로젝트 X에 사용한 시간 (대략) [0 % ... 100 %]
• 유지 보수성 측면에서 어떻게 코드베이스의 상태를 평가할 것입니까?
• 프로젝트의 복잡성에 비해 코드 기반을 얼마나 복잡하게 평가할 수 있습니까 [너무 복잡하고, 옳고 간단합니다].
• 코드베이스가 너무 복잡하여 작업 해결에 방해가되는 지점을 얼마나 자주 느끼셨습니까? [절대로, 가끔씩, 자주, 끊임없이] 전혀 아닙니다.

(댓글의 유지 관리 성을 측정하는 데 유용하다고 생각되는 추가 질문을 자유롭게 추가하십시오. 추가하겠습니다.)

유지 보수성을 검토하는 두 가지 방법을 생각할 수 있습니다 (다른 사람들이 좋은 정의를 도출 할 수 있기를 바랍니다.

이해하지 않고 수정.

전체 시스템의 작동 방식을 이해할 필요없이 버그 수정 프로그램이 코드에 들어 와서 문제를 해결할 수 있습니까?

이것은 포괄적 인 단위 테스트 (회귀 테스트)를 제공함으로써 달성 될 수 있습니다. 시스템을 변경해도 시스템이 특정 입력으로 작동하는 방식이 변경되지 않는지 확인할 수 있어야합니다.

이 상황에서 버그 수정자는 시스템에 대한 최소한의 지식만으로 (간단한) 버그를 가져 와서 고칠 수 있어야합니다. 수정 프로그램이 작동하면 회귀 테스트가 실패하지 않습니다. 회귀 테스트가 실패하면 2 단계로 이동해야합니다.

maintainabilty1 = K1 . (Code Coverage)/(Coupling of Code) * (Complexity of API)

이해를 통한 수정.

버그 수정이 사소하지 않은 경우 시스템을 이해해야합니다. 그런 다음 시스템의 문서는 무엇입니까? 우리는 외부 API에 대한 문서를 말하고 있지 않습니다 (상대적으로 쓸모가 없습니다). 우리가 이해해야 할 것은 구현 등에 사용되는 영리한 (해킹 읽기) 트릭이있는 곳에서 시스템이 어떻게 작동하는지입니다.

그러나 문서로는 충분하지 않아 코드를 명확하고 이해할 수 있어야합니다. 코드의 이해도를 측정하기 위해 약간의 트릭을 사용할 수 있습니다. 개발자가 코딩을 마친 후 한 달 동안 다른 작업을 수행하십시오. 그런 다음 부두가 시스템을 이해할 수있을 정도로 시스템을 다시 문서화하도록 요청하십시오. 코드가 이해하기 쉬운 경우에는 빠르다. 잘못 작성된 경우 문서를 작성하고 문서를 작성하는 데 시간이 더 오래 걸립니다.

아마도 우리는 이것에 대해 어느 정도 측정 할 수 있습니다.

maintainability2 = K2 . (Size of doc)/(Time to write doc)

"가장 짧은 동등한"솔루션이 가장 유지 관리가 쉬운 경향이있는 경우가 많습니다.

여기서 가장 짧은 것은 라인이 아닌 가장 적은 연산을 의미합니다. 동등한 것은 짧은 솔루션이 이전 솔루션보다 시간이나 공간이 복잡하지 않아야 함을 의미합니다.

이것은 논리적으로 유사한 반복 패턴을 모두 적절한 추상화로 추출해야한다는 것을 의미합니다. 기능을 추출하십시오. 함께 발생하는 변수? 구조체 / 클래스로 추출하십시오. 유형별로 멤버가 다른 클래스는 무엇입니까? 당신은 일반이 필요합니다. 많은 곳에서 같은 것을 다시 계산하는 것 같습니까? 처음에 계산하고 값을 변수에 저장하십시오. 이렇게하면 코드가 짧아집니다. 그것이 기본적으로 DRY 원칙입니다.

또한 사용하지 않는 추상화는 삭제해야한다는 데 동의 할 수 있습니다. 더 이상 필요하지 않은 클래스, 함수는 데드 코드이므로 제거해야합니다. 버전 관리는 복원해야 할 경우를 기억합니다.

종종 논의되는 것은 한 번만 참조되는 추상화입니다. 콜백이 아닌 함수는 한 번만 호출 될 이유없이 한 번만 호출됩니다. 한 유형 만 사용하여 인스턴스화되는 제네릭이며 다른 유형으로 인스턴스화 될 이유가 없습니다. 한 번만 구현되고 다른 클래스 등에 의해 구현 될 실제 이유가없는 인터페이스. 이러한 것들이 불필요하고 제거되어야한다는 의견은 기본적으로 YAGNI 원칙입니다.

따라서 코드 반복을 발견 할 수있는 도구가 있어야하지만 문제는 최적 압축을 찾는 것과 비슷하다고 생각합니다. 이는 Kolmogorov 복잡성 문제로, 결정 불가능합니다. 그러나 다른 한편으로는 사용되지 않거나 사용되지 않은 추상화는 참조 수에 따라 쉽게 파악할 수 있습니다.

그것은 모든 주관적이며 코드 자체를 기반으로 한 측정은 궁극적으로 무관합니다. 결국 그것은 당신의 요구를 충족시키는 능력에 달려 있습니다. 요청중인 기능을 계속 제공 할 수 있습니까? 가능한 경우 아직 옳지 않은 문제와 그 문제가 얼마나 심각하여 변경 사항이 자주 발생합니까?

나는 단지 유지 보수성을 정의했지만 여전히 주관적입니다. 반면에, 그것은 그렇게 중요하지 않을 수 있습니다. 우리는 고객을 만족시키고 즐기기 만하면됩니다. 그것이 바로 우리가 목표로하는 것입니다.

분명히 당신은 상사 나 동료들에게 코드베이스의 상태를 개선하기 위해 무언가를해야한다는 것을 증명해야한다고 느낍니다. 나는 당신이 변경하거나 추가해야 할 모든 작은 일에 대해 피할 수있는 10 가지 다른 문제를 해결하거나 해결해야한다는 사실에 좌절한다고 말하면 충분하다고 주장합니다. 그런 다음 악명 높은 지역의 이름을 정하고 뒤집어 놓으십시오. 그래도 팀에서 지원을받지 못하면 다른 곳에서 더 나아질 수 있습니다. 주위 사람들이 신경 쓰지 않는다면 요점을 증명해도 마음이 바뀌지 않을 것입니다.