Padrões de codificação Python vs. produtividade

Trabalho para uma grande organização humanitária, em um projeto de construção de software que poderia ajudar a salvar vidas em emergências, acelerando a distribuição de alimentos. Muitas ONGs precisam desesperadamente do nosso software e estamos com semanas de atraso.

Uma coisa que me preocupa nesse projeto é o que eu acho que é um foco excessivo nos padrões de codificação. Nós escrevemos em python / django e usamos uma versão do PEP0008, com várias modificações, por exemplo, comprimentos de linha podem ir até 160 caracteres e todas as linhas devem demorar tanto se possível, sem linhas em branco entre as importações, regras de quebra de linha que se aplicam apenas a certos tipos de classes, muitos modelos que devemos usar, mesmo que não sejam a melhor maneira de resolver um problema etc. etc.

Um desenvolvedor central passou uma semana reescrevendo uma parte importante do sistema para atender aos então novos padrões de codificação, descartando vários conjuntos de testes no processo, pois a reescrita significava que eles eram 'inválidos'. Passamos duas semanas reescrevendo todas as funcionalidades perdidas e corrigindo bugs. Ele é o desenvolvedor líder e sua palavra tem peso; portanto, convenceu o gerente de projeto de que esses padrões são necessários. Os desenvolvedores juniores fazem o que mandam. Sinto que o gerente de projeto tem um forte sentimento de dissonância cognitiva em relação a tudo isso, mas mesmo assim concorda veementemente, pois não tem certeza do que mais fazer.

Hoje, tive um problema sério porque esqueci de colocar alguns espaços após vírgulas em um argumento de palavra-chave. Fui literalmente gritado por dois outros desenvolvedores e pelo gerente de projeto durante uma chamada do Skype. Pessoalmente, acho que os padrões de codificação são importantes, mas também acho que estamos perdendo muito tempo obcecados por eles e, quando verbalizei isso, provocou raiva. Sou visto como um causador de problemas na equipe, uma equipe que procura bodes expiatórios por suas falhas. Desde a introdução dos padrões de codificação, a produtividade da equipe despencou de forma mensurável, no entanto, isso apenas reforça a obsessão, ou seja, o desenvolvedor líder simplesmente culpa a nossa não adesão aos padrões pela falta de progresso. Ele acredita que não podemos ler o código um do outro se não seguirmos as convenções.

Isso está começando a ficar pegajoso. Agora estou tentando modificar vários scripts, autopep8, pep8ify e PythonTidy para tentar corresponder às convenções. Também executamos o pep8 no código fonte, mas há tantas alterações implícitas em nosso padrão que é difícil rastrear todas elas. O desenvolvedor principal simples escolhe falhas que o script pep8 não pega e grita conosco na próxima reunião de stand-up. Toda semana, há novas adições aos padrões de codificação que nos forçam a reescrever o código existente, funcional e testado. Graças a Deus ainda temos testes (reverti alguns commits e consertei vários dos que ele removeu).

O tempo todo aumenta a pressão para cumprir o prazo.

Acredito que uma questão fundamental é que o desenvolvedor líder e outro desenvolvedor principal se recusem a confiar em outros desenvolvedores para fazer seu trabalho. Mas como lidar com isso? Não podemos fazer nosso trabalho porque estamos muito ocupados reescrevendo tudo.

Eu nunca encontrei essa dinâmica em uma equipe de engenharia de software. Estou errado em questionar sua adesão aos padrões de codificação? Alguém já passou por uma situação semelhante e como eles lidaram com sucesso? (Não estou procurando uma discussão, apenas soluções reais que as pessoas encontraram)

Os padrões de codificação não são o problema. O problema é que a gerência não consegue descobrir qual é o problema. Isso leva a "Faça alguma coisa ... qualquer coisa!" modo. Você está procurando uma solução racional, mas é um problema irracional. O melhor que você pode fazer é:

• Faça críticas construtivas às suas idéias, mas uma vez que a decisão seja tomada, não se queixe continuamente.
• Faça o que puder para facilitar a reescrita.
• Pare de se estressar. Prazos perdidos são um problema da gerência, não seu. Faça o seu melhor, mas não assuma a responsabilidade por suas más decisões.
• Se você souber algo que possa ajudar, conte a eles. A sua menção de standups faz parecer que você está tentando agir com agilidade, mas o resto não parece muito alegre. Veja se você pode fornecer funcionalidade limitada mais cedo, em vez de tentar cumprir um grande prazo com tudo. Crie histórias de usuário para as reescritas, para ficar claro como elas estão impactando o backlog.
• Comece a procurar outro emprego. Seriamente. Empresas nesse estado não estão longe de começar a demitir pessoas.
• Imprima algumas camisetas "avisei" :-)

Alguém precisa decidir se o envio ou a adesão servil aos padrões de codificação é a verdadeira prioridade. Eu sei qual seria minha preferência; se está passando nos testes de unidade e aceitação, digo navio. Após o envio, a empresa pode decidir se deve ou não gastar tempo e dinheiro para corrigir a dívida técnica.

Problemas com espaços após vírgulas são facilmente resolvidos com uma ferramenta de pré-verificação de código. Encontre uma ferramenta que aplique todas as suas convenções de codificação e execute-a em todo o código modificado antes da compilação e teste. IDE decente já faz isso, enquanto você escreve o código.

Estou errado em questionar sua adesão aos padrões de codificação?

Depende do grupo. Pessoalmente , acho que tudo deve ser questionado. Algumas pessoas consideram esse questionamento uma afronta; que eu não confio neles.

