Onde minha equipe deve começar a se tornar "moderna"? [fechadas]

106

Sou um desenvolvedor relativamente novo, recém-formado na faculdade. Enquanto estava na faculdade e durante a subsequente procura de emprego, percebi que havia muitas metodologias "modernas" de desenvolvimento de software que estavam faltando na minha formação: teste de unidade, registro em log, normalização de banco de dados, desenvolvimento ágil (versus conceitos ágeis genéricos), estilo de codificação guias, refatoração, revisões de código, nenhum método de documentação padronizado (ou mesmo requisitos), etc.

No geral, eu não vi isso como um problema. Eu esperava que meu primeiro emprego abrisse todas essas idéias e as ensinasse a mim no trabalho. Então, consegui meu primeiro emprego (desenvolvimento web de pilha cheia) em uma grande corporação e percebi que não fazemos nada disso. Na verdade, eu, o menos experiente na equipe, sou o líder que tenta liderar minha equipe com as técnicas de programação "modernas" - pois me preocupo que não fazer isso seja suicídio profissional no futuro.

Primeiro, comecei com o software de log (log4J), mas rapidamente passei a escrever meu próprio guia de estilo, depois o abandonei para o guia de estilo do Google - e depois percebi que nosso desenvolvimento web Java usava controladores frontais escritos à mão; nossa adoção do Spring - mas então percebi que também não tínhamos testes de unidade, mas eu já estava aprendendo o Spring ... e, como você pode ver, ele se torna muito rápido demais, especialmente quando combinado com o trabalho normal de desenvolvimento. Além disso, é difícil para mim me tornar "especialista" o suficiente nessas metodologias para ensinar qualquer outra pessoa nelas sem dedicar muito tempo a uma delas, muito menos a todas.

De todas essas técnicas, que considero "esperadas" no mundo atual de desenvolvimento de software, como as integro a uma equipe como um novo player sem sobrecarregar a mim e à equipe?

Como posso influenciar minha equipe a se tornar mais ágil? é relacionado, mas estou não um desenvolvedor Agile como o autor da questão aqui, e eu estou olhando para um conjunto muito mais amplo de metodologias que Agile.

WannabeCoder
fonte
92
"moderno"? Retire esse chavão "ágil" da sua lista e só posso ver coisas com idade> 20 anos.
Doc Brown
10
Talvez "moderno" no sentido de que a adoção generalizada deles seja moderno, não os gêneses das idéias, então? Também não sou especialista neste assunto, é apenas minha impressão.
WannabeCoder 19/05
41
Garanto que você, testes de unidade, criação de log, normalização de banco de dados, guias de estilo de codificação, inspeções de código (= revisões) têm mais de 30 anos. O termo "refatoração" tem pelo menos 15 anos (Fowler escreveu seu livro em 2000). E não ter documentação formal ou requisitos escritos não é "uma técnica moderna", é IMHO nem mesmo uma "técnica".
Doc Brown
69
@DocBrown admita, você acabou de enviar Marty de volta no tempo para criar todas essas coisas antes de fazer seu comentário.
null
17
Estou mais preocupado que a faculdade dele não esteja ensinando essas coisas desde o início - estou fora da escola há mais de 15 anos e a maioria dessas coisas foi abordada bem cedo. (Menos as chavões, é claro).
Allen Gould

Respostas:

165

Parece-me que você está colocando a carroça diante do cavalo.

Qual é o principal problema que sua equipe está enfrentando e quais tecnologias ajudariam a corrigi-lo?

Por exemplo, se houver muitos erros, principalmente erros do tipo regressão, o teste de unidade pode ser um ponto de partida. Se sua equipe estiver com falta de tempo, talvez uma estrutura possa ajudar (médio a longo prazo). Se as pessoas tiverem dificuldade em ler o código umas das outras, o estilo pode ser útil.

Lembre-se de que o objetivo da empresa em que trabalha é ganhar dinheiro, não criar código.

