Quantas linhas de código um desenvolvedor de C # pode produzir por mês? [fechadas]

Um executivo no meu local de trabalho fez a mim e ao meu grupo de desenvolvedores a pergunta:

Quantas linhas de código um desenvolvedor de C # pode produzir por mês?

Um sistema antigo deveria ser portado para C # e ele gostaria dessa medida como parte do planejamento do projeto.

De alguma fonte (aparentemente creditável), ele teve a resposta de "10 SLOC / mês ", mas não ficou satisfeito com isso.

O grupo concordou que isso era quase impossível de especificar, porque dependeria de uma longa lista de circunstâncias. Mas poderíamos dizer que o homem não iria embora (ou ficaria muito desapontado conosco) se não tivéssemos uma resposta adequada para ele. Então ele saiu com a resposta muitas vezes melhor de "10 SLOC / dia "

Esta pergunta pode ser respondida? (improvisado ou mesmo com algumas análises)

Pergunte ao seu executivo quantas páginas de contrato o advogado dele pode escrever por mês. Então (esperançosamente) ele perceberá que há uma enorme diferença entre escrever um contrato de página única e escrever um contrato de 300 páginas sem brechas e contradições. Ou entre escrever um novo contrato e alterar um existente. Ou entre escrever um novo contrato e traduzi-lo para um idioma diferente. Ou para um sistema jurídico diferente. Talvez ele até concorde que "páginas de contrato por unidade de tempo" não é uma medida muito boa para a produtividade dos advogados.

Mas, para lhe dar uma resposta à sua verdadeira pergunta: Na minha experiência, para um novo projeto, algumas centenas de SLOC por dia e desenvolvedor não são incomuns. Mas assim que os primeiros erros aparecerem, esse número cairá acentuadamente.

Quantas linhas de código um desenvolvedor de C # pode produzir por mês?

Se eles são bons, menos que zero.

Corra para o outro lado ... Agora.

LoC é uma das piores métricas que você pode usar.

Desenvolvedores ruins podem escrever mais LoC por dia do que bons desenvolvedores, mas produzem código de lixo.

Dependendo da complexidade do código, a portabilidade pode ser feita por processos de automação que resultariam em milhares de alterações de + LoC por dia, enquanto que seções mais difíceis, nas quais as construções de linguagem são muito diferentes, podem ser portadas nos 100LoC por dia.

Envie-o para ler a página da Wikipedia no SLOC . Se fornece alguns exemplos simples e agradáveis ​​de por que essa é uma métrica tão ruim.

A resposta certa: Não ...

Esse executivo deve ser informado de que o SLOC não é uma métrica válida para o progresso da análise

The Sloppy Answer: Qualquer número que você possa inventar.

Basta dar a ele algum número, você e sua equipe podem facilmente criar esse número de qualquer maneira. (Colocando a menos que a linha, linhas vazias, comentários, etc, etc, apenas para permitir que esse cara continue vivendo em seu mundo de fantasia, assombrar mais uma equipe e continuar o ciclo reforçado de miséria que faz uma história para todos os dias.

Não é legal, mas é capaz.

À primeira vista, essa pergunta parece absolutamente estúpida, e todos aqui responderam apenas à parte estúpida de C # LoC. Mas há uma nuance importante - é uma pergunta sobre uma performance de portabilidade . A maneira correta de fazer essa pergunta é: quantas linhas de código do projeto de origem (a que está sendo portada) um desenvolvedor pode manipular dentro de uma determinada unidade de tempo. É uma pergunta perfeitamente justificada, pois o número total de linhas de código é conhecido e é exatamente a quantidade de trabalho a ser realizado. E a maneira certa de responder a essa pergunta é coletar um pouco de dados históricos - trabalhe por, digamos, uma semana e avalie o desempenho de cada um dos desenvolvedores.

Eu só tenho uma coisa a dizer:

"Medir o progresso da programação por linhas de código é como medir o progresso da construção de aeronaves em peso".

- Bill Gates

Depois disso, você pode argumentar que Bill Gates não sabia como criar software de sucesso;)

Nota: O SLOC é uma medida muito boa da complexidade da base de código!

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

Proporcional ao número de palavras, de fato.

Você entende o meu ponto?

Eu posso ter uma posição um pouco diferente sobre isso, mas acho que posso entender por que o executivo estava procurando essas informações se atualmente está fazendo o planejamento do projeto. Como é difícil estimar quanto tempo um projeto levará, um dos métodos usados ​​(consulte: Estimativa de software: Desmistificando a arte negra ) é estimar quanto tempo levará o projeto com base no número de SLOCs em projetos similares e agora os desenvolvedores podem produzir em média. Na prática, isso deve ser feito usando registros históricos que o grupo tem em mãos para projetos semelhantes com o mesmo desenvolvedor ou com desenvolvedores semelhantes.

No entanto, não vale nada que essas estimativas se destinem apenas ao planejamento básico do projeto e não se destinem a definir o ritmo dos desenvolvedores no projeto, porque as coisas mudam dia após dia. Portanto, a maioria do que você lê sobre o uso de SLOCs como ferramenta de estimativa é que eles são bons a longo prazo, se você já possui um bom corpo de conhecimento, mas péssimo para o uso no dia a dia.

