Em que casos, menos código não é melhor? [fechadas]

Ultimamente, refatorei algum código no trabalho e achei que fiz um bom trabalho. Deixei cair 980 linhas de código para 450 e reduzi pela metade o número de classes.

Ao mostrar isso aos meus colegas, alguns não concordaram que isso fosse uma melhoria.

Eles disseram - "menos linhas de código não são necessariamente melhores"

Percebo que pode haver casos extremos em que as pessoas escrevem linhas realmente longas e / ou colocam tudo em um único método para salvar algumas linhas, mas não foi o que fiz. Na minha opinião, o código é bem estruturado e mais simples de compreender / manter, por ter metade do tamanho.

Estou lutando para ver por que alguém iria querer trabalhar com o dobro do código necessário para realizar um trabalho, e estou imaginando se alguém se sente da mesma forma que meus colegas e pode fazer bons casos por ter mais código por menos ?

Uma pessoa magra não é necessariamente mais saudável que uma pessoa com sobrepeso.

Uma história infantil de 980 linhas é mais fácil de ler do que uma tese de 450 linhas de física.

Existem muitos atributos que determinam a qualidade do seu código. Alguns são simplesmente computados, como Complexidade Ciclomática e Complexidade de Halstead . Outros são definidos de maneira mais vaga, como coesão , legibilidade, compreensibilidade, extensibilidade, robustez, correção, auto-documentação, limpeza, testabilidade e muito mais.

Pode ser, por exemplo, que, enquanto você reduzia o tamanho geral do código - você introduzia uma complexidade injustificada adicional e tornava o código mais enigmático.

Dividir um longo pedaço de código em métodos minúsculos pode ser tão prejudicial quanto benéfico .

Peça a seus colegas que forneçam feedback específico sobre o motivo pelo qual eles acham que seus esforços de refatoração produziram um resultado indesejável.

Curiosamente, um colega e eu atualmente estamos no meio de um refator que aumentará o número de classes e funções em pouco menos do que o dobro, embora as linhas de código permaneçam iguais. Por isso, tenho um bom exemplo.

No nosso caso, tínhamos uma camada de abstração que realmente deveria ter sido duas. Tudo estava amontoado na camada da interface do usuário. Ao dividi-lo em duas camadas, tudo se torna mais coeso, e testar e manter as peças individuais se torna muito mais simples.

Não é o tamanho do código que está incomodando seus colegas, é outra coisa. Se eles não conseguirem articulá-lo, tente olhar o código como se nunca tivesse visto a implementação antiga e avaliá-lo por seus próprios méritos, e não apenas em comparação. Às vezes, quando faço uma refatoração longa, meio que perco de vista o objetivo original e levo as coisas longe demais. Dê uma olhada crítica no "quadro geral" e coloque-a de volta nos trilhos, talvez com a ajuda de um programador de pares, cujo conselho você valoriza.

Uma citação, muitas vezes atribuída a Albert Einstein, vem à mente:

Faça tudo da forma mais simples possível, mas não muito simples.

Quando você exagera no corte de itens, pode tornar o código mais difícil de ler. Como "fácil / difícil de ler" pode ser um termo muito subjetivo, explicarei exatamente o que quero dizer com isso: uma medida do grau de dificuldade que um desenvolvedor experiente terá ao determinar "o que esse código faz?" apenas olhando a fonte, sem o auxílio de ferramentas especializadas.

Idiomas como Java e Pascal são famosos por sua verbosidade. As pessoas frequentemente apontam para certos elementos sintáticos e dizem ironicamente que "elas estão lá apenas para facilitar o trabalho do compilador". Isso é mais ou menos verdade, exceto a parte "justa". Quanto mais informações explícitas houver, mais fácil será a leitura e a compreensão do código, não apenas por um compilador, mas também por um ser humano.

Se eu digo var x = 2 + 2;, é imediatamente óbvio que xé suposto ser um número inteiro. Mas se eu disser var foo = value.Response;, é bem menos claro o que foorepresenta ou quais são suas propriedades e capacidades. Mesmo que o compilador possa inferir facilmente, ele coloca muito mais esforço cognitivo em uma pessoa.

Lembre-se de que os programas devem ser escritos para que as pessoas leiam e, incidentalmente, para as máquinas executarem. (Ironicamente, essa citação vem de um livro didático dedicado a um idioma famoso por ser extremamente difícil de ler!) É uma boa idéia remover coisas que são redundantes, mas não retire um código que facilite o contato com os seres humanos. descobrir o que está acontecendo, mesmo que não seja estritamente necessário para a gravação do programa.

Um código mais longo pode ser mais fácil de ler. Geralmente é o oposto, mas há muitas exceções - algumas delas descritas em outras respostas.