Jaydee
fonte
35
Bastante. Em parte do ponto de vista pragmático de ter que começar em algum lugar e em parte do ponto de reputação, que se você puder resolver um problema para a equipe, eles poderão estar mais dispostos a ouvir outras sugestões. Lembre-se também de que esta empresa estava ganhando dinheiro antes de você chegar com os métodos existentes; portanto, o que você implementou deve aumentar a capacidade de ganhar dinheiro da empresa.
Jaydee
6
Aceitando isso, mas eu gostaria de receber um follow-up para lidar com os riscos deste profissional (por exemplo, "meu currículo teria mais coisas, mas meu antigo emprego não aceitar a mudança muito bem.")
WannabeCoder
4
@ WannabeCoder - Você precisa começar a usá-lo antes de se tornar proficiente. Você ainda pode colocar o código em produção. Às vezes, codificar é como ser médico. Ainda estamos praticando.
JeffO
5
Ótima resposta. Você só deve implementar essas coisas para resolver problemas, não para fabricar problemas.
Kik
5
@WannabeCoder É importante perceber que nenhuma dessas metodologias foi criada no vácuo. Eles estão se espalhando porque ajudam a resolver problemas . Se você tentar implementá-los e eles não ajudarem a resolver problemas que sua equipe está enfrentando, você não conseguiu nada e possivelmente entendeu e abusou completamente das práticas. Seu foco como desenvolvedor deve estar na solução de problemas em todas as ações que você executa. Procure pequenas vitórias em que a prática dessas práticas apenas um pouco mais melhorará a situação. Isso ajuda a criar um caso para expandi-los.
Jpmc26
77

Java? Moderno?! Você falhou no primeiro obstáculo. Se você quer ser verdadeiramente moderno e evitar o "suicídio profissional", deve escrever o código Rust. É claro que na próxima semana tudo mudará e você terá que aprender algo ainda mais novo para acompanhar!

Ou então, você pode aceitar que nenhuma quantidade de tecnologias, metodologias ou estruturas de palavras-chave ou qualquer outro dia alterará o fato de que você deseja criar produtos de qualidade que funcionem. Não importa se você não usa o Agile se estiver produzindo com êxito a saída correta. Obviamente, se você não estiver, pode querer mudar as coisas, mas as chances são de que nenhuma prática específica conserte os problemas. Eles permanecerão problemas humanos que podem ser corrigidos de várias maneiras diferentes.

Quanto ao suicídio profissional, se você sabe o que está fazendo e é flexível, não precisa de nada do que mencionou. As pessoas continuarão apresentando novas maneiras de fazer o trabalho antigo e você sempre estará atualizando. Ou você pode simplesmente usar as técnicas que sua empresa atual usa independentemente. Quando você muda de empresa, simplesmente aprende e usa as técnicas que eles usam.

Muitas crianças ficam presas a todas as novas ferramentas que poderiam usar, esquecendo que essas ferramentas são inúteis nas mãos de um novato. Aprenda a prática primeiro, uma vez que você é um desenvolvedor experiente, pode começar a "consertar" as práticas de desenvolvimento com "coisas novas e legais", mas, então, esperamos ter percebido que elas não são tão importantes quanto você pensa atualmente, e apenas para ser usado quando eles são realmente necessários.

gbjbaanb
fonte
4
Resposta muito boa (+1), especialmente o último parágrafo. Um livro muito moderno (moderno no sentido em que acho muito relevante hoje) que estou lendo recentemente é o SICP.
Giorgio
1
+1 pela menção da rapidez com que essas palavras-chave e idiomas populares são alterados. Um bom desenvolvedor lançando um bom código supera qualquer metodologia. Faça o que funciona e funciona bem!
WeRelic
2
Enquanto você estiver certo de que eles precisam ser usados ​​corretamente, discordo da noção de que "eles não são tão importantes quanto você pensa atualmente". Ok, claro, isso pode ser verdade em algumas práticas (eu sou um pouco cético em relação aos testes de unidade), mas outras são extremamente valiosas. Tive a chance de começar a fazer muito CI, automação e bom uso do controle de origem, e agora, trabalhando em um projeto onde eles não estão presentes, vejo todos os problemas que queríamos resolver em ação: erros, inconsistências , ninguém sabe qual é o código, onde funciona. Essas práticas fazem uma enorme diferença.
Jpmc26
6
Ninguém diz "não resolva problemas", o problema é quando são introduzidas soluções procurando por problemas a resolver. Eles não são tão importantes quanto muitos pensam, os cultistas de carga acham que as ferramentas são a parte importante, onde na verdade são apenas ferramentas. É o profissional que importa e as ferramentas que funcionam nos lugares certos são as que você escolhe. meu objetivo é nunca escolher uma ferramenta simplesmente porque está na caixa de ferramentas.
Gbjbaanb
2
Um tolo com uma ferramenta ainda é um tolo.
Pete Becker
40

