Parece-me que você está colocando o carrinho antes do cavalo.

Qual é o maior problema que sua equipe está enfrentando e quais tecnologias ajudariam a resolvê-lo?

Por exemplo, se houver muitos bugs, especialmente bugs do tipo regressão, o teste unitário pode ser um ponto inicial. Se a sua equipe não tiver tempo, talvez uma estrutura possa ajudar (de médio a longo prazo). Se as pessoas tiverem dificuldade em ler os códigos uns dos outros, o estilo pode ser útil.

Lembre-se de que o objetivo do negócio para o qual você trabalha é ganhar dinheiro, não fazer código.

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

Ou, você poderia aceitar que nenhuma quantidade de tecnologias, metodologias ou estruturas de palavras-chave ou qualquer outro du jour mudará o fato de que você deseja criar produtos de qualidade que funcionem. Não importa se você não usa ágil se estiver produzindo com sucesso a saída correta. Claro, se você não for, então você pode querer mudar as coisas, mas as chances são de que nenhuma prática particular 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, então não precisa de nenhuma das coisas que mencionou. As pessoas continuarão a criar novas maneiras de fazer o trabalho antigo e você sempre estará se atualizando. Ou você pode simplesmente usar as técnicas que sua empresa atual usa independentemente. Quando você muda sua empresa, você simplesmente aprende e usa as técnicas que eles usam.

Muitas crianças ficam presas em todas as novas ferramentas que podem usar, esquecendo-se de 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, você pode começar a "consertar" as práticas de desenvolvimento com "coisas novas e legais", mas você perceberá 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 nenhuma formação formal. Esses desenvolvedores geralmente são melhores em seus trabalhos, pois serão aqueles que são orientados a aprender novas habilidades e a ter sucesso, em vez de simplesmente fazer o trabalho. Infelizmente, isso também pode significar que, embora sejam excelentes em programação, podem não estar cientes dos benefícios dessas práticas. O fato é que essas são as práticas melhores , e não práticas comuns . O melhor usa-os, mas eles não são necessários para ter sucesso, eles são simplesmente ferramentas para ajudar a tornar o sucesso mais fácil.

Você está absolutamente certo, será difícil tentar implementar tudo de uma vez. Você provavelmente vai se queimar (e talvez sua equipe) tentando fazer isso, o que vai desmotivar futuros esforços para adotar novas metodologias / tecnologias. A melhor coisa a fazer em uma situação como esta é pegar uma coisa uma (o log provavelmente é um bom começo, já que você provavelmente tem um caminho difícil à frente para encontrar bugs sem logging, e com certeza haverá bugs) e fale com a equipe sobre isso. Você não precisa implementar sozinho isso; você se sairá muito melhor discutindo os prós e contras com a equipe (e seu chefe, que absolutamente DEVEM estar a bordo com algo assim) e elaborando um plano para implementá-lo. Terá que ser o mais simples possível (lembre-se, você está dizendo às pessoas que elas agora têm que escrever código extra além do que já fazem).

E deixe-me dizer novamente, certifique-se de que seu chefe compre em . Isso é crucial; você provavelmente descobrirá que a velocidade das correções / versões diminui à medida que você implementa coisas novas. O ponto é que você está pagando adiantado para economizar na linha; eles devem entender isso e estar do seu lado. Se você não os coloca a bordo, você está lutando uma batalha perdida na melhor das hipóteses, e na pior das hipóteses eles podem considerar você ativamente sabotando o time (pergunte-me como eu sei).

Depois de trazer esses itens para a mesa, discuti-los com a equipe, planejar como implementá-los e seguir adiante, o segundo, terceiro, oitavo, etc. será mais fácil. Não só isso, há um potencial para a equipe e seu chefe para ganhar respeito para você como suas sugestões são implementadas e reconhecidas como agregação de valor. Ótimo! Apenas certifique-se de que você permaneça flexível: você está pressionando contra a inércia aqui, e a mudança não é fácil. Esteja preparado para fazer lentamente alterações pequenas e certifique-se de que pode acompanhar o progresso e o valor ganho. Se você implementar o registro em um novo processo e ajudar você a economizar horas para encontrar um bug em três semanas, faça um grande negócio! Certifique-se de que todos saibam que a empresa acabou de economizar $ XXX ao fazer a coisa certa antes do tempo. Por outro lado, se você receber um pushback ou tiver 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 vai ganhar tentando forçar a equipe a fazer algo que eles não querem fazer, e você pode ter certeza que a primeira coisa que eles vão sugerir é o novo trabalho 'extra' (como escrever logging ou seguir um guia de estilo em vez de apenas 'fazer funcionar').

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