Geralmente, é uma má idéia chamar seu chefe de idiota; portanto, minhas sugestões começam com a compreensão e discussão de métricas, em vez de rejeitá-las.

Algumas pessoas que não são realmente consideradas idiotas usaram métricas baseadas em linhas de código. Fred Brooks, Barry Boehm, Alcaparras Jones, Watts Humphries, Michael Fagan e Steve McConnell todos os usaram. Você provavelmente os usou mesmo que apenas para dizer a um colega, este módulo de Deus é de 4000 linhas, ele precisa ser dividido em classes menores.

Existem dados específicos relacionados a esta questão de uma fonte que muitos de nós respeitam.

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

Eu suspeito que o melhor uso da linha de código por hora do programador é mostrar que, ao longo da vida do projeto, esse valor começará bastante alto, mas à medida que os defeitos são encontrados e corrigidos, novas linhas de código serão adicionadas para resolver problemas que não fizeram parte das estimativas originais e as linhas de código removidas para eliminar duplicação e melhorar a eficiência mostrarão que LOC / hr indica outras coisas além da produtividade.

• Quando o código é escrito rápido, desleixado, inchado e sem nenhuma tentativa de refatoração, a eficiência aparente será máxima. A moral aqui será que você deve tomar cuidado com o que mede.
• Para um desenvolvedor em particular, se estiver adicionando ou tocando em uma grande quantidade de código nesta semana, na próxima semana poderá haver uma dívida técnica a ser paga em termos de revisão, teste, depuração e retrabalho do código.
• Alguns desenvolvedores trabalharão a uma taxa de saída mais consistente do que outros. Pode-se constatar que eles gastam mais tempo obtendo boas histórias de usuários, revertendo-se muito rapidamente e fazendo testes de unidade correspondentes e, em seguida, reviram e rapidamente criam código focado apenas nas histórias de usuários. A conclusão aqui é que os desenvolvedores metódicos provavelmente terão uma mudança rápida, escreverão um código compacto e terão um baixo retrabalho porque entenderão muito bem o problema e a solução antes de começarem a codificar. Parece razoável que eles codifiquem menos porque codificam somente depois de refletir, em vez de antes e depois.
• Quando o código é avaliado quanto à sua densidade de defeitos, ele se mostra menos do que uniforme. Algum código será responsável pela maioria dos problemas e defeitos. Será um candidato para reescrever. Quando isso acontece, ele se tornará o código mais caro, devido ao alto grau de retrabalho. Ele terá as maiores linhas brutas de contagem de códigos (adicionadas, excluídas, modificadas, como pode ser relatado por uma ferramenta como CVS ou SVN), mas as menores linhas líquidas de código por hora investidas. Isso pode acabar sendo uma combinação do código, implementando o problema mais complexo ou a solução mais complicada.

Independentemente do resultado do debate sobre a produtividade do programador em linhas de código, você descobrirá que precisa de mais mão-de-obra do que pode e o sistema nunca será concluído a tempo. Suas ferramentas reais não são métricas. São o uso de metodologia superior, os melhores desenvolvedores que você pode contratar ou treinar e o controle de escopo e risco (provavelmente com métodos Agile).

Dê a ele uma métrica melhor para trabalhar com

Em vez de LOC , explique que essa é a pior métrica a ser usada. Então dê a ele uma alternativa:

Nº de funções / recursos por solicitação de recurso / função -> NOFF / RFF

Pode ser necessário adicionar uma ponderação / normalização sobre o NOFF / RFF, para atender às quantidades de solicitações por semana.

:) claramente o acima é composto, mas qualquer coisa, é melhor que SLOC ...

Posso dizer que uma carga de empreiteiros para um grande projeto escreveu 15000 LOC (cada) em um ano. Essa é uma resposta incrivelmente grosseira, mas foi útil para nós, pois temos 400.000 LoC C ++ existentes e pudemos descobrir que converter tudo em C # levaria cerca de 26 anos-homem para ser concluído. Dar ou pegar.

Portanto, agora que sabemos a ordem aproximada de magnitude, podemos planejar melhor para isso - obter 20 desenvolvedores e estimar o trabalho de um ano para todos eles seria correto. Antes de contar, não tínhamos idéia de quanto tempo levaria para migrar.

Portanto, meu conselho para você é fazer o check-out de todo o código que você escreveu em um período específico de tempo (tive a sorte de ter um projeto novo para trabalhar) e executar uma das muitas ferramentas de métrica de código nele. Divida o número pelo tempo e você poderá dar uma resposta precisa - quanto LOC você escreve por dia. Para nós, saiu a 90 LOC por dia! Acho que tivemos muitas reuniões e documentação sobre esse projeto, mas acho que também teremos muitas reuniões e documentação no próximo :)

Parece correto.

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

Se você levar em consideração a depuração, a documentação, o planejamento etc. A média é de 10 linhas de código por dia. Na verdade, eu classificaria 10 linhas por dia no lado alto (ou seja, um desenvolvedor muito produtivo).

