Qual é o valor real de um estilo de código consistente


47

Faço parte de uma equipe de consultores que implementa uma nova solução para um cliente. Sou responsável pela maioria das revisões de código na base de código do lado do cliente (React e javascript).

Percebi que alguns membros da equipe usam padrões de codificação únicos a um ponto em que eu poderia escolher um arquivo aleatoriamente para dizer quem era o autor apenas do estilo.

Exemplo 1 (funções inline únicas)

React.createClass({
  render: function () {
    var someFunc = function () {
      ...
      return someValue;
    };
    return <div>{someFunc()}</div>
  }
});

O autor argumenta que, ao atribuir um nome significativo a someFunc, o código será mais fácil de ler. Acredito que, ao incluir a função e adicionar um comentário, o mesmo efeito pode ser alcançado.

Exemplo 2 (funções não acopladas)

function renderSomePart(props, state) {
    return (
      <div>
        <p>{props.myProp}</p>
        <p>{state.myState}</p>
      </div>
    );
}

React.createClass({
  render: function () {
    return <div>{renderSomePart(this.props, this.state)}</div>;
  }
});

É assim que geralmente fazemos (evita ter que passar estado e adereços):

React.createClass({
  renderSomePart: function () {
    return (
      <div>
        <p>{this.props.myProp}</p>
        <p>{this.state.myState}</p>
      </div>
    );
  },
  render: function () {
    return <div>{this.renderSomePart()}</div>;
  }
});

Embora esses padrões de codificação sejam tecnicamente corretos, eles não são consistentes com o restante da base de código nem com o estilo e os padrões que o Facebook (o autor do React) sugere em tutoriais e exemplos.

Precisamos manter um ritmo acelerado para cumprir o prazo e não quero sobrecarregar a equipe desnecessariamente. Ao mesmo tempo, precisamos estar em um nível de qualidade razoável.

Estou tentando me imaginar como o desenvolvedor de manutenção dos clientes diante de inconsistências como essas (cada componente pode exigir que você entenda outra maneira de fazer a mesma coisa).

Pergunta, questão:

Qual é o valor percebido pelo cliente e seus desenvolvedores de manutenção de uma base de código consistente versus permitir que inconsistências como essas permaneçam e potencialmente se espalhem?


50
Qual é o valor de uma ortografia consistente? Uma aceleração permanente e constante na leitura e escrita de textos. Qual é o valor do estilo de código consistente? Uma aceleração permanente e consistente na leitura e gravação de código. O que mais você poderia querer?
Kilian Foth

9
Quando você lê coisas, acostuma-se a padrões no que está lendo e antecipa como ler coisas futuras. Se não houver consistência, não se pode antecipar padrões e é necessário fazer mais interpretação do código, diminuindo a velocidade do leitor.
Canadian Coder 07/07

1
Joel tem algumas boas idéias sobre esse tópico. Em resumo, um bom padrão de codificação facilita a visualização de bugs. joelonsoftware.com/articles/Wrong.html

13
Quero acrescentar que as funções nomeadas são quase sempre preferidas às funções anônimas no JavaScript. Ao depurar, isso ajuda muito a determinar onde você está na pilha.
Mike McMahon

1
@yoniLavi, você deve perguntar isso na meta.
RubberDuck

Respostas:


48

Vantagem de transferência de código

Seguir os padrões fornecidos por uma biblioteca, Reactno seu caso, significa que o produto que você entrega será facilmente escolhido e mantido por outros desenvolvedores que também estão familiarizados com o React.

Potenciais problemas de compatibilidade com versões anteriores

Algumas bibliotecas têm uma nova versão principal e a compatibilidade com versões anteriores pode ser comprometida se seus padrões forem significativamente diferentes, retardando / interrompendo sua atualização futura. Não sei como Reactlidar com novos lançamentos, mas já vi isso acontecer antes.

Novos membros da equipe começam a ser produtivos mais rapidamente

Se você seguir o que é fornecido pelo autor, é mais provável que esteja contratando desenvolvedores talentosos usando sua estrutura e inicie-os mais rapidamente com seu sistema, em vez de ensinar novos padrões.

Problemas potenciais não descobertos

Pode haver problemas no futuro que você ainda não descobriu com sua abordagem, resolvidos pela abordagem do autor.

Dito isto, a inovação é sempre um risco; se você acha que sua abordagem é melhor e funciona para sua equipe, vá em frente!


Obrigado por esses excelentes pontos. Geralmente, seguimos os padrões fornecidos pela biblioteca. Os exemplos que eu dei (encontrados nas revisões de código) são diferentes. Fiquei preocupado com o fato de o cliente rejeitar e exigir que refizemos uma parte de nossa entrega porque não "parecia e parecia reagir". Agora eu sei por que eles fariam isso.
Andreas Warberg 07/07

2
+1 "rather than teaching new patterns"- o treinamento processual é um grande desperdício de tempo com novas contratações. Sempre se esforce para minimizar o custo do tempo
pegando

