Existem usos válidos conhecidos do SLOC para medir a produtividade?


54

Tive uma conversa breve e incomum com um arquiteto sênior sobre linguagens dinâmicas e estáticas. Ele disse que os dados da empresa mostram que há evidências de maior produtividade quando são usadas linguagens estáticas. Observe que é uma grande empresa com longa história. Para minha surpresa (e outras), a métrica que ele usou foi adicionar linhas de código.

Ele rapidamente descartou objeções em relação à métrica, dizendo que em uma mesma empresa, com cultura, linha de negócios e dados suficientes, as diferenças (quanto a situações e capacidades únicas dos indivíduos) se misturam o suficiente para que a métrica SLOC seja útil para comparar a produtividade de ferramentas e linguagens.

Embora eu não ache que essa afirmação seja apoiada por uma análise estatística rigorosa, há alguma evidência no setor que apoiaria essa linha de pensamento?


25
Produtividade é o termo errado. Esse termo é definido como a quantidade de trabalho realizado em um período de tempo, que não está relacionado ao código produzido.
precisa

25
Uma pessoa sábia disse que devemos considerar as linhas de código não como "construídas", mas como "gastas"; na engenharia física, quando consideramos a contagem e o comprimento da lista técnica, menor é melhor.
Pjc50

23
Comparar idiomas diferentes (não importa se estáticos ou dinâmicos) derrota a suposição de "dentro de uma mesma empresa, com cultura e linha de negócios semelhantes": as diferenças nos idiomas tornam as comparações SLOC sem sentido.
22617 Rob

4
Este método é tragicamente falho. Mesmo dois desenvolvedores diferentes na mesma empresa que usam o mesmo ambiente de desenvolvimento geralmente produzem SLOC drasticamente diferentes para implementar o mesmo conjunto de recursos.
17 de 26

8
Usar o SLOC para medir a produtividade faz tanto sentido quanto usar a poluição emitida para medir a distância percorrida quando o que você deveria se importar é com a eficiência do combustível. As maneiras pelas quais isso é certo ainda estão erradas. Use isso .
candied_orange

Respostas:


65

O argumento do arquiteto sênior pode significar duas coisas.

  1. Pode significar que um desenvolvedor médio da empresa produz mais linhas de código ao usar linguagens estáticas do que ao usar dinâmicas. Por exemplo, se quinze desenvolvedores trabalham com Java por seis meses, eles escreverão 100 KLOC, e se os mesmos quinze desenvolvedores trabalharem com Python por seis meses, eles escreverão apenas 50 KLOC.

    Não há correlação entre LOC e produtividade aqui. E se forem necessárias quatro vezes mais linhas de código em Java para produzir o mesmo recurso que em Python? Se isso for verdade, o uso do Python resultaria em duas vezes a produtividade, com base nas métricas do KLOC acima.

  2. Ele também pode significar que um desenvolvedor médio na empresa produz menos linhas de código ao usar linguagens estáticas do que ao usar linguagens dinâmicas: quinze desenvolvedores escreveriam em seis meses 100 KLOC em Java ou 200 KLOC em Python.

    Embora menos linhas de código geralmente sejam melhores (menos código para escrever, ler e manter), ainda não está claro quantos recursos os desenvolvedores Java produziram em comparação aos Python. Talvez eles tenham escrito meias linhas de código em comparação com os desenvolvedores de Python, mas também tenham produzido metade do número de recursos?

Nos dois casos, o LOC não é uma métrica valiosa, porque o mesmo recurso não seria traduzido na mesma quantidade de linhas de código em idiomas diferentes . Algumas línguas tendem a ser mais detalhadas; outros - mais compactos. Embora em alguns casos a compactação seja valiosa, não há regra geral para isso. Um exemplo extremo seria a linguagem Brainfuck, que possui extrema compacidade, mas que não é popular por sua legibilidade. Comparar linguagens semelhantes pode ser complicado: por exemplo, quando se trata de chaves, o Java segue o estilo K&R, enquanto em C #, a chave de abertura fica em sua própria linha na maioria dos casos, quando segue o estilo oficial, o que leva a uma falha artificial. aumento de LOCs para C #. E o que acontece quando se compara uma linguagem processual com uma linguagem orientada a objetos ou com uma linguagem funcional?

