C # 개발자가 한 달에 몇 줄의 코드를 생성 할 수 있습니까? [닫은]

직장의 한 임원이 나와 개발자 그룹에게 다음과 같은 질문을했습니다.

C # 개발자가 한 달에 몇 줄의 코드를 생성 할 수 있습니까?

오래된 시스템을 C #으로 이식해야했으며 프로젝트 계획의 일부로이 측정을 원합니다.

일부 (명백히 신용할만한) 출처에서 그는 "10 SLOC / 월 " 의 답을 얻었지만 그 점에 만족하지 않았습니다.

그룹은 긴 환경 목록에 의존하기 때문에이를 지정하는 것이 거의 불가능하다는 데 동의했다. 그러나 우리는 그에게 더 잘 맞는 대답을 얻지 못하면 그 사람이 떠나지 않을 것이라고 말할 수있었습니다. 그래서 그는 "10 SLOC / day " 라는 여러 번 더 나은 답변을 남겼습니다.

이 질문에 대답 할 수 있습니까? (손으로 또는 일부 분석으로)

담당 변호사에게 한 달에 변호사가 쓸 수있는 계약 페이지 수를 문의하십시오. 그런 다음 단일 페이지 계약을 작성하는 것과 허점 및 모순없이 300 페이지 계약을 작성하는 것 사이에는 큰 차이가 있음을 알고 있습니다. 또는 새로운 계약서 작성과 기존 계약서 변경 사이. 또는 새로운 계약서를 작성하고 다른 언어로 번역하는 것 사이. 또는 다른 법률 시스템으로. 어쩌면 그는 "단위 시간당 계약 페이지"가 ​​변호사 생산성에있어 매우 좋은 척도가 아니라는 데 동의 할 것입니다.

그러나 당신에게주는 몇 가지 실제 질문에 대한 답을 내 경험에 의하면, 일 및 개발자 당 몇 백 SLOC가 드물지 않다 새로운 프로젝트. 그러나 첫 번째 버그가 나타나면이 숫자가 급격히 떨어집니다.

C # 개발자가 한 달에 몇 줄의 코드를 생성 할 수 있습니까?

좋은 경우 0보다 작습니다.

다른 방법으로 실행하십시오 ... 지금.

LoC는 사용할 수있는 최악의 메트릭 중 하나입니다.

나쁜 개발자는 좋은 개발자보다 하루에 더 많은 LoC를 작성할 수는 있지만 쓰레기 코드를 생성 할 수 있습니다.

코드의 복잡성에 따라 포팅은 자동화 프로세스에 의해 수행 될 수 있으며, 하루에 수천 개 이상의 LoC 변경이 발생하는 반면, 언어 구성이 서로 다른 코드가 더 어려운 섹션은 하루 100LoC에 포팅됩니다.

SLOC 의 Wikipedia 페이지를 보도록 보내십시오 . 그렇다면 왜 이것이 좋지 않은 메트릭인지에 대한 훌륭하고 간단한 예를 제공합니다.

정답 : 아니요 ...

이 임원은 SLOC가 분석 진행에 대한 유효한 지표가 아님을 교육해야합니다.

너절한 답변 : 당신이 구성 할 수있는 숫자.

그에게 번호를 알려 주면 당신과 당신의 팀은 어쨌든 쉽게 그 번호를 만들 수 있습니다. (라인, 빈 줄, 주석 등을 제외 하고는이 사람이 환상의 세계에 계속 살도록하고 또 다른 팀을 괴롭 히고 불행한 사이클을 계속하여 Dailywtf에 이야기를 만듭니다.

좋지는 않지만 가능합니다.

언뜻보기 에이 질문은 절대적으로 어리석은 것처럼 보이며 여기의 모든 사람들은 바보 같은 C # LoC 부분에만 대답했습니다. 그러나 중요한 뉘앙스가 있습니다. 포팅 성능 에 관한 질문 입니다. 이 질문을하는 올바른 방법은 개발자가 주어진 시간 단위 내에서 처리 할 수있는 소스 프로젝트 (포팅되는 코드)의 라인 수를 묻는 것입니다. 총 코드 줄 수를 알고 있기 때문에 완벽하게 정당화 된 질문이며 정확히 수행해야 할 작업량입니다. 그리고이 질문에 대답하는 올바른 방법은 일주일 동안 작업하고 각 개발자의 성과를 측정하는 약간의 기록 데이터를 수집하는 것입니다.

할 말이 하나 밖에 없습니다 :

"코드 라인별로 프로그래밍 진행 상황을 측정하는 것은 무게로 항공기 건물 진행 상황을 측정하는 것과 같습니다."

-- 빌 게이츠

그 후 Bill Gates가 성공적인 소프트웨어를 만드는 방법을 모른다고 주장 할 수 있습니다.)