1
@Alexus: Em relação à compatibilidade com versões anteriores, o React ainda não está na versão 1.0. A versão atual, 0,13, quebrou a compatibilidade de maneiras bastante drásticas, embora a ocorrência dessas falhas dependa de qual mecanismo é usado para chamar os componentes do React. Ter regras muito consistentes sobre como chamar o React pode não impedir que as atualizações do React quebrem o código, mas a correção de códigos consistentes é mais fácil, rápida e confiável. Suas preocupações com problemas de compatibilidade com versões anteriores são definitivamente justificadas no caso do React. Por exemplo, veja meu comentário em stackoverflow.com/a/20913637/18192
Brian

53

Inconsistências fazem você parar e pensar por que , onde e onde :

  • Quando você lê parte do código e vê que ele usa um estilo diferente do restante do código, você se pergunta: por que essa parte específica é diferente? Tem algum motivo especial que eu preciso conhecer? Isso é perigoso, porque se realmente existe uma razão para essa parte ser diferente, você precisa estar ciente disso ou pode criar alguns erros desagradáveis. Portanto, em vez de pensar no problema original que o levou a tocar nesse código, agora perde tempo pensando no motivo de ser diferente, e você não pode descobrir isso, então vai ao autor original perguntar, perdendo tempo também, e ainda pior - no processo, vocês dois perdem o modelo mental dos problemas em que estavam trabalhando.

    Multiplique por todos os outros desenvolvedores da equipe que precisam tocar / ler esse código.

  • Quando você precisar adicionar um código que use vários estilos, precisará parar e decidir qual estilo usar para sua adição. Você precisa tomar decisões suficientes que importam - é perda de tempo perder tempo pensando em decisões que não importam.

  • Quando o estilo é consistente, é fácil navegar pelo código, porque a consistência ajuda a encontrar rapidamente onde as coisas estão localizadas. Com um estilo inconsistente, até o grepping se torna mais difícil, porque você não sabe qual estilo a coisa que está procurando está usando.


6
Ótima percepção fanstastic. Por que alguns desenvolvedores parecem apenas 'entender' isso e outros lutam contra isso?
Dogweather

2
Suspeito, porque um estilo consistente sendo proposto agora é profundamente inconsistente com o que eles trabalharam em projetos anteriores. Especialmente para aqueles com uma quantidade substancial de experiência em diferentes ambientes.
Kickstart

4

O código pode ser bem escrito, mas não perfeitamente consistente, portanto, alguns clientes não se importam. Quando as coisas começam a ficar ruins, você quer dar-lhes outra batida contra você? Se eu contratasse uma empresa para trabalhar em um projeto com vários desenvolvedores e eles não me indicassem que têm um padrão de codificação e o seguem, eu ficaria cético.

Precisamos manter um ritmo acelerado para cumprir o prazo e não quero sobrecarregar a equipe desnecessariamente.

Desde que os padrões de codificação não sejam muito loucos, não deve ser tão difícil para todos entrarem. Os projetos ficam paralisados ​​porque as pessoas não sabem qual código escrever ou não, e não devido à digitação e formatação. Você saberá que foi longe demais quando leva uma quantidade desproporcional de tempo para aderir. Felizmente, este não é o seu primeiro rodeio.

Realize seu próprio teste Tudo que você precisa fazer é alternar as atribuições no meio de um desenvolvedor para o outro e fazer com que elas concluam o arquivo de outra pessoa. Eles gastam tempo reformatando completamente as coisas em sua versão? É muito difícil de seguir? Isso vai piorar para a equipe de manutenção do seu cliente.


2

Tive sorte em tratar os estilos de código, assim como os estilos de escrita em inglês natural. Há uma enorme variedade de estilos, desde o inglês de conversação, que imita a maneira como falamos na conversa diária, até o inglês formal, que geralmente é pesado e empolgado por sempre muito preciso em seu significado.

Considere como você gostaria que o produto final fosse nesse sentido. Algumas situações são muito favoráveis ​​ao uso de qualquer estrutura que seja melhor no momento. Outros requerem uma cadência e estrutura uniformes. Isto é especialmente verdade se o seu produto for o melhor, como se tivesse sido escrito em inglês formal. Os coloquialismos podem ajudar nesse caso, mas afetam a sensação geral do produto.

Em geral, quanto mais consistente for o seu padrão de codificação, menor o esforço que um desenvolvedor precisa para chamar sua atenção para algo interessante. Se você oferece suporte a grande diversidade de padrões de codificação, os desenvolvedores devem ser mais altos ao anunciar que estão fazendo algo incomum ou exclusivo. Essa tentativa de expressar o que um desenvolvedor considera importante geralmente pode ofuscar a faixa dinâmica do próprio código. Quando isso acontece, é fácil que os bugs passem, porque é muito difícil vê-los.

Por outro lado, quanto mais fracos forem seus padrões de codificação, mais liberdade os desenvolvedores terão para adaptar sua sintaxe ao problema. Em contraste irônico com o argumento dos padrões pró-codificação, muita padronização pode levar a uma estrutura de código rígida, o que também pode facilitar a passagem de bugs.