Alguém já passou por uma situação semelhante e como eles lidaram com sucesso?

Perguntei como esses padrões melhoram a produtividade. Eu medi o tempo que passei brincando com os padrões versus 'fazer as coisas'. No final, os poderes que são decididos seguir os padrões. Acontece. Eu reclamei sobre eles mais alto do que o habitual, porque eles foram a causa de eu não ter feito as coisas, mas de outra forma focada em fazer o meu trabalho. Lutar sobre as coisas continuamente também não é bom para a produtividade ...

Se, como você diz, as coisas são mensuráveis ​​pior devido aos padrões, a adesão aos padrões deve invalidar o argumento do líder e deixar o seu. Se as pessoas não conseguem ver essa correlação objetiva (em grande parte) entre a implementação do padrão e a queda na produtividade, então não há muito o que fazer. Aprenda a lidar com isso e, se não puder, procure um lugar menos burocrático.

Padrões são algo que não deve ser colocado em prática no final do projeto com um prazo aproximado. É algo que deveria ter sido implementado no início do projeto ou quando houver tempo reservado no cronograma do projeto (de preferência após o envio inicial) para (potencialmente) grande refator de código ofensivo.

Se isso foi colocado no final do projeto, é um erro cometido pelo seu líder (IMHO).

No entanto , isso não significa que, se você não concorda com a sua liderança, deve apenas avançar com o motim. Esse é o seu trabalho . Você trabalha em equipe . Você tem uma vantagem . Definitivamente deveria haver algum nível de democracia na equipe, mas no final a liderança é o ditador. Se ele diz para fazer alguma coisa, você faz.

No final, ao atender a seus pedidos e padrões, você não fornece um bode expiatório fácil para a falta de prazos.

Além disso, sou um grande defensor dos padrões de codificação (especialmente à medida que o tamanho de uma equipe aumenta), mas eles devem ser implementados quando faz sentido.

Sua pergunta foi "Estou errado em questionar a aderência deles aos padrões de codificação?". http://c0x.coding-guidelines.com/Introduction.pdf (para linguagem de programação C) tem alguns estudos referenciados sobre o valor das diretrizes de codificação. Consulte a seção 9, começando na página 39.

Os padrões de codificação são implementados por um motivo. Uma coisa que parece estar faltando na pergunta original é a compreensão do motivo desses padrões específicos no projeto específico (ou na organização específica). A decisão de implementá-los no código existente foi baseada em alguma lógica. Sem conhecer a lógica, é difícil comentar sobre a 'bondade' dessa decisão.

Em segundo lugar, alguém disse que os padrões são implementados para 'produtividade a longo prazo' - questões como a manutenção do código. Talvez tenha ocorrido algum evento que atrasou severamente o projeto por causa de confusão e má interpretação.

Parece que há muita emoção de ambos os lados - tente chegar a uma discussão fundamentada.

Como você provavelmente já viu pelas outras respostas e comentários, seu projeto tem grandes problemas, então o que vou sugerir não tem uma grande chance de sucesso, mas é algo que você pode tentar sem grandes riscos no que diz respeito a sua própria pele.

Peça uma reunião entre quatro olhos com seu desenvolvedor principal. Diga que você está interessado em entender completamente os benefícios de ser tão rigoroso com o padrão de codificação e por que a base de código estava tão mal antes de introduzi-los. É muito importante que você mantenha uma atitude muito aberta e "estou tentando aprender" durante esta discussão. Seu desenvolvedor principal provavelmente já está mais estressado do que você ou qualquer outra pessoa da sua equipe e provavelmente ficará muito defensivo assim que sentir um pouco de crítica.

Tente empurrar a discussão na direção de tentar descobrir maneiras de atingir seu objetivo comum; fornecendo software funcional e de manutenção prontamente.

Por exemplo, algumas frutas baixas são não adicionar mais nada às diretrizes de codificação. Sempre que isso acontece, o código que aderiu anteriormente às diretrizes não o faz mais, e isso resulta em que você precisa reescrever os pedaços de código. Esperamos que o seu desenvolvedor líder possa ver que, mesmo que a regra adicionada agregue valor (do ponto de vista dele), ela pode não ser tão boa quanto motivar a reescrita nesta fase do projeto já atrasado.

Se isso funcionar, você pode tentar fazer com que ele remova as regras mais arbitrárias que não podem ser auto-formatadas com alguma ferramenta.

Os padrões de codificação são bons. Alterar os padrões de codificação é caro (bem, é caro se você os tornar menos permissivos; se uma alteração no padrão deixar todo o código existente ainda em conformidade, não será um problema), portanto, isso só deve ser feito quando for absolutamente necessário.

Uma coisa a fazer, talvez, é fazer com que o lead verifique todo o código antes de confirmar / mesclar / o que quer que seja, para garantir que esteja em conformidade com o padrão, pois aparentemente a cadeia de ferramentas existente parece não conseguir verificá-lo automaticamente.

software que poderia ajudar a salvar vidas em emergências, acelerando a distribuição de alimentos

Acredito em bons padrões de codificação, mas também acredito que salvar vidas é muito mais importante.

Sua maior prioridade deve ser salvar a vida das pessoas . Imagine se este software estiver distribuindo alimentos para sua família ou sua equipe. Qualquer outra coisa pode vir a seguir.

A boa notícia: você tem testes. Os testes ajudarão você a cumprir seus padrões de codificação sem interromper a funcionalidade, mas isso deve ocorrer após o envio , não antes.