Quais são os obstáculos à adoção das melhores práticas? Como eles podem ser superados? [fechadas]

Todos nós já vimos (e muitos de nós escrevemos) muitos códigos mal escritos. Por quê? O que nos leva a adotar práticas ruins, e não boas?

A resposta mais óbvia (para mim) é "ignorância", mas tenho certeza de que esse não é o único motivo. Que outros existem? O que podemos fazer para superar a tentação de escrever códigos ruins?

Resistência à mudança.

Esse é o principal fator por trás da ignorância, má administração etc.

O capítulo 30 da Peopleware 2ª edição é dedicado a este tópico. E cita um livro de outro consultor bastante conhecido, escrito um pouco antes:

E deve-se considerar que nada é mais difícil de lidar, mais duvidoso do sucesso, nem mais perigoso de administrar, do que se colocar à frente da introdução de novas ordens. Pois o introdutor tem como inimigos todos os que se beneficiam com as ordens antigas e ele tem defensores mornos em todos aqueles que podem se beneficiar com as novas ordens.

Niccolò Maquiavel: O Príncipe (1513)

DeMarco e Lister continuam afirmando o mantra a ter em mente antes de pedir às pessoas que mudem:

A resposta fundamental à mudança não é lógica, mas emocional.

O processo de mudança raramente é uma movimentação direta e suave das atuais condições abaixo do ideal para o novo mundo aprimorado. Para qualquer mudança não trivial, há sempre um período de confusão e caos antes de chegar ao novo status quo . Aprender novas ferramentas, processos e formas de pensar é difícil e leva tempo. Durante esse período de transição, a produtividade diminui, o moral sofre, as pessoas podem reclamar e desejar se ao menos fosse possível voltar às boas e velhas maneiras de fazer as coisas. Frequentemente, mesmo com todos os problemas, porque sentem que os bons e velhos problemas conhecidos são melhores que os novos, desconhecidos, frustrantes e embaraçosos problemas. Essa é a resistência que deve ser delicada e delicada, mas decididamente superada para ter sucesso.

Com paciência e perseverança, eventualmente, a equipe chega do Caos ao próximo estágio, Prática e Integração. As pessoas, embora não se sintam totalmente à vontade com as novas ferramentas / processos, começam a pegar o jeito delas. Pode haver experiências positivas de "Aha". E gradualmente, a equipe alcança um novo status quo.

É realmente importante perceber que o caos é parte integrante e inevitável do processo de mudança . Sem esse conhecimento - e preparação para isso -, pode-se entrar em pânico ao entrar na fase do Caos e confundi-la com o novo status quo. Posteriormente, o processo de mudança é abandonado e a equipe retorna ao seu estado miserável anterior, mas com ainda menos esperança de melhorar alguma coisa ...

Para referência, as fases descritas acima foram originalmente definidas no Satir Change Model (em homenagem a Virginia Satir ).

Péter Török está certo, mas deixou de fora um ponto importante e otimista:

• as pessoas podem gostar de mudanças nas quais estão envolvidas, mas quase nunca gostam de mudanças que simplesmente "acontecem" com elas

então envolva-os, deixe que eles contribuam com idéias, que eles criem uma participação nela, e não será tão doloroso

Nota: isso é relevante para a programação, pois muitos projetos de software tecnicamente bem-sucedidos falham porque os usuários os rejeitam .

O tempo parece ser grande onde eu trabalho.

Por que adotar o teste de unidade quando você precisa escrever mais código e leva mais tempo para obter um produto liberável? O cliente x quer agora! Código mais rápido!

(Isso obviamente não termina bem)

Isso também é resultado de uma gestão e economia precárias, não cobrando dos clientes o suficiente para gastar o tempo fazendo o que é certo.

Apesar da enorme evidência em contrário, as pessoas geralmente são criaturas muito racionais. A razão pela qual as pessoas não adotam as melhores práticas, como o TDD, por exemplo, é que não acham que valerá a pena. Ou eles pensam que as práticas não são, de fato, melhores; e que isso realmente lhes custará mais do que os salvará. Ou eles pensam que o benefício é tão marginal que o custo da mudança supera o pequeno benefício. A linha inferior é que o problema das melhores práticas é um problema da linha inferior.

Se você deseja ser um agente de mudança, sua tarefa é demonstrar que a percepção deles da linha de fundo é falha. Você precisa mostrar que a melhor prática é realmente a melhor. Que os benefícios são imediatos e significativos . Você precisa mostrar que a curva de aprendizado é pequena o suficiente para suportar e que pelo menos alguns dos benefícios começam imediatamente.

Como você mostra isso? Ao adotar você mesmo as melhores práticas! Nada serve para convencer os outros melhor do que seu próprio comportamento. Se você seguir a melhor prática e for sincero, outros verão que você fez a análise econômica e tomou a decisão oposta. Isso os fará reconsiderar sua decisão. Eles farão isso em particular, e nunca o admitirão a princípio. Mas todos que virem você usando essa prática recomendada reexaminarão sua posição.

