Mítico homem mês 10 linhas por dia do desenvolvedor - qual a distância em grandes projetos? [fechadas]

Todo mundo sempre diz que pode vencer as "10 linhas por desenvolvedor por dia" a partir do "Mythical Man Month" e, iniciando um projeto, geralmente consigo algumas centenas de linhas por dia.

Mas no meu empregador anterior, todos os desenvolvedores eram muito afiados, mas era um projeto grande, com mais de um milhão de linhas de código, com requisitos de certificação muito onerosos e com interface com outros projetos de vários milhões de linhas. Em algum momento, como um exercício de curiosidade, plotei linhas de código no produto de remessa do meu grupo (sem contar as ferramentas que desenvolvemos), e com certeza, de forma incremental, chegou a cerca de 12 linhas de adição líquida por desenvolvedor por dia. Sem contar as alterações, o código de teste ou o fato de que os desenvolvedores não estavam trabalhando no código real do projeto todos os dias.

Como estão as outras pessoas? E que tipo de requisitos você enfrenta (imagino que seja um fator)?

Eu acho que o número de linhas adicionadas depende muito do estado do projeto, a taxa de inclusão em um novo projeto será muito maior que a taxa de um projeto inicial.

O trabalho é diferente entre os dois - em um projeto grande, você costuma passar a maior parte do tempo imaginando os relacionamentos entre as partes e apenas uma pequena quantia para realmente mudar / adicionar. enquanto em um novo projeto - você escreve principalmente ... até que seja grande o suficiente e a taxa diminua.

Em um dos meus projetos atuais, em alguns módulos, tenho orgulho de ter contribuído com uma contagem de linhas negativa para a base de código. Identificar quais áreas do código aumentaram a complexidade desnecessária e podem ser simplificadas com um design mais limpo e claro é uma habilidade útil.

É claro que alguns problemas são inerentemente complexos e exigem soluções complexas, mas na maioria dos grandes projetos, as áreas com requisitos mal definidos ou em mudança tendem a ter soluções excessivamente complexas com um número maior de problemas por linha.

Dado um problema a resolver, prefiro muito a solução que reduz a contagem de linhas. Obviamente, no início de um projeto pequeno, posso gerar muito mais do que dez linhas de código por dia, mas não costumo pensar na quantidade de código que escrevi, apenas no que ele faz e no quão bem ele faz. Eu certamente não pretendia bater dez linhas por dia ou considerá-lo uma conquista.

Eu gosto desta citação:

Se quisermos contar linhas de código, não devemos considerá-las "linhas produzidas", mas "linhas gastas". - Edsger Dijkstra

Algumas vezes você contribuiu mais removendo o código do que adicionando

Você deve parar de usar essa métrica; na maioria das vezes, não faz sentido. Coesão, acoplamento e complexidade são métricas mais importantes que as linhas de código.

Como estão as outras pessoas?

Sou o único desenvolvedor de tempo integral da nossa empresa e escrevi 500.000 linhas de código OCaml e F # nos últimos 7 anos, o que equivale a cerca de 200 linhas de código por dia. No entanto, a grande maioria desse código são exemplos de tutoriais que consistem em centenas de projetos separados, cada um com algumas centenas de linhas. Além disso, há muita duplicação entre o OCaml e o F #. Não estamos mantendo nenhuma base de códigos interna maior que 50kLOC.

Além de desenvolver e manter nosso próprio software, também tenho consultado muitos clientes do setor nos últimos 7 anos. Para o primeiro cliente , escrevi 2.000 linhas de OCaml ao longo de 3 meses, ou seja, 20 linhas de código por dia. Para o próximo cliente , quatro de nós criamos um compilador que gerou milhões de linhas de código C / C ++ / Python / Java / OCaml, além de documentação em 6 meses, ou seja, 2.000 linhas de código por dia por desenvolvedor. Para outro cliente, substituí 50kLOC de C ++ por 6kLOC de F # em 6 meses, ou seja, -352 linhas de código por dia. Para outro cliente , estou reescrevendo 15kLOC de OCaml em F #, que terá o mesmo tamanho e, portanto, 0 linhas de código por dia.

Para o nosso cliente atual , substituirei 1.600.000 linhas de código C ++ e Mathematica por ~ 160kLOC de F # em 1 ano (escrevendo um compilador sob medida) que será de -6.000 linhas de código por dia. Este será o meu projeto de maior sucesso até o momento e economizará milhões de dólares por ano para o cliente em custos contínuos. Acho que todo mundo deveria tentar escrever -6.000 linhas de código por dia.

