생산성을 측정하기위한 SLOC의 유효한 사용이 있습니까?

나는 역동적이고 정적 인 언어에 관해 선임 건축가와 특이하고 간단한 대화를 나 had습니다. 그는 회사 데이터에 따르면 정적 언어를 사용할 때 생산성이 향상 될 수있는 증거가 있다고합니다. 오랜 역사를 가진 대기업입니다. 놀랍게도, 그가 사용한 메트릭은 추가 된 코드 라인이었습니다.

그는 같은 회사 내에서 유사한 문화, 사업 분야 및 충분한 데이터를 가지고, (개인의 고유 한 상황 및 능력과 관련하여) 차이가 충분히 혼합되어 SLOC 지표가 도구와 언어.

이 주장이 엄격한 통계 분석에 의해 뒷받침되는 것은 아니라고 생각하지만 업계에서이 사고 방식을 뒷받침 할 증거가 있습니까?

수석 건축가의 주장은 두 가지를 의미 할 수 있습니다.

1. 이는 회사 의 일반 개발자 가 동적 언어를 사용할 때보 다 정적 언어를 사용할 때 더 많은 코드 줄을 생성 한다는 의미 일 수 있습니다. 예를 들어, 15 명의 개발자가 6 개월 동안 Java를 사용하는 경우 100 KLOC를 작성하고 동일한 15 명의 개발자가 6 개월 동안 Python을 사용하는 경우 50 KLOC 만 작성합니다.

   LOC와 생산성 사이에는 상관 관계가 없습니다. 파이썬에서와 동일한 기능을 생성하기 위해 Java에서 4 배 더 많은 코드 줄이 필요한 경우 어떻게해야합니까? 이것이 사실이라면, 파이썬을 사용하면 위의 KLOC 메트릭을 기반으로 생산성이 두 배가됩니다.

2. 또한 회사의 일반 개발자가 정적 언어를 사용할 때보 다 동적 언어를 사용할 때보 다 코드 줄이 적다 는 것을 의미 할 수도 있습니다. 15 명의 개발자는 6 개월 동안 Java에서 100 KLOC, Python에서 200 KLOC를 작성합니다.

   적은 줄의 코드가 일반적으로 더 나은 반면 (작성, 읽고, 유지하는 코드가 적음), Java 개발자가 Python과 비교하여 얼마나 많은 기능을 생성했는지는 여전히 불분명합니다. 아마도 파이썬 개발자에 비해 절반의 코드를 작성했지만 기능의 절반도 생성했을까요?

두 경우 모두 동일한 기능이 다른 언어로 동일한 양의 코드 줄로 번역되지 않기 때문에 LOC는 중요한 지표 가 아닙니다 . 일부 언어는 더 장황한 경향이 있습니다. 다른 것들은 더 작습니다. 어떤 경우에는 압축이 중요하지만 일반적인 규칙은 없습니다. 극단적 인 예는 매우 간결하지만 가독성으로 인기가없는 Brainfuck 언어입니다. 예를 들어 중괄호와 관련하여 Java는 K & R 스타일을 따르고 C #에서는 공식 스타일을 따를 때 대부분의 경우 여는 중괄호가 자체 라인에 있으므로 인공 언어로 연결됩니다. C #에 대한 LOC 증가 그리고 절차 언어를 객체 지향 언어 또는 기능적 언어와 비교하면 어떻게됩니까?

수석 설계자는 오류가 발생하기 쉬운 메트릭을 사용하는 대신 함께 사용할 때 생산성을 측정하는 메트릭 그룹에 의존 할 수 있습니다. 한 달에 개발 된 기능 수, 코드베이스에 도입 된 버그 수 및 이러한 버그를 해결하는 데 소요 된 시간 기술 부채의 발전 등.이 비교는 처음에는 까다로울 수 있는데, 이는 새로운 언어에 대한 팀의 친숙 함을 고려해야하기 때문입니다. 팀이 익숙해지면 안정적인 메트릭과 팀 구성원의 선호도를 기반으로 선택해야합니다.