Mas vamos olhar de um ângulo diferente. Assumimos que o novo código será considerado superior pela maioria dos programadores qualificados que veem os dois trechos de código sem ter conhecimento adicional da cultura, da base de códigos ou do roteiro da empresa. Mesmo assim, há muitos motivos para contestar o novo código. Por uma questão de brevidade, chamarei "Pessoas que criticam o novo código" Pecritenc :

• Estabilidade. Se se sabia que o código antigo era estável, a estabilidade do novo código é desconhecida. Antes que o novo código possa ser usado, ele ainda precisa ser testado. Se, por algum motivo, o teste adequado não estiver disponível, a mudança será um grande problema. Mesmo se o teste estiver disponível, o Pecritenc pode pensar que o esforço não vale a melhoria (menor) do código.
• Desempenho / escala. O código antigo pode ter melhorado a escala e o Pecritenc assume que o desempenho se tornará um problema no futuro, à medida que clientes e recursos em breve * se acumulam.
• Extensibilidade. O código antigo pode ter permitido a introdução fácil de alguns recursos que o Pecritenc supõe que sejam adicionados em breve *.
• Familiaridade. O código antigo pode ter reutilizado padrões usados ​​em outros 5 locais da base de código da empresa. Ao mesmo tempo, o novo código usa um padrão sofisticado que apenas metade da empresa já ouviu falar nesse momento.
• Batom em um porco. O Pecritenc pode pensar que tanto o código antigo quanto o novo são inúteis ou irrelevantes, tornando inútil qualquer comparação entre eles.
• Orgulho. Pecritenc pode ter sido o autor original do código e não gosta de pessoas fazendo grandes mudanças em seu código. Ele pode até ver as melhorias como um insulto leve, porque elas sugerem que ele deveria ter feito melhor.

Que tipo de código é melhor pode depender da experiência dos programadores e também das ferramentas que eles usam. Por exemplo, eis por que o que normalmente seria considerado código mal escrito pode ser mais eficaz em algumas situações do que o código orientado a objetos bem escrito que faz uso total da herança:

(1) Alguns programadores simplesmente não têm uma compreensão intuitiva da programação orientada a objetos. Se sua metáfora para um projeto de software é um circuito elétrico, você espera muita duplicação de código. Você gostaria de ver mais ou menos os mesmos métodos em muitas classes. Eles vão fazer você se sentir em casa. E um projeto em que você precisa procurar métodos nas classes principais ou mesmo nas classes dos avós para ver o que está acontecendo pode parecer hostil. Você não quer entender como a classe pai funciona e depois entender como a classe atual difere. Você quer entender diretamente como a classe atual funciona e acha confuso o fato de que as informações estão espalhadas por vários arquivos.

Além disso, quando você apenas deseja corrigir um problema específico em uma classe específica, pode não gostar de pensar em corrigir o problema diretamente na classe base ou sobrescrever o método na sua classe de interesse atual. (Sem herança, você não precisaria tomar uma decisão consciente. O padrão é ignorar problemas semelhantes em classes semelhantes até que sejam relatados como bugs.) Esse último aspecto não é realmente um argumento válido, embora possa explicar algumas das oposição.

(2) Alguns programadores usam muito o depurador. Embora em geral eu esteja firmemente do lado da herança de código e impeça a duplicação, compartilho parte da frustração que descrevi em (1) ao depurar código orientado a objetos. Quando você segue a execução do código, às vezes ele continua pulando entre as classes (ancestrais), mesmo que permaneça no mesmo objeto. Além disso, ao definir um ponto de interrupção em um código bem escrito, é mais provável que ele seja acionado quando não for útil; portanto, você pode ter que se esforçar para torná-lo condicional (quando possível) ou até mesmo continuar manualmente muitas vezes antes do acionador relevante.

Depende totalmente. Eu tenho trabalhado em um projeto que não permite variáveis ​​booleanas como parâmetros de função, mas requer um dedicado enumpara cada opção.

Assim,

enum OPTION1 { OPTION1_OFF, OPTION1_ON };
enum OPTION2 { OPTION2_OFF, OPTION2_ON };

void doSomething(OPTION1, OPTION2);

é muito mais detalhado do que

void doSomething(bool, bool);

Contudo,

doSomething(OPTION1_ON, OPTION2_OFF);

é muito mais legível do que

doSomething(true, false);

O compilador deve gerar o mesmo código para ambos, portanto, não há nada a ser ganho usando o formato mais curto.

Eu diria que a coesão pode ser um problema.

Por exemplo, em um aplicativo da web, digamos que você tenha uma página de administrador na qual você indexa todos os produtos, que é essencialmente o mesmo código (índice) que você usaria em uma situação de página inicial, para .. apenas indexar os produtos.