Em vez de usar uma métrica propensa a erros, o arquiteto sênior pode confiar em um grupo de métricas que medem a produtividade quando usadas em conjunto: o número de recursos desenvolvidos por mês, o número de bugs introduzidos na base de código e o tempo gasto na solução desses bugs. , a evolução da dívida técnica etc. Essa comparação pode ser complicada no início, pois é preciso levar em consideração o desconhecimento da equipe com o novo idioma. Uma vez que a equipe se familiarize o suficiente, a escolha deve se basear nas métricas estáveis, bem como, em grande parte, na preferência dos próprios membros da equipe.

LOC tem um valor em algumas situações estreitas. Por exemplo, poderia dar uma dica sobre o tamanho do projeto e partes do projeto (e, em média, se correlaciona com os pontos de função, embora seja mais fácil de medir) ou pode indicar os métodos e classes que podem precisar de mais atenção, porque do seu tamanho grande. No entanto, o LOC deve ser usado com cuidado, uma vez que é mal utilizado com frequência por pessoas que imaginam alguma correlação entre coisas não relacionadas. O uso mais humanamente desastroso de LOCs foi no passado a tentativa de medir a produtividade de um desenvolvedor individual com base nos LOCs escritos por mês.


8
Sim. A única métrica em que confio é o número de tickets (recursos, bugs, pesquisas etc.) concluídos por unidade de tempo. Varia de acordo com a equipe (equipe diferente divide os tickets com granularidade diferente), mas dentro da mesma equipe ou grupo de equipes uma cultura emergirá para tornar os tamanhos dos ingressos razoavelmente precisos (desde que você não os compare fora dessa cultura)
slebetman

10
A coisa que eu mais gosto: "Nunca confie em apenas uma métrica"
Chococroc

30
@slebetman Sinto inveja da precisão / consistência da pessoa que criou seus tickets, mas tenho que resolver problemas que variam de "Corrigir escrita de 2 palavras" a "Adicionar recurso X". A métrica dos tickets é ainda menos útil para mim do que o LOC. O código de classe reduzido em 20 LOC, pelo menos, me dá uma idéia do trabalho realizado. A resolução de 5 tickets pode levar uma hora de trabalho, mas pode demorar uma semana.
22417

3
@ R.Schmitz É o mesmo na minha empresa, mas cada ticket também tem um tamanho associado; portanto, somar o tamanho do ticket funcionaria.
Nico Burns

11
Mesmo tentando usar essas métricas tem problemas. E se os recursos adicionados forem complexos e difíceis de implementar? Ou pode até ser uma situação em que recursos específicos são particularmente fáceis ou difíceis de implementar para um idioma, mas em geral o idioma é mais fácil / mais difícil de trabalhar. A falta de produtividade também pode dever-se ao fato de os funcionários atuais não estarem familiarizados com um idioma no início. Não se deve confiar principalmente nas métricas para determinar qual idioma usar.
John Smith

26

Sobre produtividade e SLOC

O problema com o SLOC

O problema com a métrica SLOC é que ela mede uma aproximação da quantidade de código gravado, sem levar em consideração:

  • a qualidade do código (por exemplo, e se, para cada 100 SLOC, você tiver que adicionar outros 90 SLOC por causa de bugs, mas que você não sabe no momento em que seu código é entregue?)
  • os objetivos alcançados com o código (por exemplo, o SLOC de 10K lida com todos os casos de uso ou histórias de usuários esperados? ou apenas com um pequeno subconjunto?)
  • a manutenção do código (ou seja, você precisará adicionar 1% ou 50% a mais de código para ajustar o código aos requisitos em evolução esperados?).

Em outras palavras, a produção de código espaguete não-sustentável, suscetível a erros e com muitas peças coladas, será considerada mais produtiva do que o código reutilizável cuidadosamente projetado.

Portanto, o SLOC definitivamente não é a melhor maneira de medir a produtividade.

Que produtividade estamos considerando?

A produtividade é medida para um processo. Portanto, o SLOC pode ser um indicador perfeitamente válido apenas para o processo de codificação.