참고 : SLOC는 코드 기반 복잡성을 매우 잘 측정합니다!

I 
can
write
large
numbers
of
lines
of
code
per
month.

실제로 단어 수에 비례합니다.

내 요점이 보이나요?

나는 이것에 대해 약간 다른 입장을 가질 수 있지만, 현재 프로젝트 계획을 수행하는 중역이 왜이 정보를 찾고 있었는지 이해할 수있을 것입니다. 프로젝트 소요 시간을 추정하기가 어렵 기 때문에 사용되는 방법 중 하나 ( 소프트웨어 추정 : 블랙 아트 미확인 )는 프로젝트 수에 따라 프로젝트 소요 시간을 추정하는 것입니다. 유사한 프로젝트의 SLOC 및 현재 개발자는 평균적으로 생산할 수 있습니다. 실제로 이것은 동일하거나 유사한 개발자와 유사한 프로젝트를 위해 그룹이 보유한 기록을 사용하여 수행됩니다.

그러나 이러한 추정치가 기본 프로젝트 계획만을위한 것이며 실제 상황이 매일 바뀌기 때문에 프로젝트에서 개발자의 속도를 설정하려는 것은 아닙니다. 따라서 SLOC를 추정 도구로 사용하는 것에 대해 읽은 내용의 대부분은 이미 지식이 풍부하지만 일상적으로 사용하기에는 장기적으로는 훌륭하다는 것입니다.

일반적으로 상사를 바보라고 부르는 것은 좋지 않습니다. 따라서 제 제안은 메트릭을 거부하기보다는 이해하고 논의하는 것으로 시작합니다.

실제로 바보로 간주되지 않는 일부 사람들은 코드 라인을 기반으로 한 메트릭을 사용했습니다. Fred Brooks, Barry Boehm, Capers Jones, Watts Humphries, Michael Fagan 및 Steve McConnell이 모두 사용했습니다. 당신은 아마도 동료에게 말하기를 원하더라도,이 신 모듈은 4000 줄이므로 더 작은 클래스로 나누어야합니다.

우리 중 많은 사람들이 존중하는 출처에서이 질문과 관련된 특정 데이터가 있습니다.

http://www.codinghorror.com/blog/2006/07/diseconomies-of-scale-and-lines-of-code.html

http://www.codinghorror.com/blog/2005/08/are-all-programming-languages-the-same.html

http://discuss.joelonsoftware.com/default.asp?joel.3.286106.22

프로그래머 시간당 코드 라인을 가장 잘 사용하는 것은 프로젝트 수명 동안이 값이 상당히 높아지지만 결함이 발견되고 수정됨에 따라 새로운 코드 라인이 추가되어 문제를 해결한다는 것을 보여주는 것입니다. 원래 추정치의 일부가 아니었고 중복을 제거하고 효율성을 개선하기 위해 제거 된 코드 줄은 LOC / hr이 생산성 이외의 것을 나타냅니다.

• 코드가 빠르고 느슨하고 부풀어지고 리팩토링을 시도하지 않으면 겉보기 효율성이 최고가됩니다. 여기서 도덕은 당신이 측정하는 것에주의해야한다는 것입니다.
• 특정 개발자의 경우 이번 주에 많은 양의 코드를 추가하거나 건 드리면 다음 주에 코드 검토, 테스트, 디버그 및 재 작업과 관련하여 지불해야 할 기술적 부채가있을 수 있습니다.
• 일부 개발자는 다른 개발자보다 일관된 출력 속도로 작업합니다. 좋은 사용자 스토리를 얻는 데 가장 많은 시간을 소비하고, 매우 빠르게 돌아 서서 해당 단위 테스트를 수행 한 다음, 사용자 스토리에만 초점을 맞춘 코드를 빠르게 둘러보고 작성합니다. 여기서 취지는 방법 론적 개발자는 아마도 빠르게 돌아 서고, 콤팩트 한 코드를 작성하며, 코딩을 시작하기 전에 문제와 솔루션을 잘 이해하기 때문에 재 작업이 적다는 것입니다. 이전과 이후가 아니라 생각한 후에 만 ​​코드를 작성하므로 코드를 적게 작성하는 것이 합리적입니다.
• 결함 밀도에 대해 코드를 평가하면 균일하지 않은 것으로 확인됩니다. 일부 코드는 대부분의 문제와 결함을 설명합니다. 재 작성 후보가 될 것입니다. 그렇게되면 높은 수준의 재 작업으로 인해 가장 비싼 코드가됩니다. CVS 또는 SVN과 같은 도구에서보고되는 것처럼 추가, 삭제, 수정 된 총 코드 줄 수가 가장 많지만 시간당 가장 낮은 코드 줄이 투자됩니다. 이것은 가장 복잡한 문제를 구현하거나 가장 복잡한 솔루션을 구현하는 코드의 조합 일 수 있습니다.