O que você está procurando é o meio feliz de sua própria equipe.


2

Como vários outros apontaram, quando os desenvolvedores de manutenção precisam ir atrás de você, uma seção de código em um estilo diferente fará com que eles parem e tentem descobrir o que há de especial nessa seção. Também existe o risco muito real de o estilo inconsistente ser propagado para outras seções, resultando em uma enorme confusão mais tarde.

Tenho a impressão de que, no fundo, você já sabe a resposta para essa pergunta e nem sequer a enfrentaria se não fosse por isso:

Precisamos manter um ritmo acelerado para cumprir o prazo e não quero sobrecarregar a equipe desnecessariamente.

Esse sempre parece ser o compromisso universal ... fazer rápido ou errado. Somente você pode avaliar as conseqüências do sacrifício de boas práticas de codificação na alteração dos prazos do cliente. No entanto, eu tenho que concordar com JeffO quando ele observa que seguir um estilo de codificação (possivelmente incomum ou contra-intuitivo) não deve desacelerar sua equipe de maneira tão drástica que os prazos caem significativamente.

Embora eu conheça o conceito há anos, só recentemente aprendi o termo " dívida técnica ". Você realmente precisa considerar a dívida técnica que acabará por ser paga se não seguir um estilo disciplinado agora.

Infelizmente, como o eBusiness afirmou, a menos que seu cliente seja particularmente experiente em termos técnicos ou mantenha o código posteriormente, é difícil para eles apreciar o valor de padrões consistentes de codificação. No entanto, qualquer empresário razoável deve entender o conceito de que "um pouco de manutenção preventiva agora" (na forma de uma boa codificação) "ajudará a evitar custos significativos de reparo posteriormente" (na forma de desperdício de tempo do desenvolvedor, limpando o bagunça).


O cliente é tecnicamente esclarecido e provavelmente assumirá a manutenção e o desenvolvimento adicional da solução em algum momento. O esforço de perguntas e respostas até agora se concentrou no layout visual e não tanto na funcionalidade. Quando os erros de funcionalidade começarem a surgir, teremos uma ideia de como é a manutenção. Eu acho que as revisões de código seriam mais rápidas com mais consistência (reduzam novas e surpreendentes maneiras de fazer a mesma coisa). Obviamente, o cliente deseja a máxima consistência (mas talvez não pague mais por isso).
Andreas Warberg

2

As respostas mais votadas aqui repetem as melhores práticas teóricas facilmente aceitáveis, detalhando como todos gostaríamos que nossas bases de código fossem. Mas o código real de alguma forma nunca se parece com isso. Se você tentar criar a base de código perfeita, você quase inevitavelmente falhará. Isso não quer dizer que não devamos tentar fazer melhor, mas deve haver um limite para o quão longe do realístico alcançável estabelecemos nossos objetivos.

Muito foco em coisas menores tem o risco de perder o foco em questões mais importantes, como a maneira de resolver o trabalho da maneira mais eficiente possível.

Eu não me referiria ao seu primeiro exemplo como estilo, o estilo é as opções em que não há certo ou errado claro; nesse caso, a função extra é o inchaço do código sem vantagem. São apenas duas linhas extras, ainda fáceis de ler e corrigir, portanto, este exemplo em si não é um grande problema.

A questão muito maior é o inchaço complicado do código. Funções de invólucro, hierarquias de classes e todos os tipos de outras construções, nas quais o código circundante é complexo o suficiente para não ser óbvio que eles não servem a nenhum propósito real. Se houver inchaço óbvio no código, provavelmente há muito mais inchaço não óbvio. É muito mais difícil fazer algo e mais difícil de identificar, mas também uma questão muito maior.

Sobre clientes

Os clientes tendem a se concentrar em obter um produto que atenda às suas necessidades. Mesmo que você tenha um dos poucos clientes que se preocupa com a qualidade do código, isso será uma prioridade secundária, e a ideia deles de qualidade do código pode não ser perfeitamente consistente com a sua. A empresa cliente pode ter seus próprios programadores, mas ainda é o gerenciamento que decidirá se você fez ou não um bom trabalho, e o gerenciamento provavelmente nem sabe o que significa a qualidade do código.


Ao revisar o código, procuro várias coisas que acredito serem definitivamente importantes, como manipulação direta do DOM, seqüências de caracteres não localizadas do usuário, oportunidades de reutilização (um componente existente, auxiliar, biblioteca de terceiros já carregada etc.), alterações incompatíveis ou impróprias para código compartilhado, desvio das convenções de cliente e equipe. O valor da consistência do estilo e dos padrões de codificação não estava claro para mim; portanto, não tinha certeza de como responder àqueles nas revisões de código.
Andreas Warberg

0

É muito sobre a legibilidade das diferenças. Se o estilo do código for alterado, os diffs ocultam as alterações sem significado semântico para o programa e podem tornar as mesclas difíceis ou impossíveis.

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.