A primeira questão é que você está tentando ensinar tecnologias e métodos que até mesmo você não tem experiência com um grupo de programadores que, talvez estejam um pouco desatualizados, mas obtenham o trabalho "concluído". As possibilidades desse backfiring são infinitas, e provavelmente trarão muita alegria para seus colegas de trabalho. É interessante e admirável que você queira melhorar a si mesmo e ao seu departamento, mas evite usar termos como "liderar". Sinceramente, não use essa palavra.

Como uma questão secundária, verifique se você está fazendo algum trabalho . Tenho trabalhado como programador autônomo e solitário por muito tempo, e sei como é fácil separar o trabalho real para explorar estruturas promissoras, tecnologias e afins. Assegure-se de que seu desempenho está dentro dos parâmetros esperados (não, ninguém se importa que você gaste 20 horas pesquisando Spring se o relatório que eles pediram não estiver pronto).

De todos os itens acima, evite ser o professor (a menos que esteja relacionado a um campo / técnico no qual você tenha experiência suficiente). Uma apresentação mais neutra seria apontar as vantagens, digamos, dos testes automatizados, e deixar a gerência escolher 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 para sua equipe:

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

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

Para que a segunda abordagem funcione, deve haver a percepção de que existe um problema . Então:

• não vá empurrar dia e noite para testes automáticos. Aguarde até que uma atualização quebre alguns recursos, e a equipe precise fazer hora extra para corrigi-la e depois proponha a criação de um sistema de teste automatizado.
• não solicite comentários de código. Aguarde até que Joe esteja em licença prolongada e haja a necessidade de alterar o módulo que apenas Joe conhece e aponte para seu chefe quanto tempo foi perdido tentando entender o código de Joe.

É claro que a mudança será lenta e progressiva (mais ainda em uma grande corporação). Se você introduzir a revisão de código e testes automatizados em cinco anos, você deve se congratular com um trabalho bem feito. Mas, a menos que haja uma reescrita completa devido a causas externas, esqueça qualquer fantasia de que eles mudem o núcleo para, digamos, Spring ( Joel explicou dessa maneira melhor do que eu jamais poderia, mesmo antes de você nascer ¹ ); Nesse período, você poderia, no máximo, obter o Spring na lista de plataformas suportadas para gravar sistemas não críticos.

Bem-vindo ao mundo da TI corporativa, rapaz! :-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 herdado de Michael Feathers. A partir da introdução do livro, "Trata-se de um sistema confuso, opaco e complicado e, lenta e gradualmente, passo a passo, 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 você quebrar alguma coisa) e ele inclui muitas estratégias para trazer código difícil em testes automatizados. Isso é útil para todos os projetos que ainda estão em desenvolvimento. Uma vez que você tenha alguma ordem básica no lugar, você pode ver de que outras tecnologias modernas seu projeto realmente pode se beneficiar - mas não assuma que você precisa de todas elas.

Se você quiser aprender um novo framework (ou algo assim) por razões profissionais, e não porque seu projeto atual realmente precisa dele, então você deve usá-lo em algum projeto pessoal (em seu próprio tempo).

Controle de origem.

Você não mencionou, esperançosamente porque já está no lugar, mas, caso não esteja, comece por aí.

O controle da fonte tem o maior custo-benefício, exceto em raras circunstâncias patologicamente necessitadas de outra coisa.

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

Uma resposta direta

Outras respostas são bons "meta-pontos" sobre a adoção de melhores práticas, mas, para dar a você uma orientação diretamente relevante, aqui está uma ordem aproximada das melhores práticas que eu sugeriria à sua equipe (ou qualquer equipe) adotar (primeiro):