Mesmo que você possa produzir algumas centenas de linhas em um único dia (isso não é sustentável). Não é um código de qualidade até que você tenha adicionado toda a documentação do teste de unidade e, é claro, depurado o código após o teste de unidade mostrar os erros. Depois de tudo isso, você volta ao 10.

Meu palpite é que um desenvolvedor que trabalha com uma linguagem como C # deve ser capaz de escrever / gerar cerca de 10K LoCs / dia. Suponho que eu poderia fazer isso. Eu nunca faria isso.

O que você quer de um desenvolvedor é realizar seu trabalho em 10 LoCs / dia. Menos código é sempre melhor. Costumo começar produzindo uma grande quantidade de código e depois cortando até atingir o máximo de simplicidade; portanto, tenho dias com LoCs negativos.

Em certo sentido, a codificação é como poesia. A questão não é: quantas linhas um poeta pode escrever, mas quanto ele pode transmitir nas 14 linhas de um soneto.

Deixe seu gerente lidar com isso ou comece a procurar emprego.

Com toda a seriedade, você pode gastar o que pode acabar sendo um esforço sem esperança, explicando ao executivo os métodos adequados e impróprios de medir o progresso de um projeto até a conclusão. Em toda a realidade, porém, para que servem os gerentes de engenharia e projetos.

Por outro lado, as circunstâncias são tais que o executivo em questão É seu gerente de engenharia e / ou projeto. Você tem problemas muito maiores e mais básicos para lidar, mesmo que eles ainda não tenham se revelado. Nesse caso, um problema como esse pode servir como um "alerta" para futuros problemas maiores.

Outras respostas estão corretas, é uma pergunta idiota e a resposta não significa nada. É tudo verdade, mas por acaso sei quantas linhas de código produzi em aproximadamente um mês.

São cerca de 3000 linhas de código C # sem XML-doc. Eu estava implementando novas funcionalidades e acabei com esse valor em um mês ou um mês e uma semana. Foi tudo o que acabou no controle de origem, muito código foi escrito e depois refatorado ou excluído.

Sou desenvolvedor de C # e estou tentando ser bom nisso, mas não posso dizer o quanto sou objetivamente bom. Tentei escrever um bom código e fiz um grande esforço para facilitar a manutenção. Eu só coloquei comentários uma ou duas vezes neste código.

Não sei se são muitas ou poucas linhas de código e devo dizer que realmente não me importo. É um dado sem sentido e não pode ser usado com segurança para extrapolação de forma alguma. Mas por acaso conheci esses dados, então decidi compartilhar.

Bem, estou um pouco atrasado para esta festa, como sempre, mas isso é realmente interessante. Inicialmente, tive o mesmo pensamento de que a pergunta do executivo é tola. No entanto, li a resposta da SK-logic e percebi que é uma pergunta sensata feita de uma maneira sem sentido. Ou, em outras palavras, há um problema válido por trás da pergunta.

Os gerentes geralmente precisam tentar determinar a viabilidade, financiamento, pessoal etc. para um projeto. Este é um problema sensato. Para uma porta straightford, uma estimativa baseada em linhas de código de porta dividida pela média estimada de linhas de código por desenvolvedor por dia é atraente em simplicidade, mas fadada ao fracasso por todos os motivos apresentados nesta página.

Uma abordagem mais sensata seria:

1. Para obter uma estimativa no local, pergunte aos desenvolvedores com mais experiência com o código uma estimativa de quanto tempo levará. Isso deve estar incorreto por muitos motivos que não abordarei aqui, mas é o melhor que eles poderão fazer desde o início. Pelo menos eles devem ter uma idéia de se será fácil em uma semana ou anos, mesmo com recursos adicionais. Se houver portas ou peças de tamanho semelhante, elas podem ser usadas como um guia.
2. Estime a porta por componente para obter um dimensionamento total. As tarefas que não estão diretamente relacionadas à porta precisam ser incluídas, como a configuração de infraestrutura (máquinas, sistemas de construção, etc.), investigação e compra de software etc.
3. Identifique os componentes mais arriscados da porta e comece pelos primeiros. É provável que isso exploda ao máximo a estimativa; portanto, isso deve ser feito antecipadamente, se possível, para que haja surpresas limitadas no final do porto.
4. Acompanhe o progresso em relação ao dimensionamento feito na etapa 2 para calcular continuamente a duração esperada da porta. À medida que o projeto avança, isso deve se tornar mais preciso. Obviamente, o número de linhas de código que foram portadas (recursos na base de códigos original que agora estão no código portado) também pode ser usado como uma métrica e é realmente útil para garantir que o produto original esteja sendo portado em vez de um monte de novas funcionalidades bacanas sendo adicionadas sem atacar a porta real.

Essas seriam as etapas básicas, é claro que existem muitas outras atividades úteis como investigar ferramentas de portabilidade e estruturas conectáveis, criar protótipos, determinar o que realmente precisa ser portado, reutilizar ferramentas e infraestrutura de teste etc.