Se, por exemplo, você não entende os requisitos ruins, gasta cinco meses para produzir o software, mostra ao usuário, descobre que está errado e gasta mais 5 meses para reescrevê-lo para o zero, você teria a mesma produtividade no SLOC / mês, uma equipe que escreveu o código logo na primeira vez, por exemplo, porque usou um processo ágil que reduz mal-entendidos por meio de feedback frequente. Essa produtividade aparentemente aparente esconde enormes problemas.

Portanto, medir a produtividade do desenvolvimento de software precisa levar em consideração todo o processo, incluindo a análise de requisitos, o design do código, a codificação, o teste, a depuração e a verificação de que as expectativas do usuário são atendidas. Como todas essas atividades são muito diferentes, o melhor é medir o único pensamento que importa: software em funcionamento, ou seja, o que o software produzido significa para o usuário .

Como medir as entregas de software?

Existem várias abordagens:

  • A abordagem típica na engenharia clássica de software é o Function Points (FP). Os pontos de função são medidos com base nos requisitos a serem preenchidos (por exemplo, número de formulários, número de campos em cada formulário, etc ...). A produtividade é então medida em PF por unidade de tempo e por pessoa. Algumas empresas ainda têm dados que informam quantos pontos de função um desenvolvedor pode produzir por unidade de tempo em um determinado idioma para um determinado domínio. O problema com o FP é que ele exige requisitos muito detalhados antecipadamente e consome muito tempo.
  • Uma abordagem mais moderna e pragmática é o story points (SP). Eles são usados ​​para avaliar a complexidade do código a ser produzido e são rotineiramente usados ​​para avaliar a velocidade das equipes de desenvolvimento. No entanto, SP é uma medida de estimativa do trabalho realizado antes que todos os detalhes sejam conhecidos. Não é uma medida final do que realmente aconteceu. Portanto, alguns cuidados devem ser tomados ao usá-lo como uma medida de produtividade, pois podem sair pela culatra no processo de estimativa .

Sobre a produtividade da digitação estática versus dinâmica

Tenho que confessar que sou pessoalmente fã de linguagens de tipo estaticamente, porque no meu íntimo sei que é mais confiável (anos de codificação me provaram isso).

Então, uma coisa que eu tenho certeza é que a linguagem de tipo estaticamente é capaz de evitar muito mais erros / bugs em tempo de compilação (por exemplo, erros de digitação, incompatibilidade nos tipos esperados, etc ...) do que as línguas de tipo não estaticamente. Mas, com toda objetividade, eu não ousaria generalizar abusivamente isso como uma produtividade mais alta.

Seu arquiteto está certo?

Talvez talvez não.

Mas seus argumentos não parecem válidos: o ganho de produtividade da linguagem de tipo estaticamente vem de um número significativo de erros que são detectados antecipadamente pelo compilador.

Consequentemente, não é possível descobrir esse ganho "mais alto" de produtividade observando apenas o SLOC sem observar o retrabalho necessário para linguagens de tipo dinâmico. Portanto, a comparação dele não pode ser justa.

O argumento de circunstâncias comparáveis ​​também não é válido. Algumas linguagens de tipo dinâmico permitem algumas construções de nível superior que exigem menos código do que fazer o mesmo em uma das linguagens de tipo estaticamente clássicas. Portanto, você pode precisar de menos tempo, escrever menos código, mas adicionar a mesma sobrecarga de análise, teste e verificação. Portanto, medir a produtividade pelo SLOC diluiria os possíveis ganhos de produtividade, criando assim um viés contra a linguagem digitada dinamicamente.

Algum estudo para apoiar essa afirmação?

Existem vários estudos acadêmicos recentes sobre o tema. Embora alguns deles vejam uma vantagem da digitação estática, em geral se limita a uma finalidade específica (documentação, reutilização de código ou API mal documentado, etc.). As palavras prudentes também são usadas porque o IDE moderno reduziu significativamente os riscos relacionados à digitação dinâmica:


3
Seus pontos de crítica já foram abordados na pergunta: “ dentro de uma mesma empresa, com cultura, linha de negócios semelhante e com dados suficientes, as diferenças (quanto a situações e capacidades únicas dos indivíduos) se misturam o suficiente para que a métrica SLOC seja útil ”. Ou seja, o argumento era que, nessa escala, todas as bases de código teriam qualidade comparável. Embora pessoalmente, duvido muito que isso seja verdade.
amon

Usamos gitprime ( gitprime.com ) para medições concretas, e uma das coisas que faz é rastrear quantas vezes um desenvolvedor reescreve as mesmas linhas de código. Portanto, se você escreve algum código, obtém um relatório de bug e reescreve o código, ele realmente mede sua eficiência e relata sua produtividade líquida. Em suma, não acho que seus comentários sejam problemas inerentes ao uso do SLoC como uma medida de produtividade. Em vez disso, acho que suas queixas são de sistemas que não medem o SLoC "corretamente".
Conor Mancone #

8
@ConorMancone Ninguém é pago para escrever código. Eles são pagos para criar soluções. Uma analogia seria medir um carpinteiro com quantas pregos e tábuas ele usa. Um palhaço que corta pranchas e dobra mais unhas do que dirige para casa será mais produtivo do que um mestre carpinteiro por essa métrica.
JimmyJames

11
@Christophe Eu tenho experimentado a medição de entregas para produção como a principal métrica de produtividade. A única parte complicada é que algumas coisas podem ser mais trabalhosas do que outras, mas pelo que posso dizer, com o tempo, as coisas tendem a um rendimento bastante consistente (estatisticamente) com base no tamanho e na composição da equipe. Obviamente, muito é necessário para que a atribuição possa ser um desafio, mas é a âncora de qualquer outra medição de produtividade do desenvolvimento.
JimmyJames

2
Anos atrás, em pelo menos uma loja de programação, algumas pessoas escreviam diagramas lógicos e outras pessoas convertiam esses diagramas lógicos em código compilável. Em essência, o compilador da loja tinha pré-processadores humanos. Seria justo usar SLoC / mês para medir a produtividade de um desses pré-processadores humanos; isso é análogo a quantos parafusos um trabalhador da linha de montagem pode instalar nos orifícios onde os engenheiros disseram que deveriam ir. O engenheiro que especifica 100 parafusos quando 15 são o que o trabalho exige está diminuindo a produtividade da empresa. (Da mesma forma, se especificar 5 parafusos!)
David K

7

Aqui está um contra-exemplo para seu arquiteto sênior: Suponha que eu queira escrever uma hierarquia de três classes, duas das quais derivam da terceira, implementando algumas funções virtuais que a classe base define.

Se eu escrever essas três classes em C ++, isso é bastante simples. Declaro as aulas, uso virtual nos locais corretos e pronto.

Se eu escrever essas três classes em C, precisarei adicionar um pouco de código: preciso definir structs para as tabelas v, preciso adicionar um ponteiro da tabela v à classe base, preciso adicionar código para os construtores para realmente definir os ponteiros da tabela v, preciso adicionar código aos construtores para chamar o construtor da classe base, preciso adicionar código para executar a alocação de memória explicitamente antes de chamar um construtor (o que o C ++ newfaz em uma única etapa ), da mesma forma, preciso separar a destruição da free()chamada subsequente e assim por diante.

O ponto é que todas essas coisas adicionais são bastante irracionais. Eu posso fazê-los muito rapidamente. Portanto, não levarei muito mais tempo para escrever a versão C do que preciso para escrever a versão C ++. No entanto, produzi muito mais linhas de código C que código C ++. Tanto que pareço ter sido mais produtivo em C em termos de SLOCs.

Qualquer idioma que exija alguma quantidade de código padrão aparecerá mais produtivo em termos de SLOCs do que um idioma que não exija a mesma quantidade de código padrão.

Veja, o argumento SLOC é tão fundamentalmente defeituoso, que eu realmente consideraria o contrário: eu diria que "os programadores tendem a produzir mais SLOCs em linguagens estáticas" para significar: "linguagens estáticas parecem exigir mais código padrão e, assim, reduzir a produtividade ".


11
Eu gosto da sua última frase.
Peter - Reintegrar Monica