Sem realmente verificar minha cópia de "The Mythical Man-Month" (todo mundo que lê isso deve ter uma cópia disponível), houve um capítulo em que Brooks analisava a produtividade por linhas escritas. O ponto interessante, para ele, não era o número real de linhas escritas por dia, mas o fato de que parecia ser praticamente o mesmo no assembler e no PL / I (acho que essa foi a linguagem de nível superior usada).

Brooks não estava disposto a apresentar algum tipo arbitrário de produtividade, mas ele estava trabalhando com dados de projetos reais e, pelo que me lembro, eles poderiam ter sido 12 linhas / dia, em média.

Ele ressaltou que a produtividade pode variar. Ele disse que os compiladores eram três vezes mais difíceis que os programas aplicativos e os sistemas operacionais três vezes mais difíceis que os compiladores. (Ele parece ter gostado de usar multiplicadores de três para separar categorias.)

Não sei se ele apreciou as diferenças individuais entre a produtividade do programador (embora em um argumento de ordem de magnitude ele tenha postulado um fator de sete diferenças), mas como sabemos, produtividade superior não é apenas uma questão de escrever mais. código, mas também escrevendo o código certo para fazer o trabalho.

Há também a questão do meio ambiente. Brooks especulou um pouco sobre o que tornaria os desenvolvedores mais rápidos ou mais lentos. Como muitas pessoas, ele questionou se os modismos atuais (depuração interativa usando sistemas de compartilhamento de tempo) eram melhores do que os métodos antigos (pré-planejamento cuidadoso para uma tomada de duas horas usando toda a máquina).

Dado isso, eu desconsideraria qualquer número real de produtividade que ele apresentasse como inútil; o valor contínuo do livro está nos princípios e nas lições mais gerais que as pessoas persistem em não aprender. (Ei, se todos os tivessem aprendido, o livro seria apenas de interesse histórico, bem como todos os argumentos de Freud de que existe algo como uma mente subconsciente.)

É fácil obter algumas centenas de linhas de código por dia. Mas tente obter algumas centenas de linhas de código de qualidade por dia e isso não é tão fácil. Além disso, depure e passe dias com poucas ou nenhuma nova linha por dia, e a média diminuirá rapidamente. Passei semanas depurando problemas difíceis e a resposta é 1 ou 2 linhas de código.

Seria muito melhor perceber que falar de linhas físicas de código não faz muito sentido. O número de linhas de código físicas (LoC) depende tanto do estilo de codificação que pode variar de uma ordem de magnitude de um desenvolvedor para outro.

No mundo .NET, há uma maneira conveniente de contar o LoC. Ponto de sequência . Um ponto de sequência é uma unidade de depuração, é a parte do código destacada em vermelho escuro ao colocar um ponto de interrupção. Com o ponto de sequência, podemos falar de LoC lógico , e essa métrica pode ser comparada em várias linguagens .NET. A métrica lógica de código LoC é suportada pela maioria das ferramentas .NET, incluindo a métrica de código VisualStudio, NDepend ou NCover.

Por exemplo, aqui está um método 8 LoC (os pontos de sequência dos colchetes iniciais e finais não são levados em consideração):

A produção de LoC deve ser contada a longo prazo. Alguns dias você cuspirá mais de 200 LoC, outros dias passará 8 horas consertando um bug, nem mesmo adicionando um único LoC. Alguns dias, você limpa o código morto e remove o LoC; outros, gasta todo o seu tempo refatorando o código existente e não adicionando nenhum novo LoC ao total.

Pessoalmente, conto um único LoC em minha própria pontuação de produtividade apenas quando:

1. É coberto por testes unitários
2. está associado a algum tipo de contrato de código (se possível, nem todos os LoC, é claro, podem ser verificados por contratos).

Nessa condição, minha pontuação pessoal nos últimos 5 anos codificando a ferramenta NDepend para desenvolvedores .NET é uma média de 80 LoC físico por dia, sem sacrificar a qualidade do código . O ritmo é sustentado e não o vejo diminuindo tão cedo. Em suma, o NDepend é uma base de código em C # que atualmente pesa cerca de 115K de LoC físico