코드 라인에서 프로그래머 생산성에 대한 논쟁이 어떻게 진행되는지에 관계없이, 당신이 감당할 수있는 것보다 더 많은 인력이 필요하며 시스템은 제 시간에 완료되지 않을 것입니다. 실제 도구는 메트릭스가 아닙니다. 그들은 우수한 방법론, 고용 또는 훈련 할 수있는 최고의 개발자, 범위 및 위험 제어 (아마 일 방법으로)를 사용합니다.

더 나은 측정 항목을 제공하세요

대신 LOC , 이것이 설명 사용 최악의 메트릭. 그런 다음 그에게 대안을 제공하십시오.

기능의 번호 / 특징 별 > - 특징 / 기능 요청 NOFF / RFF

주당 요청 수를 충족시키기 위해 NOFF / RFF 위에 가중치 / 정규화를 추가해야 할 수도 있습니다.

:) 분명히 위의 내용이 구성되었지만 SLOC보다 낫습니다 ...

대규모 프로젝트를위한 많은 계약자가 1 년에 15000 LOC (각각)를 작성했다고 말할 수 있습니다. 그것은 엄청나게 거친 대답이지만, 우리가 40 만 개의 기존 C ++ LoC를 가지고 있기 때문에 우리에게 유용했고 우리는 그것을 모두 C #으로 변환하면 완료하는 데 약 26 년이 걸린다는 것을 알 수있었습니다. 주고받습니다.

이제 우리는 대략적인 규모를 알았으므로 더 나은 계획을 세울 수 있습니다 .20 명의 개발자를 확보하고 1 년 동안의 작업을 추정하는 것은 모두 옳을 것입니다. 계산하기 전에 마이그레이션하는 데 시간이 얼마나 걸릴지 알 수 없었습니다.

그래서 당신을위한 조언은 특정 시간에 작성한 모든 코드를 체크 아웃하고 (행운이 좋은 프로젝트가 있었기 때문에 운이 좋았습니다) 많은 코드 메트릭 도구 중 하나를 실행하는 것입니다. 숫자를 시간으로 나누면 하루에 실제로 쓰는 LOC의 양에 대한 정확한 답을 줄 수 있습니다 . 우리에게는 하루에 90 LOC가 나왔습니다! 그 프로젝트에 대해 많은 회의와 문서가 있었지만 다음 회의에도 많은 회의와 문서가 있다고 생각합니다. :)

올바른 소리.

/programming/966800/mythical-man-month-10-lines-per-developer-day-how-close-on-large-projects

디버깅, 문서화, 계획 등을 고려하면 하루 평균 약 10 줄의 코드가 작성됩니다. 실제로 나는 높은 편에서 하루에 10 줄을 평가할 것이다 (즉, 매우 생산적인 개발자).

하루에 몇 백 줄을 만들 수 있지만 (이것은 지속 가능하지 않습니다). 모든 단위 테스트 문서를 추가하고 단위 테스트 후 오류를 표시 한 후 코드를 디버깅 할 때까지 품질 코드가 아닙니다. 모든 것이 끝나면 10으로 돌아갑니다.

내 생각에 C #과 같은 언어로 작업하는 개발자는 하루에 약 10K LoC를 작성 / 생성 할 수 있어야합니다. 나는 그렇게 할 수 있다고 생각합니다. 난 절대 안할거야

개발자가 원하는 것은 하루 10 LoC로 작업을 수행하는 것입니다. 코드가 적을수록 좋습니다. 나는 종종 대량의 코드를 생산하기 시작한 다음 최대의 단순성에 도달 할 때까지 자르기 시작합니다. 따라서 실제로 음의 LoC가있는 날이 있습니다.

어떤 의미에서 코딩은시와 같습니다. 문제는 시인이 몇 줄을 쓸 수 있는가가 아니라 소네트의 14 줄에 얼마나 많은 양을 전달할 수 있는지입니다.

관리자가 처리하게하거나 구직을 시작하십시오.

진지하게, 프로젝트 진행을 측정하는 올 바르고 부적절한 방법을 경영진에게 설명하는 데 희망이없는 노력을 기울일 수 있습니다. 그러나 실제로는 엔지니어링 및 프로젝트 관리자가 무엇을 원하는가.