11
"linguagens estáticas parecem exigir mais código padrão e, portanto, reduzem a produtividade": isso mostra novamente como a métrica SLOC é falha. O número final de linhas não considera (1) quantas vezes é necessário reescrever o código antes de obter a solução final (2) quantas linhas de código adicionais na forma de testes de unidade são necessárias (as linguagens dinamicamente tipificadas requerem, em média, mais testes de unidade para ter uma confiança comparável na exatidão do código de produção). A métrica SLOC é definitivamente falha.
Giorgio

6

Eu serei o contrário.

Acompanhamos o SLoC em nosso trabalho (embora não o usemos diretamente nas decisões de pessoal), e já tive pessoas discutindo o que a maioria das pessoas está dizendo em suas respostas. De fato, "LoC não importa, porque a tecnologia X nos permite fazer mais com menos código" ou "Melhores desenvolvedores escrevem códigos melhores e mais curtos e, portanto, não escrevem mais do que ninguém". Na minha experiência (embora eu não tenha números concretos para apoiar essas coisas), essas objeções simplesmente não estão corretas. No meu tempo, vi uma correlação clara na taxa e na qualidade da produção de código para nossos desenvolvedores, quando comparada com todas as outras medidas significativas de sua "competência" geral como engenheiro. Para dar alguns contra-exemplos aos tipos de argumentos apresentados acima:

  1. Sim, alguns idiomas podem fazer mais com menos código. De fato, temos uma estrutura inteira que construímos que "automatiza" grandes partes do desenvolvimento para nossos problemas comerciais específicos (somente back-end). O resultado de tudo isso não é que as pessoas escrevam menos código, mas simplesmente que temos mais tempo para escrever código. Como resultado, em nossa empresa, a taxa geral de escrita de código é bastante constante entre as tecnologias e depende principalmente do nível de competência do engenheiro.
  2. A idéia de que um desenvolvedor melhor produza menos código porque está escrevendo de maneira mais inteligente definitivamente não é verdadeira. Sim, um programa melhor projetado pode ocupar menos linhas de código. No entanto, eu pessoalmente descobri que os desenvolvedores "melhores" que escrevem código mais eficiente não demoram mais para planejá-lo do que um desenvolvedor mais júnior que escreve coisas pelo longo caminho. Como resultado, o desenvolvedor mais sênior concluirá suas tarefas de codificação mais rapidamente e passará a escrever códigos diferentes na mesma taxa alta.

Essa parte final é o meu resumo geral, BTW. O que descobri é que, independentemente da pilha de tecnologia ou tipo de projeto, a maioria dos desenvolvedores tem seu próprio ritmo, que é o ritmo em que operam. Se um idioma possui muitos recursos que tornam os desenvolvedores mais eficazes, isso é um grande benefício para os negócios, mas isso não significa que eles escreverão menos código como resultado. Em vez disso, eles realizam os recursos mais rapidamente e passam rapidamente para o novo código. Novamente, o resultado final é que eles avaliam em que codificam depende principalmente de suas habilidades e menos de sua pilha de tecnologias. De fato, por causa disso, eu geralmente esperaria que a pilha de tecnologia fizesse mais diferença na taxa na qual os tickets e recursos são desenvolvidos do que na taxa na qual as pessoas codificam.

Dito isto, nem a taxa de redação de código nem a taxa de fechamento de tickets são uma medida perfeita de produtividade, e é por isso que não tomamos diretamente decisões de equipe com base no SLoC. Em vez disso, faz parte do processo, e as avaliações dos funcionários são feitas usando o maior número possível de dados. Eu diria que seu arquiteto certamente não é louco.

Uma exceção

A única exceção com a qual concordo é a possibilidade do código da placa da caldeira. Se houver muita copiar e colar de uma classe (ou outra) para colocá-la em funcionamento, isso obviamente distorcerá as métricas. Isso também é verdade se você tiver ferramentas que podem gerar automaticamente grandes quantidades de código para você. No entanto, acho que essas serão frequentemente a exceção e não a regra. Se seus desenvolvedores gastam algum tempo copiando o código da placa da caldeira para começar, você está usando o conjunto de tecnologias errado. Se eles estão realmente escrevendo o código, mesmo que seja bastante repetitivo, espero que isso incline qualquer medida apenas uma pequena quantidade: ao escrever código, na maioria das vezes estamos limitados à rapidez com que podemos pensar no problema. do quão rápido podemos digitar. Mesmo ao escrever um código relativamente repetitivo,

