직장의 한 임원이 나와 개발자 그룹에게 다음과 같은 질문을했습니다.
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.실제로 단어 수에 비례합니다.
내 요점이 보이나요?