반면에, 상황은 임원 -에 - 질문하도록되어 IS 엔지니어링 및 / 또는 프로젝트 매니저. 아직 밝혀지지 않은 경우에도 처리해야 할 훨씬 더 크고 기본적인 문제가 있습니다. 이 경우 이와 같은 문제는 더 큰 문제가 발생할 경우 "경고"로 작용할 수 있습니다.

다른 대답은 맞습니다. 그것은 멍청한 질문이며 그 대답은 망할 것을 의미하지 않습니다. 모두 사실이지만 대략 한 달에 몇 줄의 코드를 만들 었는지 알 수 있습니다.

XML-doc없이 약 3000 줄의 C # 코드입니다. 나는 새로운 기능을 구현하고 있었고 한 달 또는 한 달에 일주일 에이 금액으로 끝났습니다. 소스 제어로 끝나는 모든 것, 많은 코드가 작성된 다음 리팩토링되거나 삭제되었습니다.

저는 C # 개발자이고 잘하려고 노력하고 있지만 객관적으로 내가 얼마나 좋은지 말할 수 없습니다. 좋은 코드를 작성하고 유지 관리하기 쉽도록 많은 노력을 기울였습니다. 이 코드에는 한두 번만 주석을 달았습니다.

코드 줄이 너무 많거나 적다는 것을 알지 못하며 실제로 신경 쓰지 않는다고 말해야합니다. 의미가없는 데이터이므로 어떤 식 으로든 외삽에 안전하게 사용할 수 없습니다. 그러나 나는이 데이터를 알게되어 공유하기로 결정했습니다.

글쎄, 나는 평소와 같이이 파티에 약간 늦었지만 실제로 이것은 재미있는 것입니다. 나는 처음에는 경영진의 질문이 멍청하다는 생각과 거의 동일했다. 그러나 나는 SK-logic의 답변을 읽고 그것이 무의미한 방식으로 묻는 합리적인 질문이라는 것을 깨달았습니다. 또는 다르게 말하면, 질문 뒤에 유효한 문제가 있습니다.

관리자는 종종 프로젝트의 타당성, 자금 조달, 인력 등을 결정하려고 노력해야합니다. 이것은 현명한 문제입니다. 스트레이트 포드 포트의 경우 포트 개발자 코드를 기준으로 일일 개발자 당 예상 평균 코드 라인으로 나눈 추정치는 단순하지만 매력적이지만이 페이지에 제공된 모든 이유로 실패하지는 않습니다.

보다 합리적인 접근 방식은 다음과 같습니다.-

1. 현장 평가의 경우 코드에 대한 경험이 가장 많은 개발자에게 시간이 얼마나 걸리는지 대략적으로 추정하십시오. 여기에 가지 않을 여러 가지 이유로 잘못 될 수 있지만 처음부터 그들이 할 수있는 것이 가장 좋습니다. 최소한 추가 리소스를 사용해도 일주일 또는 몇 년 안에 쉽게 해결할 수 있을지에 대한 아이디어가 있어야합니다. 비슷한 크기의 포트 또는 작업이 수행 된 경우이를 가이드로 사용할 수 있습니다.
2. 구성 요소별로 포트를 추정하여 전체 크기를 얻으십시오. 인프라 (기계, 빌드 시스템 등) 설정, 소프트웨어 조사 및 구매 등과 같이 포트와 직접 관련이없는 작업이 포함되어야합니다.
3. 가장 위험한 포트 구성 요소를 식별하고 먼저 시작하십시오. 이것들은 추정치를 가장 많이 날려 버릴 가능성이 있기 때문에 가능한 늦은 선착순으로 항구에서 늦게 놀라운 일이 발생하도록해야합니다.
4. 포트의 예상 지속 시간을 지속적으로 계산하려면 2 단계에서 수행 한 사이징을 기준으로 진행 상황을 추적하십시오. 프로젝트가 진행됨에 따라 더욱 정확 해져야합니다. 물론, 포팅 된 코드 줄 수 (현재 포팅 된 코드에있는 원래 코드베이스의 기능)도 메트릭으로 사용할 수 있으며 실제로 원래 제품이 아닌 포팅되고 있는지 확인하는 데 도움이됩니다. 실제 포트를 처리하지 않으면 서 멋진 새 기능이 추가됩니다.

포팅 툴 및 플러그 가능 프레임 워크 조사, 프로토 타입 생성, 포팅해야 할 사항 결정, 테스트 툴 및 인프라 재사용 등과 같이 도움이되는 다른 활동이 많이 있습니다.