Muitas empresas estão presas assim; você pode até se surpreender ao descobrir que alguns de seus colegas desenvolvedores são autodidatas e se tornaram desenvolvedores sem formação formal. Esses desenvolvedores geralmente são melhores em seus trabalhos, pois eles são os únicos a aprender novas habilidades e ter sucesso, em vez de simplesmente fazer o trabalho. Infelizmente, isso também pode significar que, embora sejam excelentes em programação, eles podem não estar cientes dos benefícios dessas práticas. O fato é que estes são melhores práticas, e não comuns práticas. Os melhores são os que os usam, mas eles não são todos os requisitos para ter sucesso, são simplesmente ferramentas para ajudar a facilitar o sucesso.

Você está absolutamente certo, será impressionante tentar implementar tudo de uma só vez. Você provavelmente se queimará (e talvez sua equipe) tentando fazê-lo, o que desmotivará futuros impulsos para adotar novas metodologias / tecnologias. A melhor coisa a fazer em uma situação como essa é escolher umacoisa (registrar é provavelmente um bom começo, pois você provavelmente tem um caminho difícil pela frente para encontrar bugs sem registrar, e com certeza haverá bugs) e converse com a equipe sobre isso. Você não precisa implementar isso sozinho; você fará muito melhor discutir os prós e contras com a equipe (e seu chefe, que absolutamente DEVE estar de acordo com algo assim) e elaborar um plano para implementá-lo. Terá que ser o mais simples possível (lembre-se, você está dizendo às pessoas que agora elas precisam escrever um código extra , além do que já fazem).

E deixe-me dizer novamente, verifique se o seu chefe compra . Isso é crucial; você provavelmente descobrirá que a velocidade das correções / lançamentos diminui à medida que você implementa coisas novas. O ponto é que você está pagando antecipadamente para economizar; eles devem entender isso e estar do seu lado. Se você não os aceitar, estará travando uma batalha perdida, na melhor das hipóteses, e na pior das hipóteses, eles podem considerá-lo sabotando ativamente a equipe (pergunte-me como eu sei).

Depois de trazer esses itens para a mesa, discuta-os com a equipe, planeje como implementá-los e siga em frente, o segundo, terceiro, oitavo etc. será mais fácil. Além disso, existe um potencial para a equipe e seu chefe ganharem respeito por você, à medida que suas sugestões são implementadas e reconhecidas como agregadoras de valor. Ótimo! Apenas certifique-se de permanecer flexível: você está pressionando contra a inércia aqui e a mudança não é fácil. esteja preparado para fazer lentamente pequenosalterações e verifique se você pode acompanhar o progresso e o valor agregado. Se você implementa o logon em um novo processo e ajuda a economizar horas para encontrar um bug em três semanas, faça uma grande coisa! Certifique-se de que todos saibam que a empresa acabou de economizar US $ XXX, fazendo a coisa certa com antecedência. Por outro lado, se você receber uma resposta negativa ou um prazo apertado, não tente forçar o problema. Deixe a nova mudança deslizar por um momento e circule de volta. Você nunca vencerá tentando forçar a equipe a fazer algo que não deseja, e você pode ter certeza de que a primeira coisa que eles sugerem deixar é o novo trabalho 'extra' (como escrever o registro ou seguir um guia de estilo em vez de apenas 'fazê-lo funcionar').