Obviamente, tudo acima é baseado em minha própria experiência pessoal. Sua milhagem pode variar e, obviamente, sou minoria. Sinta-se livre para discordar. Em resumo, porém:

Acho que a taxa de codificação depende mais da rapidez com que você consegue pensar nos seus problemas do que em qualquer outra coisa. Como resultado, descobri que a taxa de codificação é uma medida decente de produtividade, mesmo em conjuntos de tecnologia, com apenas algumas exceções possíveis.


4
Há também uma outra exceção: caça de bugs. A busca de bugs para erros especialmente desagradáveis ​​pode demorar muito, mas geralmente resulta em uma única linha de alteração de código.
Nathan Merrill

@NathanMerrill Esse é um bom ponto, apesar de menos relevante para o OP: a depuração é a depuração em todos os idiomas e (em cima da minha cabeça), não vejo razão para que seja substancialmente mais fácil ou mais difícil de um techstack para outro. Dito isto, essa é uma razão pela qual, em geral, você não pode julgar a produtividade exclusivamente em código escrito, mais do que em qualquer outra métrica.
Conor Mancone #

Usamos o gitprime ( gitprime.com ) em nossa empresa e, como gerente e engenheiro, acho que é a melhor coisa do mundo. Novamente, é apenas parte do cenário para nós, mas foi extremamente útil na identificação de possíveis problemas com engenheiros muito antes de haver um problema real. A transparência é incrível e tudo o que eles fazem se resume ao SLoC. Dada a quantidade de valor e discernimento que ela acrescenta, sempre sou muito duvidoso sobre a tendência de alguns engenheiros de dispensar SLoC imediatamente. Qualquer um é bem-vindo à sua opinião, mas ele definitivamente funciona
Conor Mancone

A questão é perguntar se o LoC pode ser usado para comparar ferramentas e linguagens, no contexto do desenvolvedor sênior dizendo que mostra maior produtividade nas linguagens "estáticas". Você parece estar respondendo a uma pergunta diferente - o LoC pode ser usado para comparar desenvolvedores, mas você ainda concorda que não pode ser usado para comparar idiomas, porque um determinado desenvolvedor grava o mesmo número de LoC, independentemente da ferramenta / idioma? Você diz que é contrário às outras respostas aqui, mas parece que você está de acordo?
TessellatingHeckler

Como desenvolvedor, muitas vezes, peguei um monte de código não-DRY e o substituí por um pequeno conjunto de funcionalidades reutilizáveis. Adicionei uma quantidade significativa de novas funcionalidades. Reduzir a quantidade de código e adicionar um múltiplo de valor real é uma coisa boa no meu livro. Na minha experiência, os melhores engenheiros escrevem menos linhas de código e os piores escrevem mais.
JimmyJames

6

Embora eu esteja pulando na onda. Eu acho que o impacto no comportamento dos programadores precisa ser destacado.

Usar o SLOC como uma medida produtiva tem um efeito tóxico no moral do programador. No momento em que qualquer engenheiro da sua equipe / empresa percebe que é medido no SLOC, várias coisas acontecem:

  1. Eles começam a escrever um código muito mais longo para fazer a mesma função
  2. eles se importarão menos com a qualidade do seu código
  3. eles deixarão de fazer outras coisas que ajudam a sua equipe (recrutamento, depuração, ajuda aos juniores)
  4. eles vão odiar seu trabalho e provavelmente sair

Não posso enfatizar com força o quão corrosivo é projetar o moral, como já vi acontecer duas vezes em duas empresas diferentes. Quaisquer que sejam os casos de uso aparentemente válidos que você possui, eu argumento que é improvável que valha a pena o impacto em sua equipe / empresa, mesmo que haja apenas uma pequena chance de que seu uso seja descoberto. Embora em alguns casos haja uma correlação entre o número de linhas escritas e a quantidade de recursos úteis, incentive todos os comportamentos errados nos seus programadores e envie a mensagem de que a qualidade não é importante.


