Quais são os obstáculos à adoção das melhores práticas? Como eles podem ser superados? [fechadas]
22
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?
Qual é a razão pela qual você pode dizer hoje que o código está mal escrito e não o motivo pelo qual foi escrito?
@ Thorbjørn: Me desculpe, eu não entendo a pergunta?
Kramii Reinstate Monica
@ Kramil, você reconheceu quando escreveu o código mal escrito que estava mal escrito e, em caso afirmativo, por que o escreveu dessa maneira? Caso contrário, o que aconteceu desde que você pode reconhecê-lo agora, ao contrário do anterior.
4
@ Kramii, nenhuma "melhor prática" jamais pode substituir um pensamento racional e crítico. Todas as "melhores práticas" nada mais são do que ferramentas, e usá-las às cegas seria apenas prejudicial. É estúpido seguir algo apenas porque é considerado uma "melhor prática", sem entender a lógica por trás disso. Mas com esse entendimento, você não precisará seguir as "melhores práticas". Portanto, a própria noção de "melhores práticas" é profundamente falha e é inerentemente prejudicial.
21412 SK-logic
Respostas:
29
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 ...
Eu acho que isso é verdade para programadores mais estabelecidos, mas acho que eles representam apenas uma porcentagem muito pequena daqueles que não codificam pelas melhores práticas. Todo o código que vi que não segue as melhores práticas veio de duas outras respostas aqui: falta de tempo e ingenuidade.
precisa saber é o seguinte
1
@ AndrewrewKS, isso diz respeito não apenas aos desenvolvedores, mas também aos gerentes e clientes. Em uma boa equipe e processo de desenvolvimento, os prazos são realistas e os desenvolvedores não recebem tarefas acima das capacidades atuais - ou pelo menos não sem orientação e verificação adequadas. A falha nesses é quase sempre um sinal de que a gerência resiste à adoção das melhores práticas.
Péter Török
Ponto realmente bom - eu não estava pensando em não programadores nessa situação até agora.
precisa saber é o seguinte
A relutância geralmente resulta em uma certa preguiça, o que acaba gerando ignorância.
S.Robins
23
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 .
Você precisa ter cuidado com o ciclismo ! Não deixe que eles também se envolvam!
shapr
18
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.
O tempo é enorme aqui também. Meu chefe nos disse em uma reunião de equipe: "O negócio não paga por um ótimo trabalho".
27711 Joshua Smith
@ Joshua Smith: wtf !? A sério? Eu não ficaria surpreso se eles obter exatamente o que fazer paga.
Steven Evers
2
Muitas vezes vi a abordagem que não podemos dar ao luxo de fazer da maneira certa. Mas podemos nos dar ao luxo de gastar um tempo sem fim consertando a bagunça. Para empresas de consultoria que cobram por hora, qual abordagem é a melhor?
BillThor
1
@jwenting: Para colocar meu comentário anterior em contexto, eu estava defendendo testes de unidade em uma reunião da equipe. Atualmente, apenas dois de nós estão escrevendo testes de unidade (e temos que fazer isso às escondidas). Pessoalmente, não considero os testes de unidade decorações de ouro e diamantes.
Joshua Smith
1
@ shapr: Isso é uma coisa terrível de se ouvir de uma empresa que constrói foguetes e mísseis. >: P
Sr. JavaScript
11
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'.
+1 e nem todos os desenvolvedores recebem ou levam tempo suficiente para aprender ou explorar maneiras melhores. para muitos (gerenciamento e desenvolvedores), é adiado até que se torne um obstáculo que não pode ser ignorado. enquanto isso, as resoluções não são feitas heuristicamente com bastante frequência - é comum que muitas pessoas aceitem uma solução ou recomendação existente. essa prática envolve acaso, aproximação e ignora grande parte do processo de aprendizagem, que é vital para a compreensão. por sua vez, não entender (adversamente) afeta a capacidade de fazer as melhores escolhas.
Justin
6
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.
É verdade que: especialmente a combinação mortal ignorante + arrogante.
Sklivvz
6
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.
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'.)
+1 pela noção de que somos pagos para produzir o código primeiro. Temos a responsabilidade adicional de (subjetivamente) torná-lo sustentável, em segundo lugar. Afinal - não estou pagando mais ao jardineiro para fazer a manutenção do cortador de grama - depende dele. Se ele fizer um bom trabalho e seu equipamento continuar, eu o convido a voltar e lhe dou meus negócios novamente.
Sr. JavaScript
4
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.
Aprendi programação em uma sessão curta (2 a 3 horas). (Na verdade, algumas sessões com idiomas diferentes.) Durante as sessões, um código muito bom foi mostrado, e o motivo para escrever o código como foi explicado. Nenhum dos meus cursos de idiomas "oficiais" chegou perto de introduzir um bom código.
BillThor
"menor resistência" é bastante descritiva. Programadores experientes apenas têm uma idéia melhor do que significa "menor resistência" durante toda a vida útil do aplicativo.
4
(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.
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! ”
Nunca peço aos clientes que aloquem tempo para o teste de unidade, mas considero que faz parte do trabalho. Fazer com que os clientes se comprometam com os testes de unidade apenas incentiva seus clientes a gerenciarem seu trabalho de maneira micro. Quando você conserta seu carro, os mecânicos não perguntam quais ferramentas ele deve usar para fazer o trabalho! O mesmo vale para testes de unidade, você deve julgar o equilíbrio adequado de testes que considera necessário para fazer o trabalho corretamente.
Newtopian
Infelizmente, as melhores técnicas de programação podem ser mais rápidas do que as técnicas que você não pode se dar ao luxo de aperfeiçoar.
BillThor
2
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.
Respostas:
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:
DeMarco e Lister continuam afirmando o mantra a ter em mente antes de pedir às pessoas que mudem:
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 ).
fonte
Péter Török está certo, mas deixou de fora um ponto importante e otimista:
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 .
fonte
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.
fonte
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.
fonte
É 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'.
fonte
Duas causas
Ignorância.
Arrogância.
Como eles podem ser superados?
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.
fonte
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.
fonte
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'.)
fonte
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.
fonte
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 :)
fonte
(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.
fonte
@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! ”
fonte
Duas partes na maior parte da minha experiência:
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.
fonte
À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.
fonte
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.
fonte