DrewJordan
fonte
6
Duvido que você tenha entendido muito sobre isso, mas meio que me ressenti com o desprezo de desenvolvedores como eu, sem uma formação em computação universitária. Minha experiência (infelizmente) foi que o ensino universitário tem pouca correlação com a qualidade do desenvolvedor. E até agora na minha carreira, tenho sido um dos que defendem e implementam as melhores práticas. Seu conselho é ótimo.
Djeikyb 21/05
5
Na verdade, eu quis dizer o contrário: o OP ficaria surpreso com quantos bons desenvolvedores existem por aí sem educação formal. Muitas posições de tecnologia foram abertas nos últimos 20/30 anos, preenchidas por pessoas dispostas a aprender em vez de crianças com um diploma. E minhas descobertas espelham as suas: a experiência é sempre melhor que a educação. É por isso que o OP precisa ir devagar ... forçar uma equipe a adotar novas práticas muito rápido fará com que se ressentam dele, e ele não terá a experiência para moderar essas atitudes. Também é importante perceber que algumas equipes nunca usarão essas ferramentas; é quando você consegue um novo emprego.
DrewJordan
1
"Muitas empresas estão presas assim; você pode até se surpreender ao descobrir que alguns de seus colegas 'desenvolvedores' são autodidatas e se tornaram desenvolvedores sem nenhuma formação formal". Esses geralmente acabam sendo os desenvolvedores mais valiosos devido à sua experiência no domínio.
pmf
Certo, eu concordo totalmente. Reescreveu o primeiro parágrafo para parecer menos condescendente. Eu só queria ter certeza de que o OP sabia que uma boa parte da força de trabalho lá fora não tem um histórico formal. Má escolha de palavras da minha parte.
DrewJordan
18

Espero que você não tenha apresentado os problemas aos seus colegas de trabalho como nos fez em sua postagem. Isso seria suicídio profissional.

A primeira questão é que você está tentando ensinar tecnologias e métodos com os quais você ainda não tem experiência para um grupo de programadores que, talvez estejam um pouco desatualizados, mas realizem o trabalho. As possibilidades de sair pela culatra são infinitas e provavelmente trarão muita alegria aos seus colegas de trabalho. É interessante e admirável que você queira melhorar a si mesmo e a seu departamento, mas evite usar termos como "liderança". Atenciosamente, não use essa palavra.

Como uma questão secundária ao exposto, verifique se você está fazendo algum trabalho . Trabalho como programador autônomo há muito tempo e sei como é fácil deixar de lado o trabalho real para explorar estruturas promissoras, tecnologias e afins. Certifique-se de que seu desempenho esteja dentro dos parâmetros esperados (não, ninguém se importa que você gaste 20 horas pesquisando o Spring se o relatório que eles solicitarem não for concluído).

De todas as alternativas acima, evite ser o professor (a menos que esteja relacionado a um campo / tecnologia em que você tenha experiência suficiente). Uma apresentação mais neutra estaria apontando as vantagens de, digamos, testes automatizados e permitindo que a gerência escolhesse quem eles querem pesquisar os prós e contras dessas práticas.

Agora, para apresentar essas "melhores práticas", há duas maneiras de explicá-las à sua equipe:

  • Porque eu digo que elas são as melhores práticas, e isso é suficiente.
  • Porque eles são úteis e ajudam a resolver o problema.

Usando o primeiro argumento, a menos que você seja o chefe ou um membro muito sênior da equipe, é improvável que eles lhe prestem atenção. E "eu li um livro de Knuth que diz isso" ou "os caras do SE dizem que" também não causará nenhuma impressão ("esses caras não trabalham aqui e não sabem realmente o que é bom para essa loja de TI"). "). Eles têm seus métodos, rotinas, procedimentos e coisas "mais ou menos" funcionando, então por que correr o risco e os riscos de mudar?