Se você decidir parcializar tudo para ficar seco e elegante, precisará adicionar muitas condições para saber se a navegação do usuário é ou não um administrador e desordenar o código com coisas desnecessárias, o que o tornará altamente ilegível, digamos um designer!

Portanto, em uma situação como essa, mesmo que o código seja praticamente o mesmo, apenas porque ele pode ser dimensionado para outra coisa e os casos de uso podem mudar levemente, seria ruim ir atrás de cada um deles adicionando condições e ifs. Portanto, uma boa estratégia seria abandonar o conceito DRY e dividir o código em peças de manutenção.

• Quando menos código não faz o mesmo trabalho que mais código. A refatoração para simplificar é boa, mas você deve tomar cuidado para não simplificar demais o espaço do problema que esta solução atende. 980 linhas de código podem lidar com mais casos de canto que 450.
• Quando menos código não falha tão graciosamente quanto mais código. Eu vi alguns trabalhos de "ref *** toring" realizados no código para remover a tentativa de captura "desnecessária" e outro tratamento de casos de erro. O resultado inevitável foi, em vez de mostrar uma caixa de diálogo com uma boa mensagem sobre o erro e o que o usuário poderia fazer, o aplicativo travou ou YSODed.

• Quando menos código é menos sustentável / extensível que mais código. A refatoração para concisão do código geralmente remove construções de código "desnecessárias" no interesse do LoC. O problema é que essas construções de código, como declarações de interface paralela, métodos / subclasses extraídos, etc, são necessárias, caso esse código precise fazer mais do que atualmente ou de forma diferente. No extremo, certas soluções personalizadas para o problema específico podem não funcionar se a definição do problema mudar um pouco.

  Um exemplo; você tem uma lista de números inteiros. Cada um desses números inteiros possui um valor duplicado na lista, exceto um. Seu algoritmo deve encontrar esse valor não emparelhado. A solução de caso geral é comparar todos os números com todos os outros números até encontrar um número que não tem dupe na lista, que é uma operação de tempo N ^ 2. Você também pode criar um histograma usando uma hashtable, mas isso é muito ineficiente em espaço. No entanto, você pode torná-lo em tempo linear e espaço constante usando uma operação XOR bit a bit; XOR todo número inteiro em relação a um "total" em execução (começando com zero) e, no final, a soma em execução será o valor do seu número inteiro não emparelhado. Muito elegante. Até que os requisitos sejam alterados e mais de um número na lista possa não ser emparelhado, ou os números inteiros incluem zero. Agora, seu programa retorna lixo ou resultados ambíguos (se retornar zero, isso significa que todos os elementos estão emparelhados ou que o elemento não emparelhado é zero?). Esse é o problema de implementações "inteligentes" na programação do mundo real.

• Quando menos código é menos documentado do que mais código. Ser capaz de ler o próprio código e determinar o que ele está fazendo é fundamental para o desenvolvimento da equipe. Dar um algoritmo de cérebro-f *** que você escreveu que funciona muito bem a um desenvolvedor júnior e pedir para ele ajustá-lo para modificar um pouco a saída não vai levar muito longe. Muitos desenvolvedores seniores também teriam problemas com essa situação. Ser capaz de entender a qualquer momento o que o código está fazendo e o que pode dar errado com ele é a chave para um ambiente de desenvolvimento de equipe de trabalho (e até solo; garanto que o flash da genialidade que você tinha ao escrever um O método on-line para curar o câncer desaparecerá há muito tempo quando você voltar a essa função procurando curá-la também.)

O código do computador precisa fazer várias coisas. Um código "minimalista" que não faz essas coisas não é um bom código.

Por exemplo, um programa de computador deve cobrir todos os casos possíveis (ou no mínimo, todos os casos prováveis). Se um trecho de código cobre apenas um "caso base" e ignora outros, não é um bom código, mesmo que breve.

O código do computador deve ser "escalável". Um código enigmático pode funcionar para apenas um aplicativo especializado, enquanto um programa mais longo, porém mais aberto, pode facilitar a adição de novos aplicativos.

O código do computador deve ficar claro. Como outro respondedor demonstrou, é possível que um codificador de núcleo duro produza uma função do tipo "algorítmica" de uma linha que faz o trabalho. Mas o one-liner teve que ser dividido em cinco "sentenças" diferentes antes de ficar claro para o programador médio.

Desempenho computacional. Ao otimizar o alinhamento de tubos ou as partes em execução do seu código em paralelo, pode ser benéfico, por exemplo, não fazer um loop de 1 a 400, mas de 1 a 50 e colocar 8 instâncias de código semelhante em cada loop. Não estou assumindo que esse foi o caso na sua situação, mas é um exemplo em que mais linhas são melhores (em termos de desempenho).