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

Navegue suas respostas
47

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

Tenho notado que alguns membros da equipe usam padrões de codificação exclusivos até um ponto em que eu poderia escolher um arquivo aleatoriamente para informar quem era o autor do estilo sozinho.

Exemplo 1 (funções inline únicas) 

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

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

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

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 normalmente fazemos isso (evita ter que passar de 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 padrões que o Facebook (o autor do React) sugere em tutoriais e exemplos.

Precisamos manter um ritmo acelerado para entregar a tempo 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 (todo componente pode exigir que você entenda outra maneira de fazer a mesma coisa).

Pergunta:

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

    
por Andreas Warberg 07.07.2015 / 22:11
fonte

7 respostas

48

Vantagem da Transferência de Código

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

Problemas potenciais 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, diminuindo / interrompendo sua futura atualização. Não tenho certeza de como React lidaria com novos lançamentos, mas já vi isso acontecer antes.

Novos membros da equipe começam a ser mais produtivos com rapidez

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

Questões potenciais não descobertas

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

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

    
por 07.07.2015 / 22:25
fonte
53

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

  • Quando você lê parte do código e vê que ele usa um estilo diferente do resto do código, isso faz você se perguntar - por que essa parte em particular é diferente? Tem um motivo especial que eu preciso estar ciente? Isso é perigoso, porque se realmente há uma razão para que essa parte seja diferente, você precisa estar ciente disso ou então você pode criar alguns erros desagradáveis. Então, ao invés de pensar no problema original que fez você ir tocar esse código, você agora perde tempo pensando em por que é diferente, e você não pode descobrir isso, então você vai ao autor original perguntar a eles, perdendo tempo também, e ainda pior - no processo, vocês 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ê precisa adicionar um código que usa vários estilos, é necessário parar e decidir qual estilo usar para sua adição. Você tem que tomar decisões suficientes que importam - é uma 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 o material está localizado. Com estilo inconsistente, até mesmo o grepping se torna mais difícil porque você não sabe qual estilo a coisa que você está procurando está usando.

por 07.07.2015 / 22:37
fonte
4

O código pode estar bem escrito, mas não perfeitamente consistente, então alguns clientes não se importarão. Quando as coisas começam a ficar ruins, você quer dar uma outra pancada em você? Se eu contratei uma empresa para trabalhar em um projeto multi-desenvolvedor e eles não indicaram para mim que eles têm um padrão de codificação e segui-lo, eu ficaria cético.

We need to keep a fast pace in order to deliver on time and I don't want to burden the team unnecessarily.

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

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

    
por 07.07.2015 / 22:31
fonte
2

Eu tive boa sorte tratando de estilos de código como trato 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 em conversas do dia-a-dia, até o inglês formal, que é frequentemente pesado e afetado por um significado sempre muito preciso.

Considere o que você gostaria que o produto final parecesse nesse sentido. Algumas situações são muito favoráveis ao uso de qualquer estrutura que seja melhor no momento. Outros exigem uma cadência e estrutura uniformes. Isto é especialmente verdadeiro se o seu produto é melhor, embora como se estivesse escrito em inglês formal. Os coloquialismos podem ajudar nesse caso, mas eles rasgam a sensação geral do produto.

Em geral, quanto mais consistente for o seu padrão de codificação, menos esforço um desenvolvedor deve levar para chamar sua atenção para algo interessante. Se você suporta uma grande diversidade nos padrões de codificação, os desenvolvedores devem ser mais barulhentos ao anunciar que estão fazendo algo incomum ou único. Essa tentativa de expressar o que um desenvolvedor considera importante muitas vezes pode ofuscar o intervalo dinâmico do próprio código. Quando isso acontece, é fácil ter bugs escorregando porque é simplesmente muito difícil vê-los.

No outro lado desse argumento, quanto mais frouxos forem os 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 pro-coding, muita padronização pode levar a estrutura de código pomposa, o que também pode tornar mais fácil a ocorrência de bugs.

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

    
por 09.07.2015 / 01:10
fonte
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. Há também o risco real de o estilo inconsistente ser propagado para outras seções, resultando em uma enorme confusão depois.

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

We need to keep a fast pace in order to deliver on time and I don't want to burden the team unnecessarily.

Isso sempre parece ser o trade-off universal ... fazendo isso rápido, fazendo certo. Só você pode avaliar as conseqüências de sacrificar boas práticas de codificação na alteração dos prazos dos clientes. 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 atrasar sua equipe tão drasticamente que os prazos caem significativamente.

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

Infelizmente, como o eBusiness afirmou, a menos que seu cliente seja tecnicamente mais experiente ou mantenha o código depois, é difícil para eles apreciar o valor de padrões de codificação consistentes. No entanto, qualquer empresário razoável deve ser capaz de compreender 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 mais tarde" (na forma de desperdício de tempo bagunça).

    
por 09.07.2015 / 04:14
fonte
2

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

Muito foco em coisas menores corre o risco de perder o foco em questões mais importantes, como a forma de resolver o trabalho da maneira mais eficiente em geral.

Eu não me referiria a você primeiro exemplo como estilo, estilo é as escolhas onde não há certo ou errado, neste caso a função extra é o código inchado sem vantagem. São apenas duas linhas extras, ainda fáceis de ler e fáceis de corrigir, então este exemplo em si não é um grande problema.

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

Sobre os clientes

Os clientes tendem a se concentrar em obter um produto funcional que solucione suas necessidades. Mesmo se você tiver um dos poucos clientes que se preocupam com a qualidade do código, essa será uma prioridade secundária, e sua ideia de qualidade do código pode não ser perfeitamente consistente com a sua. A empresa do 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.

    
por 08.07.2015 / 16:05
fonte
0

É muito sobre a legibilidade dos diffs. Se o estilo de código se move, os diffs escondem alterações sem significado semântico para o programa, e podem dificultar ou dificultar as mesclas.

    
por 08.07.2015 / 21:09
fonte

Tags

Por que 2 ^ 16 é um número “especial”? [fechadas] Está tendo datas de entrega fixas para os elementos uma maneira “Ágil” de trabalhar?