Para aqueles que odeiam contar LoC (vi muitos deles nos comentários aqui), atesto que, uma vez calibrado adequadamente, contar LoC é uma excelente ferramenta de estimativa . Após codificar e medir dezenas de recursos alcançados em meu contexto particular de desenvolvimento, cheguei ao ponto em que posso estimar com precisão o tamanho de qualquer recurso TODO no LoC e o tempo que levarei para entregá-lo à produção.

Não existe uma bala de prata.

Uma única métrica como essa é inútil por si só.

Por exemplo, eu tenho minha própria biblioteca de classes. Atualmente, as seguintes estatísticas são verdadeiras:

Total de linhas: 252.682
Linhas de código: 127.323
Comentários: 99.538
Linhas vazias: 25.821

Vamos supor que eu não escreva nenhum comentário, ou seja, 127.323 linhas de código. Com sua proporção, essa biblioteca de códigos levaria cerca de 10610 dias para ser escrita. São 29 anos.

Certamente não passei 29 anos escrevendo esse código, já que é tudo C #, e C # não existe há tanto tempo.

Agora, você pode argumentar que o código não é tão bom assim, pois obviamente eu devo ter ultrapassado suas métricas de 12 linhas por dia e, sim, eu concordo com isso, mas se quiser reduzir a linha do tempo para quando o 1.0 foi lançado (e eu não comecei a fazê-lo até o lançamento do 2.0), que é 13/02/2002, cerca de 2600 dias, a média é de 48 linhas de código por dia.

Todas essas linhas de código são boas? Parreira não. Mas até 12 linhas de código por dia?

Parreira não.

Tudo depende.

Você pode ter um programador de primeira linha produzindo código na ordem de milhares de linhas por dia, e um programador médio produzindo código na ordem de centenas de linhas por dia, e a qualidade é a mesma.

E sim, haverá bugs.

O total que você deseja é o saldo. A quantidade de código foi alterada, versus o número de bugs encontrados, a complexidade do código e a dificuldade de corrigir esses bugs.

Steve McConnell fornece uma estatística interessante em seu livro "Software Estimation" (pág. 62 Tabela 5.2). Ele distingue entre tipos de projeto (Avionic, Business, Telco, etc) e tamanho de projeto 10 kLOC, 100 kLOC, 250 kLOC. Os números são fornecidos para cada combinação em LOC / StaffMonth. EG Avionic: 200, 50, 40 Sistemas Intranet (interno): 4000, 800, 600 Sistemas embarcados: 300, 70, 60

O que significa: por exemplo. para o projeto Avionic 250-kLOC, existem 40 (LOC / Month) / 22 (Days / Month) == <2LOC / day!

Acho que isso vem dos dias de desenvolvimento em cascata , onde a fase de desenvolvimento real de um projeto pode ser de 20 a 30% do tempo total do projeto. Pegue o total de linhas de código e divida pelo tempo inteiro do projeto e você terá cerca de 10 linhas / dia. Divida apenas o período de codificação e você se aproximará do que as pessoas estão citando.

Nossa base de código é de cerca de 2.2MLoC para um esforço de cerca de 150 homens / ano. Isso significa cerca de 75 linhas de c ++ ou c # por desenvolvedor por dia, durante toda a vida útil do projeto.

Eu acho que o tamanho do projeto e o número de desenvolvedores envolvidos são grandes fatores. Estou muito acima disso ao longo da minha carreira, mas trabalhei sozinho o tempo todo, portanto não há perda em trabalhar com outros programadores.

Bom planejamento, bom design e bons programadores. Você fica com tudo isso e não gasta 30 minutos para escrever uma linha. Sim, todos os projetos exigem que você pare e planeje, pense, discuta, teste e depure, mas em duas linhas por dia todas as empresas precisariam de um exército para fazer com que o tetris funcionasse ...

Resumindo, se você estivesse trabalhando para mim a 2 linhas por hora, seria melhor pegar muitos cofres e massagear meus pés para não ser demitido.

Suspeita-se que esse pedaço perene de doces-gerente tenha sido cunhado quando tudo era um aplicativo sys escrito em C, porque, se nada mais, o número mágico variaria em ordens de magnitude, dependendo do idioma, escala e natureza do aplicativo. E então você deve descontar comentários e atributos. E, finalmente, quem se importa com o número de linhas de código escritas? Você deveria terminar quando atingir 10 mil linhas? 100K? Tão arbitrário.

É inútil.