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.

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.

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.

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').

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 ¹ ); 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

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

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).

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.

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 ¹
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.

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.

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.

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.

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 .)