De fato ... qualquer métrica que desincentivos alguém de remoção de código redundante ( "você teve um negativo sloc métrica esta semana!" É errado, errado liso!
Andrew

1

Geralmente, não é considerado uma maneira válida de medir a produtividade. Código menor geralmente é melhor que código maior; portanto, um desenvolvedor mais produtivo geralmente produz menos código. A produtividade é a maior atingida na depuração; desenvolvedores eficientes gastam pouco tempo depurando.

Linguagens de tipo estático são mais produtivas (se você controlar todas as outras diferenças entre as linguagens), porque, quando usadas com sabedoria, reduzem o tempo de depuração, detectando erros na fase de compilação, onde são mais rápidos de corrigir.


11
Este poderia ser um ponto válido se estivéssemos comparando a produtividade de desenvolvedores individuais. Porém, a questão é sobre a comparação entre idiomas, portanto o contexto é muito diferente. Isso também significa, por exemplo, que código menor não é melhor ou pior que código maior; compare o LOC do código escrito em Brainfuck com o código escrito, digamos, em Ruby.
Arseni Mourzenko

11
@ArseniMourzenko Além de piadas como Brainfuck, as linguagens bem projetadas são comparadas com base na quantidade de código necessária para resolver uma tarefa. Geralmente, essa comparação é chamada de expressividade. É verdade, porém, eu estava falando sobre o LOC em um único idioma, não entre idiomas. Produtividade é geralmente definida como quanto tempo leva para executar uma tarefa; isso não é específico para programação.
precisa

0

A única métrica que você pode usar para comparar a produtividade de desenvolvedores entre idiomas é uma métrica que não compara o código entre os idiomas. Alguns idiomas são notoriamente detalhados (COBOL para a vitória herdada) e outros requerem várias etapas para fazer algo que você pode fazer em uma linha de código (assembly vs. praticamente todo o resto). Mesmo se você comparar apenas linhas de código ativas (ou seja, não conte declarações e conte apenas código que tenha alguma ação envolvida), você ainda poderá distorcer seus resultados.

Você pode argumentar a favor das taxas de mudança. Ou seja, linhas de código adicionadas, comparando a inclinação da produtividade no mesmo período. No entanto, isso não leva em conta alterações negativas nas linhas de código. Por exemplo, você herda um projeto que possui código de copiar e colar em qualquer lugar. Você realiza refatorações rápidas e fáceis para reduzir o número de blocos de código repetidos - por definição, você tem uma inclinação negativa.

Com toda a seriedade, comparar a produtividade de equipes / idiomas não faz sentido, porque há tantos fatores adicionais que afetam a produtividade de uma equipe que você não pode tirar conclusões significativas disso.

Trabalhei em um projeto em que a infraestrutura era muito frágil e as ferramentas estavam desatualizadas. O projeto foi construído em Java com um aplicativo de página única, mas hospedado em um contêiner de portlet sem nenhum benefício aparente. O tempo que levou para fazer mudanças simples foi ridiculamente longo. Se você basear todas as suas conclusões nesse projeto específico, poderá concluir que o Java era ruim ou os Aplicativos de Página Única eram ruins. Nem são verdadeiras. O sistema que o feio projeto deveria substituir foi criado em C # e WebForms. Quando criamos o caso de negócios para estender o aplicativo existente para atender às necessidades dos clientes, nossa produtividade disparou. Isso significa que um aplicativo WebForms fortemente acoplado é superior? Você só pode concluir esse caso em particulare não se estende ao mundo em geral. E isso faz sentido porque havia um aplicativo existente com maturidade suficiente para estender.

Mesmo a comparação das taxas de itens resolvidos no sistema de rastreamento de problemas é falha no sentido de que você está comparando infraestruturas completas do projeto entre si. As bibliotecas e estruturas usadas podem acelerar ou retardar o progresso. Você pode estar na fase inicial com muito pouca inércia a ser superada, onde o projeto "melhor que" está em uma fase de manutenção em que o número de novos tickets é relativamente baixo. Nunca é um caso de comparar coisas semelhantes.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.