Para a segunda abordagem funcionar, é preciso perceber que existe um problema . Assim:

  • não faça pressão dia e noite para testes automáticos. Aguarde até que uma atualização interrompa alguns recursos e a equipe precise trabalhar horas extras para corrigi-la e, em seguida, proponha a criação de um sistema de teste automatizado.
  • não peça revisões de código. Aguarde até que Joe tenha uma licença prolongada e seja necessário alterar esse módulo que apenas Joe conhece e aponte para o seu chefe quanto tempo foi perdido apenas tentando entender o código de Joe.

Obviamente, a mudança será lenta e progressiva (mais ainda em uma grande corporação). Se você introduzir a revisão de código e o teste automatizado em cinco anos, parabenize-se pelo trabalho bem-feito. Mas, a menos que haja uma reescrita completa devido a causas externas, esqueça qualquer fantasia para a qual eles mudarão o IS principal, digamos, Spring ( Joel explicou isso muito melhor do que eu jamais pude, mesmo antes de você nascer 1 ); nesse tempo, você poderia, no máximo, colocar o Spring na lista de plataformas suportadas para escrever sistemas não críticos.

Bem-vindo ao mundo da TI corporativa, garoto! :-p

1 : Ok, talvez eu esteja exagerando um pouco, mas não muito.

SJuan76
fonte
1
Discordo principalmente. A única maneira de conseguir alguma mudança em uma equipe é se alguém estiver disposto a fazer a pesquisa e arrastar o resto. É claro que você deve permanecer produtivo, mas se todo mundo ficar com a cabeça baixa, você acaba "um pouco desatualizado, mas você faz o trabalho". E completamente queimado de tédio.
Winkbrace
@winkbrace Eu não afirmo que você não deve tentar melhorar (na verdade, afirmo o contrário). Mas empurrar essas mudanças sem o apoio da gerência e sem a autoridade de alguma antiguidade pode ser bastante difícil e causar alguma resistência; adicione a isso que o OP não é um especialista e pode ter problemas com a implementação real. Seria bom se o OP pudesse se voluntariar para uma equipe de pesquisa / prototipagem para introduzir corretamente as mudanças; mas barrou que ele deveria ter cuidado ao escolher a abordagem correta para promovê-los e ser paciente.
SJuan76
@winkbrace para o tédio, depende da sua personalidade e do que você está procurando em um emprego. É sensato tentar chegar a uma posição de trabalho que o satisfaça, em vez de ir a qualquer lugar e tentar mudar a organização de acordo com seus gostos. E, geralmente, as grandes corporações (exceto os departamentos de P&D) não são o lugar para quem gosta de testar uma nova tecnologia a cada poucos meses.
SJuan76
Está um pouco confuso dizer: "verifique se você está realmente trabalhando". Claro que você deve fazer o trabalho, mas também precisa pensar a longo prazo e, todos os dias, deve melhorar. Levei cinco meses para que nosso gerente entrasse no fato de que os testes de unidade ajudam mesmo quando estamos tentando codificar "rapidamente". Mas eu precisava levar 10 minutos aqui e ali a cada poucos dias para que isso acontecesse.
Rudolf Olah
@omouse Eu estava apenas apontando um risco que me atingiu às vezes, ao fazer pesquisas. Certamente não vejo esse risco na situação que você descreve, mas a forma como o OP descreve sua pesquisa ("primeiro comecei com ... depois me mudei rapidamente ...") me fez acrescentar essa cautela. Observe que eu não afirmo que o OP não está fazendo o trabalho designado adequadamente (isso é algo que eu simplesmente não sei, e esse é o emprego do chefe dele); eu apenas o aviso para garantir que ele não se empolgue demais. .
SJuan76
12

Você deve começar com o livro Trabalhando Efetivamente com o Código Legado, de Michael Feathers. Desde a introdução do livro, "trata-se de pegar um sistema confuso, opaco e complicado e, lentamente, gradualmente, peça por peça, passo a passo, transformando-o em um sistema simples, bem estruturado e bem projetado". Ele começa principalmente com testes automatizados, para que você possa refatorar com segurança (você saberá se quebrar alguma coisa), e ele inclui muitas estratégias para incluir código difícil em testes automatizados. Isso é útil para todos os projetos que ainda estão em desenvolvimento. Depois de estabelecer uma ordem básica, você poderá ver de que outras tecnologias modernas seu projeto realmente poderia se beneficiar - mas não presuma que você precisa de todas elas.