LOC 는 일부 좁은 상황에서 가치가 있습니다. 예를 들어, 프로젝트의 크기와 프로젝트의 일부에 대한 힌트를 제공하거나 (종종 평균 측정하기 쉬우면서도 평균적으로 기능 포인트와 관련이 있음) 추가주의가 필요한 메소드 및 클래스를 표시 할 수 있습니다. 그들의 큰 크기의. 그러나 LOC는 관련이없는 사물간에 상관 관계가있는 사람이 너무 자주 오용하기 때문에주의해서 사용해야합니다. LOC의 가장 인간적인 비참한 사용은 과거에 한 달에 작성된 LOC를 기반으로 개별 개발자의 생산성을 측정하려는 시도였습니다.

생산성 및 SLOC 정보

SLOC의 문제

SLOC 메트릭 의 문제점은 다음 을 고려하지 않고 작성된 코드 수량의 근사값을 측정한다는 것입니다.

• 코드의 품질 (즉, 100 SLOC마다 버그로 인해 90 개의 SLOC를 추가해야하지만 코드가 제공되는 시점을 모르는 경우 어떻게해야합니까?)
• 코드를 통해 달성 된 목표 (예 : 10K SLOC는 모든 예상 사용 사례 또는 사용자 사례를 처리합니까?
• 코드의 유지 관리 성 (예 : 예상되는 발전 요구 사항에 맞게 코드를 조정하려면 1 % 또는 50 % 더 많은 코드를 추가해야합니까?)

그렇지 않으면, 복사하여 붙여 넣은 부품이 많은 오류가 발생하기 어려운 스파게티 코드를 생성하면 신중하게 설계된 재사용 가능한 코드보다 생산적인 것으로 간주됩니다.

따라서 SLOC는 생산성을 측정하는 가장 좋은 방법은 아닙니다.

우리는 어떤 생산성을 고려하고 있습니까?

공정의 생산성을 측정합니다. 따라서 SLOC는 코딩 프로세스만으로도 완벽한 지표가 될 수 있습니다.

예를 들어, 열악한 요구 사항을 오해하고 소프트웨어를 제작하는 데 5 개월을 소비하고, 사용자에게 소프트웨어를 보여주고, 잘못되었다는 것을 발견하고, 처음부터 다시 작성하기 위해 다시 5 개월을 소비하는 경우 SLOC의 생산성은 동일합니다. / month, 예를 들어, 팀은 빈번한 피드백을 통해 오해를 줄이는 민첩한 프로세스를 사용했기 때문에 코드를 처음으로 바로 작성했습니다. 이 명백한 동등한 생산성은 큰 문제를 숨 깁니다.

따라서 소프트웨어 개발 생산성을 측정하려면 요구 사항 분석, 코딩 대상 설계, 코딩, 테스트, 디버깅 및 사용자 기대치 충족 여부 확인 등 전체 프로세스를 고려해야합니다. 이러한 모든 활동이 매우 다르기 때문에 가장 좋은 것은 작동하는 소프트웨어, 즉 소프트웨어가 생성 한 소프트웨어가 사용자에게 무엇을 의미하는지에 대한 유일한 생각을 측정하는 것입니다 .

소프트웨어 결과물을 측정하는 방법?

몇 가지 접근 방식이 있습니다.

• 고전적인 소프트웨어 엔지니어링의 일반적인 접근 방식은 기능 포인트 (FP)입니다. 기능 포인트는 충족 해야 할 요구 사항 (예 : 양식 수, 각 양식의 필드 수 등)을 기준으로 측정됩니다. 그런 다음 생산성을 단위 및 시간당 FP로 측정합니다. 일부 회사에는 개발자가 주어진 도메인에 대해 주어진 언어로 단위 시간당 몇 개의 기능 포인트를 생성 할 수 있는지를 알려주는 데이터가 있습니다. FP의 문제점은 매우 상세한 요구 사항이 필요하고 시간이 많이 걸린다는 것입니다.
• 보다 현대적이고 실용적인 접근 방식은 스토리 포인트 (SP)입니다. 이것들은 생성되는 코드의 복잡성을 평가하는 데 사용되며 개발 팀의 속도를 평가하는 데 일상적으로 사용됩니다. 그러나 SP는 모든 세부 사항이 알려지기 전에 수행 된 작업에 대한 추정 측정 값입니다. 실제로 일어난 일의 최종 척도가 아닙니다. 따라서 추정 과정에서 역효과를 일으킬 수 있으므로 생산성 측정으로 사용할 때는주의를 기울여야합니다 .

정적 및 동적 타이핑의 생산성 정보

나는 개인적으로 정적으로 유형이 지정된 언어를 좋아한다고 고백해야한다. 왜냐하면 내면의 자아에서는 그것이 더 신뢰할 수 있다는 것을 알고 있기 때문이다.

따라서 정식 유형 언어는 정적 유형이 아닌 언어보다 컴파일 타임에 오류 / 버그 (예 : 오타, 예상 유형의 불일치 등)를 훨씬 많이 방지 할 수 있습니다. 그러나 모든 객관성에서 나는 이것을 더 높은 생산성으로 학대 적으로 일반화하지는 않을 것입니다.

당신의 건축가가 맞습니까?

그럴 수도 있고 아닐 수도있다.

그러나 그의 주장은 타당하지 않은 것으로 보인다. 정적으로 형식화 된 언어의 생산성 향상은 컴파일러가 미리 잡은 많은 수의 오류에서 비롯된다.

따라서 동적으로 유형이 지정된 언어에 필요한 재 작업을 보지 않고 SLOC 만 살펴보면 이러한 "높은"생산성 이점을 찾을 수 없습니다. 그래서 그의 비교는 공평 할 수 없습니다.

비교할만한 상황에 대한 주장도 마찬가지입니다. 동적으로 유형이 지정된 일부 언어는 고전적인 정적으로 유형이 지정된 언어 중 하나에서 코드를 작성하는 것보다 코드가 덜 필요한 일부 상위 레벨 구성을 허용합니다. 따라서 더 적은 시간과 코드를 작성할 수 있지만 동일한 분석, 테스트 및 검증 오버 헤드를 추가 할 수 있습니다. 따라서 SLOC로 생산성을 측정하면 잠재적 인 생산성 향상 효과가 줄어들어 동적으로 입력되는 언어에 대한 편견이 생깁니다.

그 주장을 뒷받침하는 어떤 연구?

이 주제에 관한 몇 가지 최근의 학문 연구가 있습니다. 정적 타이핑의 이점이 있지만 일부는 일반적으로 특정 목적 (문서화, 문서화되지 않은 코드 또는 API 재사용 등)으로 제한됩니다. 최신 IDE가 동적 타이핑과 관련된 위험을 크게 줄 였기 때문에 신중한 문구도 사용됩니다.

• IDE가있는 경우 API 사용에 대한 정적 및 동적 유형 시스템의 경험적 비교 : Java vs. groovy with eclipse , 2014
• 2014 년 명시 적 유형 선언의 생산성 효과 고려
• 문서화되지 않은 소프트웨어의 유용성에 대한 정적 유형 시스템의 영향에 대한 실증적 연구

수석 설계자를위한 반례는 다음과 같습니다. 두 클래스가 세 번째 클래스에서 파생되어 기본 클래스가 정의하는 가상 함수를 구현하는 세 클래스의 계층 구조를 작성한다고 가정합니다.

이 세 클래스를 C ++로 작성하면 매우 간단합니다. 클래스를 선언하고 올바른 장소에서 가상을 사용하고 완료합니다.

이 세 클래스를 C로 작성하면, 약간의 코드를 추가해야합니다 : structv-tables 에 대해 s 를 정의 하고, 기본 클래스에 v-table 포인터를 추가해야합니다. 실제로 v 테이블 포인터를 설정하는 생성자에 대한 코드, 실제로 기본 클래스 생성자를 호출하는 생성자를 코드에 추가해야합니다. 생성자를 호출하기 전에 메모리 할당을 명시 적으로 수행하는 코드를 추가해야합니다 (C ++ new은 단일 단계에서 수행함) 마찬가지로, 나는 후속 free()호출과 같은 파괴 등을 분리해야 합니다.

요점은 이러한 모든 추가 사항은 생각이 거의 없다는 것입니다. 나는 그들을 매우 빨리 할 수 ​​있습니다. 따라서 C ++ 버전을 작성하는 것보다 C 버전을 작성하는 데 시간이 오래 걸리지 않습니다. 그럼에도 불구하고, 나는 C ++ 코드보다 더 많은 C 코드 라인을 생성했습니다. SLOC 측면에서 C에서 생산성이 더 높은 것으로 보입니다.

상용구 코드가 어느 정도 필요한 언어는 동일한 상용구 코드가 필요없는 언어보다 SLOC 측면에서 생산성이 높습니다.

SLOC- 인수는 근본적으로 결함이있어 실제로는 다른 방향으로 볼 수 있습니다. "프로그래머는 정적 언어로 더 많은 SLOC를 생성하는 경향이 있습니다"라는 의미를 갖습니다. "정적 언어는 더 많은 것을 요구하는 것으로 보입니다 상용구 코드를 사용하여 생산성을 줄입니다. "

나는 반대자가 될 것이다.

우리는 직장에서 SLoC를 추적하지만 (직원 결정에 직접 사용하지는 않지만) 사람들이 대부분의 사람들이 자신의 답변에서 말하는 것을 논쟁하게했습니다. 실제로 "LoC는 X 기술을 통해 적은 코드로 더 많은 것을 할 수 있기 때문에 중요하지 않습니다"또는 "더 나은 개발자는 더 나은 짧은 코드를 작성하므로 다른 사람보다 더 많이 쓰지 않습니다." 내 경험상 (이러한 것들을 뒷받침하기 어려운 숫자는 없지만) 이러한 반대 의견은 단순히 정확하지 않습니다. 필자는 엔지니어로서의 전체 "역량"에 대한 다른 모든 의미있는 측정과 비교할 때 개발자의 코드 생성 속도와 품질에서 분명한 상관 관계를 보았습니다. 위의 주장에 대해 반례를 제시하려면 다음을 수행하십시오.

1. 예, 일부 언어는 적은 코드로 더 많은 것을 할 수 있습니다. 실제로 특정 비즈니스 문제 (백엔드에만 해당)에 대해 개발의 많은 부분을 "자동화"하도록 구축 된 전체 프레임 워크가 있습니다. 이 모든 것의 결과는 사람들이 적은 코드를 작성하는 것이 아니라 단순히 코드를 작성할 시간이 더 있다는 것입니다. 결과적으로 우리 회사의 전체 코드 작성 속도는 기술마다 상당히 일정하며 주로 엔지니어의 역량 수준에 따라 다릅니다.
2. 더 나은 개발자가 더 똑똑하게 작성하기 때문에 더 적은 코드를 생성한다는 아이디어는 사실이 아닙니다. 더 나은 디자인의 프로그램은 더 적은 코드를 사용할 수 있습니다. 그러나 저는 개인적으로 더 효율적인 코드를 작성하는 "더 나은"개발자가 더 먼 저급 개발자가 작성하는 것보다 더 긴 시간을 계획하지 않는다는 것을 알게되었습니다. 결과적으로 상급 개발자는 코딩 작업을 더 빨리 수행하고 동일한 코드로 다른 코드를 작성합니다.

위도 부분은 전체 요약, BTW입니다. 내가 찾은 것은 기술 스택이나 프로젝트 종류에 관계없이 대부분의 개발자가 자신의 페이스를 가지고 있다는 것입니다. 언어에 개발자 코드를보다 효과적으로 만드는 많은 기능이 있다면 이는 비즈니스에 큰 도움이되지만 결과적으로 더 적은 코드를 작성한다는 의미는 아닙니다. 대신, 기능을 더 빨리 수행하고 새로운 코드로 빠르게 넘어갑니다. 다시 말하지만, 결과적으로 코딩 속도는 주로 기술에 의존하고 기술 스택에는 의존하지 않습니다. 사실, 이로 인해 일반적으로 기술 스택이 사람들이 코딩하는 속도보다 티켓과 기능이 개발되는 속도에 더 큰 차이를 만들 것으로 기대합니다.

즉, 코드 작성 속도 나 티켓 마감 속도는 생산성의 완벽한 척도이므로 SLoC를 기반으로 직원 결정을 직접 내리지 않습니다. 대신 프로세스의 일부이며 가능한 많은 데이터 포인트를 사용하여 직원 평가가 수행됩니다. 나는 당신의 건축가가 확실히 미친 것이 아니라고 말할 것입니다.

한 가지 예외

내가 동의하는 한 가지 예외는 보일러 플레이트 코드의 가능성입니다. 한 클래스 (또는 다른 클래스)에서 다른 클래스로 많은 복사 및 붙여 넣기 작업을 수행하여 클래스를 시작하고 실행하면 메트릭이 왜곡됩니다. 대량의 코드를 자동으로 생성 할 수있는 툴링이있는 경우에도 마찬가지입니다. 그러나 나는 이것이 규칙이 아니라 종종 예외라고 생각합니다. 개발자가 시작하기 위해 보일러 플레이트 코드를 복사하는 데 많은 시간을 소비하면 잘못된 기술 세트를 사용하는 것입니다. 실제로 코드를 작성하는 경우 상당히 반복적이지만 측정을 약간만 기울일 것으로 예상합니다. 코드를 작성할 때 대부분의 경우 문제를 얼마나 빨리 생각할 수 있는지에 의해 제한됩니다. 입력 할 수있는 속도보다 비교적 반복적 인 코드를 작성할 때도

분명히, 위의 모든 것은 내 자신의 개인적인 경험을 기반으로합니다. 귀하의 마일리지는 다를 수 있으며 분명히 소수입니다. 동의하지 않습니다. 요약하자면 :

코딩 속도는 문제를 겪고있는 다른 문제에 대해 얼마나 빨리 생각할 수 있는지에 달려 있습니다. 결과적으로, 코딩 속도는 기술 집합에 관계없이 몇 가지 예외를 제외하고는 생산성의 적절한 척도라는 것을 알았습니다.

나는 밴드 왜건에 뛰어 오르고 있지만. 프로그래머의 행동에 미치는 영향을 강조해야한다고 생각합니다.

생산적인 수단으로 SLOC를 사용하는 것은 프로그래머의 사기에 유독 한 영향을 미칩니다. 팀 / 회사의 엔지니어가 SLOC에서 측정 한 것을 인식하는 순간 몇 가지 일이 발생합니다.

1. 그들은 같은 기능을 수행하기 위해 훨씬 더 긴 코드를 작성하기 시작합니다.
2. 그들은 코드의 품질에 대해 덜 신경 쓸 것입니다
3. 팀에 도움이되는 다른 일 (채용, 디버깅, 후배 돕기)을 중단합니다.
4. 그들은 그들의 일을 미워하고 아마 떠날 것입니다

두 회사에서 두 번 발생하는 사기를 사기 때문에 사기를 유발하는 것이 얼마나 부식성이 있는지 강하게 강조 할 수 없습니다. 유효한 유스 케이스가 무엇이든간에, 그 사용이 발견 될 가능성이 적더라도 팀 / 회사에 영향을 줄 가치가 없을 것이라고 주장합니다. 경우에 따라 작성된 줄 수와 유용한 기능의 양 사이에 상관 관계가있을 수 있지만 프로그래머의 모든 잘못된 동작을 장려하고 품질이 중요하지 않다는 메시지를 보냅니다.

일반적으로 생산성을 측정하는 올바른 방법으로 간주되지 않습니다. 코드가 작을수록 큰 코드보다 낫기 때문에 생산성이 높은 개발자는 일반적으로 코드를 적게 생성합니다. 생산성은 디버깅에서 가장 큰 타격을받습니다. 효율적인 개발자는 디버깅에 거의 시간을 소비하지 않습니다.

정적으로 유형이 지정된 언어는 더 생산적입니다 (언어 간의 다른 모든 차이점을 제어하는 ​​경우). 현명하게 사용하면 디버깅 시간이 단축되고 컴파일 단계에서 오류가 더 빨리 해결되므로 디버깅 시간이 줄어 듭니다.

언어 간 개발자의 생산성을 비교하는 데 사용할 수있는 유일한 메트릭은 언어 간 코드를 비교하지 않는 메트릭입니다. 일부 언어는 악명 높고 (레거시 승리를위한 COBOL) 다른 언어는 한 줄의 코드에서 수행 할 수있는 작업을 수행하기 위해 몇 가지 단계가 필요합니다 (조립과 다른 모든 것). 활성 코드 줄만 비교하더라도 (즉, 선언을 계산하지 않고 관련된 작업이있는 코드 만 계산) 결과가 왜곡 될 수 있습니다.

변화율에 대해 논쟁을 할 수 있습니다. 즉, 동일한 기간 동안 생산성의 기울기를 비교하여 코드 라인이 추가되었습니다. 그러나 이것이 코드 라인의 부정적인 변화를 설명하지는 않습니다. 예를 들어, 어디에서나 복사 및 붙여 넣기 코드가있는 프로젝트를 상속합니다. 반복되는 코드 블록 수를 줄이기 위해 빠르고 쉬운 리팩토링을 수행합니다. 정의에 따라 음의 기울기가 있습니다.

진지하게, 팀 / 언어의 생산성을 비교하는 것은 의미가 없습니다. 팀의 생산성에 영향을 미치는 추가 요인이 너무 많기 때문에 의미있는 결론을 내릴 수 없습니다.

인프라가 매우 취약하고 도구가 구식 인 프로젝트를 진행했습니다. 이 프로젝트는 단일 페이지 앱으로 Java에 빌드되었지만 포틀릿 컨테이너에 호스팅되어 별다른 이점이 없습니다. 간단한 변경조차도 시간이 엄청나게 길었습니다. 해당 특정 프로젝트에 대한 모든 결론을 내리려면 Java가 잘못되었거나 단일 페이지 앱이 잘못되었다고 결론을 내릴 수 있습니다. 둘 다 사실이 아닙니다. 못생긴 프로젝트를 대체해야하는 시스템은 C # 및 WebForms를 기반으로 구축되었습니다. 고객의 요구를 처리하기 위해 기존 애플리케이션을 확장하기 위해 비즈니스 사례를 만들었을 때 생산성이 급상승했습니다. 이는 밀접하게 결합 된 WebForms 앱이 우수하다는 것을 의미합니까? 이 특정한 경우에 대해서만 결론을 내릴 수 있습니다그리고 그것은 전 세계로 확대되지 않습니다. 그리고 그것은 단지 확장 할 수있는 충분한 만기가 기존 응용 프로그램이 있었기 때문에 의미가 있습니다.

전체 프로젝트 인프라를 서로 비교한다는 점에서 이슈 추적 시스템에서 해결 항목의 비율을 비교하더라도 결함이 있습니다. 사용 된 라이브러리 및 프레임 워크는 진행 속도를 높이거나 늦출 수 있습니다. "보다 더 나은"프로젝트가 새로운 티켓의 수가 비교적 적은 유지 보수 단계에있는 경우 극복 할 관성이 거의없는 시작 단계에있을 수 있습니다. 결코 같은 것을 비교하는 경우가 아닙니다.