É o melhor que você pode esperar. Se a melhor prática for uma prática recomendada, o restante será seguido automaticamente. Oh, não será rápido e haverá muitos obstáculos. A transição será lenta e irregular; e você experimentará muitas decepções. Mas a transição também será inexorável e inevitável. Pode demorar uma geração, mas a melhor prática vai ganhar.

Como prova disso, pergunte a si mesmo quando viu alguém usar goto pela última vez.

É o resultado de não saber ou pensar que se conhece o método ideal. As pessoas não estão escolhendo escrever mal o código; é mais um caso de não conhecer melhor. " Ingenuidade ", em oposição a " ignorância ", seria uma palavra melhor.

A maneira mais simples de se conformar às boas práticas é reconhecer que existe (muito provavelmente) uma maneira melhor de escrever o código que você acabou de escrever e depois aspirar a aprender o que é essa 'melhor maneira'.

Duas causas

• Ignorância.

• Arrogância.

Como eles podem ser superados?

• Incentivos.

Até que os gerentes (ou seja, as pessoas que compram a habilidade do desenvolvedor) exijam as melhores práticas como parte da entrega do software, nada pode mudar. Muitas organizações são claramente esquizofrênicas: educam os desenvolvedores em várias tecnologias e depois exigem software não testado ou um design não testável. Ou pior.

A melhor prática para mim é um software que uma equipe de 8 pessoas escreveu. Não tínhamos requisitos escritos, revisões de código, testes de unidade, documentos de liberação de formato. Sem teste do usuário final, nada do que todos os livros dizem que deveríamos ter feito. O código foi apressado, com bugs e impossível de manter. Foi descartado três anos após o lançamento e foi tão ruim. Então, o que foi tão bom nisso? Dois anos após o primeiro lançamento, o proprietário da empresa (que havia financiado o empreendimento com uma hipoteca em sua própria casa) foi embora com US $ 30 a US $ 40 milhões no bolso de trás.

Frequentemente, perdemos de vista o fato de estarmos (com mais frequência do que não) aqui para produzir software que gera dinheiro para os negócios. As empresas não existem para nos proporcionar uma oportunidade de desenvolver software usando as "Melhores Práticas", elas existem para ganhar dinheiro.

A maioria das práticas de "melhores práticas" não melhora os lucros. Aqueles que adotam, devem e são amplamente adotados. É por isso que a "melhor prática" não é praticada.

Risco aceitável

Você nunca se arriscou e apostou em alguma coisa? Há uma crise de tempo, então você trabalha com a intenção de refatorá-lo mais tarde (em vez de refatorá-lo mais cedo). Isso é realmente considerado uma boa prática para algumas pessoas.

Eventualmente, você se queima bastante e muda de atitude. Pense em todas as 'melhores práticas' existentes. Você pode acompanhar todos eles o tempo todo? Alguém se contradiz? Você não quer perder tempo lidando com todos os valores extremos.

Se eu escrever um código incorreto que funcione e ninguém mais o olhar novamente, ele ainda será considerado ruim? (Por favor, não vamos arruinar o debate filosófico discutindo sobre o que é 'código incorreto'.)

IME é uma combinação do que os outros disseram. Ignorância ("Eu só usei DataSets, por que se preocupar com esse material do LINQ?", Falta de tempo ("O chefe quer que seja feito o mais rápido possível, não podemos gastar muito tempo com isso"), falta de entendimento ("O que há de errado em escrever todo o meu código no code-behind?") todos contribuem.

A ironia que vejo é que, quando você começa a seguir esse caminho, acaba se afundando. Se você cortar custos agora e lançar todo o código de um aplicativo nos arquivos ASPX, nunca poderá corrigi-lo mais tarde; coisas novas continuarão sendo jogadas contra você, o que significa que você deve fazê-las rapidamente, o que significa que você deve apenas lançar todo o código no arquivo ASPX (jurando que o corrigirá algum dia), etc. etc. - espiral porque você não pode mais parar o desenvolvimento e dizer que as coisas precisam ser corrigidas primeiro.

Frequentemente, os desenvolvedores simplesmente não têm mostrado as melhores práticas ou, mais importante, os benefícios de usar uma melhor prática (estou começando a parar de usar o termo 'Melhores práticas' por vários motivos).

Existe uma teoria de que os desenvolvedores são 'deliberadamente preguiçosos'. Em outras palavras, eles tenderão a escolher o caminho de menor resistência.

Uma vez que você mostre rapidamente os benefícios de uma prática melhor (como TDD, ou digamos, seguindo os princípios do SOLID) e que realmente permita que eles sejam um desenvolvedor melhor (mas ainda "preguiçoso"), então você tenderá a achar que a resistência derrete longe.

É uma questão de educação :)