Se você deseja aprender uma nova estrutura (ou algo assim) por razões profissionais, e não porque o seu projeto atual realmente precisa, então você deve usá-lo em algum projeto pessoal (no seu próprio tempo).

user3067860
fonte
Eu concordo com os tópicos em Trabalhando efetivamente com o código herdado, mas não é muito compacto. Tome-o como referência e olhe os capítulos em vez de esperar lê-lo como um romance.
Lukas
10

Fonte de controle.

Você não mencionou, espero que já esteja no lugar, mas, caso não esteja, comece por aí.

O controle de fonte tem o maior retorno possível, exceto em raras circunstâncias patologicamente, necessitando de algo mais.

E você pode começar sozinho se ninguém comprar inicialmente.

Emilio M Bumachar
fonte
1
O maior retorno do investimento é mais como alguns ASSERTs nos lugares certos.
Peter Mortensen
@PeterMortensen True, mas apenas se você souber quais são os lugares certos.
Emilio M Bumachar
Você chegou antes de mim. Não importa em que direção o OP leve sua equipe, chegar lá com o Git será muito mais fácil e produtivo do que sem ele.
dotancohen
6

Uma resposta direta

Outras respostas trazem bons 'meta-pontos' sobre a adoção de melhores práticas, mas, apenas para fornecer orientações diretamente relevantes, aqui está uma ordenação aproximada das melhores práticas que eu sugiro que sua equipe (ou qualquer outra equipe) adote (primeiro):

  1. Fonte de controle
  2. Rastreamento de problemas (gerenciamento de projetos e tarefas)
  3. Construções automatizadas 1
  4. Implantações automatizadas

1 Uma prática muito relacionada é automatizar, ou pelo menos documentar , a configuração do ambiente de construção e desenvolvimento de cada aplicativo ou projeto de software que você está desenvolvendo ou mantendo. É muito menos útil, porque você (espero) está fazendo isso com pouca frequência ou raramente.

Todo o resto

Você menciona várias outras boas práticas - "teste de unidade, registro em log, normalização de banco de dados, ... refatoração, ... documentação" - mas essas são práticas que podem e devem ser adotadas de forma gradual e incremental. Nenhum deles precisam ser adotadas tudo de uma vez e você provavelmente melhor adotá-los em tudo , adotando-os cuidadosamente e conscientemente.

As quatro práticas listadas acima também tornarão a adoção e a experimentação de novas práticas o mais fácil possível. Por exemplo, o teste de unidade pode ser incorporado às suas compilações automatizadas e a documentação pode ser publicada como parte de suas implantações automatizadas.

Algumas das outras práticas mencionadas - "desenvolvimento ágil, ... guias de estilo de codificação, ... revisões de código, ... métodos de documentação padronizados" e estruturas (por exemplo, Spring) - são realmente opcionais ou de valor duvidoso. E isso é verdade para muitas práticas (mais?) Possíveis que você descobrirá ou encontrará.

O desenvolvimento ágil não é obviamente superior a qualquer outra metodologia usada. E muitas pessoas (inclusive eu) tiveram experiências horríveis com isso. Mas muitas pessoas realmente gostam (ou adoram) também. Tente!

Os guias de estilo de codificação podem ser úteis, especialmente para projetos grandes ou em equipes grandes, mas também é muito trabalhoso aplicar essas diretrizes e esse pode não ser o melhor uso para quem está fazendo isso.

As revisões de código também podem ser muito úteis - você solicitou a seus colegas que revisassem seu código? Lembre-se de que você não precisa de um processo formal para adotar boas práticas!

