코드 리팩토링을 측정하기위한 객관적인 메트릭이 있습니까?성공적인 리팩토링 측정을위한 메트릭
리팩터링 전후의 findbugs, CRAP 또는 checkstyle을 실행하면 코드가 실제로 변경된 것이 아니라 실제로 개선되었는지 여부를 확인하는 유용한 방법이 될까요?
단순한 개인 취향에 맞게 코드를 변경하지 않고도 코드 검토 프로세스를 개선 할 수있는 경향을 찾고 있습니다. 실패 unittests의
리팩터링 전후의 findbugs, CRAP 또는 checkstyle을 실행하면 코드가 실제로 변경된 것이 아니라 실제로 개선되었는지를 확인하는 유용한 방법이 될까요? 내가 질문 "What is the fascination with code metrics?"에 설명 된대로 실제로
, 모든 측정의 추세 (findbugs, 쓰레기, 무엇이든) 측정의 진정한 부가가치입니다.
그것은 (측정의 진화는) 당신이 정말로 당신의 코드를 만들 필요가 주요 고정 작업의 우선 순위를 당신을 수 있습니다 Sonar이 할 수처럼
도구를 (맹목적으로 모든 메트릭 거기 존중하려고 반대) 이 영역에서 (메트릭 모니터링) 매우 유용 할 수 있습니다.
살은 코멘트에 추가 :
진짜 문제는 변화가 단지 시험 범위가 매우 중요하다, 변화
이 들어
를 추가하는 것이 아니라 가치를 어떤 코드 확인에, 테스트 (유닛 테스트뿐만 아니라 더 큰 "기능 테스트")만이 유효한 대답을 줄 수 있기 때문입니다.
그러나 리팩토링은 명확한 목적 없이는 수행되어서는 안됩니다. "우아함"또는 심지어 "유지하기 더 쉽다"라고만하기 때문에 코드를 변경하려면 이면 충분하지 않은 것일 수도 있습니다.
프로세스에서 수정 될 버그 나 "리팩터링 된"코드의 결과로 훨씬 빠르게 구현되는 새로운 기능과 같은 다른 조치가 있어야합니다. 간단히 말해서 리팩터링의 추가 가치는 메트릭만으로 측정되는 것이 아니라 목표 및/또는 마일스톤과 비교하여 평가되어야합니다.
나는 추세선에 대해 동의합니다. 코드 테스트 적용 범위가 증가하고 한 달에 깨진 빌드 수가 0이고 경고 또는 findbugs 히트 수가 감소하는 경우 분명히 상황은 괜찮습니다. 실제 문제는 코드 변경이 단순히 변경 사항을 추가하는 것이 아니라 가치를 추가하는지 확인하는 것입니다. – sal
번호가 특정 목표에 따라 제로 :
실패한 테스트의 수가 음수 일 때 그것을 좋아합니다. –
... 그 말은 아직 쓰지 않은 사람들조차도 지나쳐 가고 있다는 것을 의미합니다. –
에 작거나 같아야합니다, cyclomatic complexity 같은 통계는 성공의 지표를 제공 할 수 있습니다. 결국 모든 통계는 정보 및/또는 상식을 포착 할 수 없으므로 전복 될 수 있습니다.
건강한 코드 검토 프로세스는 놀라운 일입니다.
트렌드를 포착하여 코드 검토 프로세스를 개선 할 수 있기를 바랍니다.가독성, 속도 또는 객관적으로 측정 할 수있는 모든 것을 향상시키지 않고도 많은 루프를 다시 작성하고 다시 작성하는 것을 보았습니다. – sal
코드 크기. 기능을 중단하지 않고 코드를 줄이는 것은 내 책에서 개선 된 것입니다 (주석을 제거하고 식별자를 줄이는 것은 물론 중요하지 않습니다)
코드의 크기가 작을수록 코드 크기가 작아 지지만 선명도와 이해가 쉽습니다. –
실제로 코드 크기를 줄이면 코드 크기를 늘리는 것보다 선명도와 이해력을 향상시킬 수있는 기회가 훨씬 더 많다고 생각합니다. –
이 메트릭이 프로그래머 성능을 평가하는 데 사용되지 않는다면, 승진 또는 그런 것.
리팩토링 성공을 측정하기위한 측정 기준 (#unit test failure == 0은 제외하고)에서 벗어날 것입니다. 대신 코드 리뷰를 사용합니다.
리팩토링을위한 확실한 대상을 찾기 위해 많은 노력을 기울이지 않습니다. "전에 정확히 똑같은 코드를 본 적이 없습니까?" 나머지 부분에서는 수행하지 않을 작업에 대한 특정 지침을 작성하고 개발자가 개발자에게 알릴 수 있도록해야합니다. 그런 다음 다른 개발자가 표준을 따르지 않은 장소를 찾을 수 있습니다.
상위 수준 리팩토링의 경우 코드 기반 이동 위치와 관련하여 수석 개발자와 설계자가 코드를 살펴볼 필요가 있습니다. 예를 들어, 코드가 오늘날 정적 구조를 갖는 것은 매우 합리적 일 수 있습니다. 보다 역동적 인 구조가 필요하다는 것을 알고 있거나 의심된다면 을 사용하는 대신 팩토리 메서드를 사용하거나 다음 릴리스에서 또 다른 구현이 있음을 알기 때문에 클래스에서 인터페이스를 추출 할 것을 제안 할 수 있습니다.
메트릭의 이점은 없습니다.
사실, 코드 리뷰의 품질을 향상시키기 위해이 데이터를 수집하는 데 흥미 롭습니다. 나는 의심스러운 가치의 너무 많은 변화가 있다고 의심한다. – sal
_measurable_ 값이 되기에는 너무 많은 변화가있을 수 있지만 그것은 모든 것이 측정 될 수는 없다는 사실 때문일 것이다. 코드를 이해하는 것이 얼마나 쉬운 지 어떻게 측정합니까? 코드가 얼마나 유연한 지 어떻게 측정합니까? 이러한 것들을 측정하기위한 메트릭스가 있지만, 정의 상으로는 모두 틀렸다고 생각합니다. –
리팩토링에서 원하는 결과가 두 가지 있습니다. 지속 가능한 속도를 유지하기 위해 팀을 구성하고 생산에있어 결함을 없애고 자합니다.
리팩토링은 TDD (Test Driven Development) 동안 코드 및 유닛 테스트 빌드에서 수행됩니다. 리팩토링은 작을 수 있으며 스토리 카드를 완성하는 데 필요한 코드 조각으로 완성됩니다. 또는 리팩토링은 커질 수 있으며 기술적 인 빚을 처리하기위한 기술 이야기 카드가 필요합니다. 스토리 카드는 제품 백 로그에 배치하고 비즈니스 파트너와 우선 순위를 매길 수 있습니다.
또한 TDD를 할 때 단위 테스트를 작성할 때 코드가 개발됨에 따라 테스트를 리팩토링합니다.
SCRUM에서 정의한 관리 방법은 민첩하게 협업을 제공하고 비즈니스 파트너의 요구 사항과 개발 한 코드가 비즈니스 요구 사항을 충족하는지 확인합니다. 그러나 적절한 엔지니어링 기술 (Extreme Programming에 정의 된대로)없이 프로젝트는 손실 지속 가능한 속도로 진행됩니다. 엔지니어링 관행을 사용하지 않은 많은 민첩한 프로젝트는 구조가 필요했습니다. 다른 한편으로, 관리 및 엔지니어링 민첩한 연습을 모두 훈련하고 고용 한 팀은 무기한으로 배달을 유지할 수있었습니다.
많은 결함이있는 코드가 출시되거나 팀에서 속도, 리팩토링 및 기타 엔지니어링 사례 (TDD, 병렬 처리, 자동화 된 테스트, 단순한 진화 설계 등)를 사용하지 않으면 제대로 사용되지 않습니다.
예, 코드 품질 측정을 통해 리팩터링이 코드의 품질을 향상시키는 지 여부를 알 수 있습니다.
복제. 일반적으로 복제가 적어집니다. 그러나 필자가 사용했던 중복 파인더는 단순히 구조적으로 유사하지만 의미 론적으로는 아무 관계가 없으며 중복 제거해서는 안되는 중복 된 블록을 식별하는 경우가 있습니다. 그러한 가양 성을 억제하거나 무시할 준비를하십시오.
코드 커버리지. 이것은 일반적으로 내가 좋아하는 척도이지만 리팩토링에만 간접적으로 관련되어 있습니다. 당신은 더 많은 테스트를 작성함으로써 낮은 커버리지를 올릴 수 있고 또한해야하지만 리팩토링이 아닙니다. 그러나 리팩토링하는 동안 (다른 코드 변경과 마찬가지로) 코드 적용 범위를 모니터링하여 코드가 다운되지 않도록해야합니다.리 팩터링은 테스트되지 않은 복제 코드 사본을 제거하여 코드 적용 범위를 향상시킬 수 있습니다.
크기 메트릭 코드 줄, 전체 및 클래스, 메서드, 함수 등 줄의 수 A Jeff Atwood post은 몇 가지를 더 나열합니다. 리팩터링이 선명도를 유지하면서 코드 줄을 줄이면 품질이 향상됩니다. 비정상적으로 긴 클래스, 메소드 등이 리팩토링의 좋은 대상이 될 가능성이 있습니다. 수업, 방법 등이 실제 일을 끝내기 위해 평소보다 오래 필요가있을 때 결정할 때 판단력을 사용할 준비를하십시오.
복잡도 메트릭, 예를 들어 순환 복잡도. 리팩토링은 복잡성을 줄이기 위해 노력해야하며, 잘 생각하지 않으면 증가시키지 않아야합니다. 복잡도가 높은 메소드/함수는 좋은 리팩터링 대상입니다.
로버트 C. 마틴의 package-design 측정 : 추상성 - 불안정성 주 계열의 추상성, 불안정성 및 거리. 그는 his article on Stability in C++ Report과 그의 책 Agile Software Development, Principles, Patterns, and Practices에 설명했다. JDepend은이를 측정하는 도구입니다. 리팩토링으로 패키지 디자인이 향상됩니다.
저는 소프트웨어 프로젝트의 품질을 모니터링하기 위해이 모든 것을 사용하여 계속 사용하고 있습니다.
나는 냄새의 관점에서 질문을 봅니다. 냄새는 품질 문제의 지표로 취급 될 수 있으므로 식별 된 냄새 사례의 양이 소프트웨어 코드 품질을 나타낼 수 있습니다.
냄새는 세분성과 잠재적 영향을 기준으로 분류 할 수 있습니다. 예를 들어 구현 냄새, 디자인 냄새 및 건축 냄새가있을 수 있습니다. 리팩토링 실습에서 얻은 이득을 보여주기 전후에 모든 세분성 수준에서 냄새를 식별해야합니다. 사실 리팩토링은 식별 된 냄새에 의해 안내 될 수 있습니다.
예 :
"좋은 디자인"을 객관적으로 정의 할 수 있습니까? "우아한", "현명한"및 "응집력있는"객관적인 점수가 있다면 도움이 될 것입니다. –
내 태그 목록에 주관적으로 추가했습니다. – sal
리팩토링의 가치를 측정하기위한 나의 대답을 완성하고 다른 기준을 추가했습니다. – VonC