(Falta de) conhecimentos e habilidades + tempo para investir

Estou surpreso que ninguém mais tenha publicado, mas talvez seja óbvio para mim porque muito do meu trabalho foi como programador singleton, sem ninguém (além da pilha) para ir quando luto com alguma coisa. Conheço técnicas melhores - como TDD -, mas muitas vezes não as compreendo o suficiente para usá-las e tenho dificuldade em encontrar boas informações para me ajudar a começar a usá-las. Novamente, usando o TDD como exemplo, eu entendo o significado básico dele - crie testes que afirmam que seu código gera um resultado específico - mas realmente implementá-lo?

Além do fato de o XCode ter testes de unidade embutidos atualmente, não tenho idéia por onde começar. Afirmo que a visualização possui botões X depois de executar uma rotina para criá-los? Que tal afirmar que minhas UIViews foram reorganizadas adequadamente depois que eu chamo a tag rotate?

Caramba, como eu escrevo um teste de unidade no XCode? Isso é outra coisa que preciso gastar tempo aprendendo.

@Zues e @Joshua Smith

Sim, eu concordo que, às vezes, tempo e orçamento são algumas restrições que não permitem que você coloque todos os princípios de “melhor programação” que você conhece em um programa.

Você sabe que a tarefa atual pode ser executada de maneira muito mais robusta, se você tiver mais algum tempo. Mas muito poucos clientes (especialmente se eles estão executando seu primeiro aplicativo para iPhone ou seu primeiro software de inteligência de negócios personalizado) entendem quando você diz que está reimplementando algo que já foi feito porque encontrou uma maneira melhor de fazê-lo.

O mesmo para testes de unidade. Infelizmente ainda estou para encontrar um cliente que esteja pronto para alocar orçamento para eles. A resposta típica é como “Teste de regressão automatizado OK, eu entendo, mas testes de unidade? Não temos tempo para isso! Precisamos torná-lo rápido para o mercado! ”

Duas partes na maior parte da minha experiência:

• Tempo
• conseguir pessoas suficientes para concordar com as melhores práticas para a situação atual

As "melhores práticas" são MUITO subjetivas em muitas situações do mundo real. Se metade da equipe estiver tentando fazer um monte de SOLID e TDD enquanto a outra metade estiver trabalhando 60 horas por semana para reduzir segundos de duração das execuções aqui e ali através de todos os meios necessários, porque você passou do ponto em que é tarde demais para redesenhar algo que não está funcionando a tempo de seu próximo lançamento, você não vai muito longe.

Mesmo se você não estiver enfrentando muita discordância na equipe, é muito difícil obter um acordo formal, documentação e treinamento sobre qualquer política que você decida seguir. Esse é um grande bloco de tempo improdutivo do ponto de vista comercial que você precisará justificar com cuidado.

Às vezes, você descobrirá que o hábito também é um dos principais contribuintes para escrever códigos terríveis.

Você pode ser um programador muito experiente e saber tudo sobre as práticas recomendadas do setor. Inferno, você pode até ser o especialista em tais coisas. A experiência me diz que essas pessoas geralmente não escrevem códigos terríveis e, no entanto, pode ser fácil recorrer a hábitos antigos e fazer algo que você sabe que infringirá as regras, simplesmente porque parece seguro e conveniente. Nesses casos, a ignorância e a arrogância e todos os outros adjetivos que você pode imaginar não importam. Não é necessariamente que esses programadores sejam especificamente ruins no que fazem (embora esse seja o caso com mais frequência), ou mesmo que eles estejam criando uma bagunça terrível.

É lamentável que eu tenha testemunhado isso pessoalmente mais vezes do que gostaria de contar, onde algumas pessoas verdadeiramente talentosas agitaram lixo puro porque seus dedos e cérebros estavam operando no automóvel por alguns meses. Na maioria das vezes, é aqui que você vê evidências de desgaste, dor e estresse. Às vezes, é apenas um hábito cego que os leva através dos movimentos diários. É algo que aprendi a manter um olho atento, a fim de evitar arriscar rotular pessoas vulneráveis ​​desnecessariamente.

Apenas um pouco de reflexão para aqueles de nós que acham mais fácil simplesmente chegar à conclusão negativa ... mesmo que, infelizmente, você esteja certo com mais frequência do que não.

Ninguém mostra interesse em pagar por um projeto intitulado algo ao longo da refatoração. Tem que ter algumas palavras que apelam aos interesses 'comerciais'. Palavras como renovar, revigorar, refazer totalmente, atualizar o ciclo de vida, etc. funcionam no meu local de trabalho. Quase todos eles têm a refatoração como parte principal do projeto.

Infelizmente, graças ao assassino econômico, o trabalho acontece apenas quando há pagamento. Mesmo que o trabalho seja apenas para salvar as fortunas dos negócios a longo prazo.