A documentação é ótima - você tem alguma? Se assim for, bom para você! Você está enfrentando muito trabalho extra que poderia ser evitado com a (mais) documentação "padronizada"? Se você é, então provavelmente é algo que vale a pena fazer. No entanto, digamos que se o seu software estiver sendo usado por um pequeno grupo de pessoas, talvez você não precise de nenhuma documentação. (Ou você pode incorporar diretamente a documentação em seu software. Essa é sempre a minha preferência.)

Estruturas são ... uma espada de dois gumes (muito afiada). Uma solução bem encapsulada e bem mantida para um recurso não essencial do seu software é ótima ... até que não seja. Não sei ao certo o que são "controladores frontais escritos à mão", mas não há explicação óbvia para o motivo de serem inferiores ao código que utiliza o Spring. Você já pensou em encapsular a lógica comum em todos esses controladores em sua própria estrutura interna? A adoção do Spring e a reescrita de todo o código existente podem ser um imenso projeto de refatoração (ou, mais provavelmente, reescrita) e essa pode não ser a melhor alteração que você pode fazer no seu código . Claro que você não deve escrever todo o software que você usa - estruturas (e bibliotecas) são ótimas!Mas talvez você não precise usar o Spring (ou uma alternativa) para escrever ótimos (ou bons) aplicativos da web.

Kenny Evitt
fonte
Eu colocaria testes de regressão automatizados lá em cima, com criação e implantação automatizadas. Ele também tem a vantagem de poder trabalhar de forma incremental.
Sdenham 21/05
O teste de unidade deve ser o primeiro, comece com a execução manual sempre localmente (ou em cada check-out / check-in) e peça ao restante da equipe que faça testes de regressão automatizados. Realmente existem desenvolvedores que têm medo de executar testes constantemente por algum motivo.
Rudolf Olah
5

Olhe ao redor da equipe da qual você faz parte. Você pode ver alguma evidência de que o desenvolvimento orientado a testes ou a normalização do banco de dados melhorará a qualidade do software que você está escrevendo ou tornará as pessoas mais produtivas?

Você já tentou falar com um dos supervisores de desenvolvimento ou com o chefe de desenvolvimento? Um bate-papo realmente informal seria um bom começo. O que faz você pensar que as pessoas acima de você não tiveram as mesmas idéias, mas não podem / não as implementam porque a empresa não permite?

Acho que liderar pelo exemplo é um bom caminho a percorrer. As pessoas são muito menos resistentes se alguém já fez o trabalho e pode mostrar a elas como replicá-lo. Introduzir TDD em um projeto no qual você está trabalhando. Peça para fazer uma apresentação para o resto da equipe, ou mesmo para algumas outras, e mostre a eles o que você fez. O que o @DrewJordan disse sobre a compra do chefe é mais importante do que você provavelmente imagina.

markp3rry
fonte
5

Encontre uma falha. Corrija uma falha. Mostre a correção.

Vamos considerar a normalização * primeiro. E, de fato, eu sugiro que você faça primeiro, porque a falta de normalização provavelmente resultará em dados de buggy reais que não poderiam existir de outra forma, enquanto o restante são casos em que as práticas recomendadas provavelmente poderiam ajudar, mas é mais difícil dizer "Bug A foi causado por não seguir a política X ". Se você possui um banco de dados que não é normalizado, existe um local em que os dados podem ser inconsistentes.

É uma boa aposta que você seja capaz de encontrar um caso real de dados inconsistentes. Agora você encontrou duas coisas:

  1. Um erro nos seus dados.

  2. Um erro nos seus esquemas de banco de dados.

Você realmente sabia primeiro sobre o segundo bug, mas o primeiro é mais facilmente demonstrável e também algo que está causando um problema real, não algo que teoricamente poderia.

Infelizmente, uma das reais razões para resistir à normalização do banco de dados desnormalizado é que a questão do que fazer com esses dados de bugs nem sempre é fácil, mas você encontrou um bug real.

(Lembre-se, porém, de que existem razões para às vezes desnormalizar alguns dados de propósito. Não confunda a quebra da regra por ignorância da regra; se você normalizar uma tabela que é deliberadamente desnormalizada para velocidade de pesquisa, você ganha Mesmo assim, a desnormalização de ser um problema é algo que deve ser feito proceduralmente; portanto, se a tabela desnormalizada não for criada automaticamente com base no conteúdo de tabelas normalizadas, ainda haverá progresso a ser feito).

De resto, apresente-os quando eles ajudarem a curto prazo, para depois construí-los a longo prazo. Por exemplo, se você receber um pequeno pedaço de código para criar, escreva um teste de unidade para ele. Melhor ainda, se você receber um bug para corrigir, escreva um teste de unidade que falhe por causa do bug e, depois de corrigi-lo, mencione o fato de que ele passa quando você fecha os bugs (ou envie um e-mail dizendo que foi corrigido , como queiras).

* Aliás, não é muito moderno. A razão é chamado de normalização e não normalizar ou qualquer outra coisa, é que no momento em que era uma piada tópica para furar -ization no final de coisas para tirar sarro do nome de Richard Nixon Vietnamization política.

Jon Hanna
fonte
4

Vou contra a corrente e dizer: encontre um novo emprego depois de passar algum tempo neste aqui para construir um pouco o seu currículo. Apontar por mais ou menos um ano. Embora muitas coisas sejam "chavões", questões como a completa falta de teste de unidade são intratáveis ​​para um único desenvolvedor, e as chances são de que, se os programadores que trabalham lá não desejam, nunca conseguirá comprar e pode comprometer sua posição. na empresa, fazendo as pessoas pensarem em você como um estúpido. Você precisa estar em um lugar onde possa obter orientação, sem tentar empurrar a cultura para a competência básica.

asthasr
fonte
3
Foi exatamente o que eu fiz. Houve apenas uma vez (entre ~ 5 tentativas em vários locais) quando introduzi com êxito algumas novas "boas práticas" ou fiz uma mudança significativa nas práticas existentes. Foi quando a equipe estava renovada e iniciamos a maioria dos projetos do zero. . Em todas as outras vezes, as boas práticas foram introduzidas do topo (líderes da equipe) ou apenas falharam porque ninguém mais participou. Acredito que tudo se resume à capacidade de forçar sua decisão sendo um líder / chefe.
Script
1

Existem muitas propostas para melhorar o paradigma de programação . As palavras-chave mais quentes agora parecem programação ágil e orientadas a objetos. Ou são eles? Ambos desapareceram substancialmente em comparação com o que eram apenas cinco anos atrás.

Você pode estar bastante confiante de que qualquer metodologia adotada está tentando obter o mesmo resultado final: ajude os engenheiros a produzir economicamente um produto final que seja bom o suficiente.

Há um paradigma que foi controversamente introduzido na década de 1960: programação estruturada : use apenas "alto nível" constrói como while, for, repeat, if/ then/ else, switch/ casedeclarações em vez do muito utilizada gotodeclaração que tinha sido aceite por padrão. Há ainda debates sobre se gototem qualquer uso legítimo de todo.

Aceito que minimizar o uso de gotoé uma coisa boa, mas como todas as coisas boas, é possível ir longe demais.

Você menciona agilemetodologias como algo positivo. Eu estive em uma equipe de desenvolvimento por cerca de seis meses que intencionalmente seguiu um regime ágil prescrito. Eu achei que era exatamente como metodologias de gerenciamento de projetos esclarecidas de décadas atrás, exceto que tudo foi renomeado. Talvez reorganizando e revendendo idéias para comunicar alguém ganha a vida e as empresas possam se sentir bem em "ver" as novas roupas do imperador .

A lição mais valiosa do Agile, conhecida há muito tempo, é que a flexibilidade para encontrar um caminho melhor para o produto final é uma coisa boa e a capacidade de encontrar esse caminho pode vir de qualquer pessoa - não apenas da alta gerência.


De uma escrita do líder anti-goto Edsger Dijkstra:

A arte da programação é a arte de organizar a complexidade, de dominar a multidão e evitar o caos bastardo da maneira mais eficaz possível.

- Dijkstra, em: Dahl, Dijkstra e Hoare 1972, pág. 6. (veja a página 6 aqui .)

Wallyk
fonte