Onde minha equipe deveria começar a se tornar “moderna”? [fechadas]

106

Sou um desenvolvedor relativamente novo, recém-saído da faculdade. Enquanto cursava a faculdade e durante a procura de emprego subsequente, percebi que havia muitas metodologias "modernas" de desenvolvimento de software que faltavam à minha formação: teste unitário, registro, normalização de banco de dados, desenvolvimento ágil (conceitos genéricos ágeis), estilo de codificação. guias, refatoração, revisões de código, métodos de documentação padronizados (ou mesmo requisitos), etc.

No geral, não percebi que isso é um problema. Eu esperava que meu primeiro emprego abrangesse todas essas idéias e as ensinasse para mim no trabalho. Então eu consegui meu primeiro emprego (full web development) em uma grande corporação e percebi que não fazemos nenhuma dessas coisas. Na verdade, eu, o menos experiente da equipe, sou aquele que está liderando as tentativas de trazer minha equipe à velocidade das técnicas de programação "modernas" - já que me preocupo com o fato de que não fazê-lo é um suicídio profissional.

Primeiro comecei com o software de logging (log4J), mas depois mudei rapidamente para escrever meu próprio guia de estilo, depois o abandonei para o guia de estilo do Google - e então percebi que nosso desenvolvimento Java na Web usava controles frontais escritos à mão, Eu forcei a adoção da Spring - mas depois percebi que não tínhamos testes unitários também, mas eu já estava aprendendo o Spring ... e, como você pode ver, torna-se muito rápido, especialmente quando combinado com o trabalho normal de desenvolvimento. Além disso, é difícil para mim tornar-me "especialista" o bastante nessas metodologias para ensinar qualquer outra pessoa nelas sem dedicar muito tempo a uma única delas, muito menos a todas elas.

De todas essas técnicas, que vejo como "esperadas" no mundo de desenvolvimento de software de hoje, como as integro a uma equipe como um novo jogador sem sobrecarregar a mim mesmo e a equipe?

Como posso influenciar minha equipe para tornar-se mais ágil? está relacionado, mas eu sou não um desenvolvedor Ágil como o questionador aqui, e estou olhando para um conjunto muito mais amplo de metodologias do que o Ágil.

    
por WannabeCoder 19.05.2015 / 14:51
fonte

11 respostas

164

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.

    
por 19.05.2015 / 15:00
fonte
75

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.

    
por 19.05.2015 / 15:03
fonte
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 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').

    
por 19.05.2015 / 15:52
fonte
17

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

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

    
por 19.05.2015 / 19:26
fonte
12

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

    
por 19.05.2015 / 18:41
fonte
10

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.

    
por 20.05.2015 / 18:49
fonte
6

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

  1. Controle de origem
  2. Acompanhamento de problemas (gerenciamento de projetos e tarefas)
  3. Construções automatizadas 1
  4. Implementações automatizadas

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

Tudo o resto

Você menciona várias outras boas práticas - "teste de unidade, registro, normalização de banco de dados, ... refatoração, ... documentação" - mas todas essas são práticas que podem e devem ser adotadas gradualmente e incrementalmente. Nenhum deles precisa ser adotado de uma só vez e você provavelmente os adotará melhor adotando-os com cuidado e atenção.

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 em suas construções automáticas e a documentação pode ser publicada como parte de suas implantações automatizadas.

Algumas das outras práticas que você menciona - "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 sobre muitas práticas possíveis que você descobrirá ou encontrará.

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

Guias de estilo de codificação podem ser úteis, especialmente para grandes projetos, ou em grandes equipes, mas também é muito trabalhoso impor essas diretrizes, o que pode não ser o melhor uso do tempo de quem quer que esteja fazendo isso.

As revisões de código também podem ser muito úteis: você solicitou a seus colegas de trabalho que revisassem seu código? Tenha em mente 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 documentação (mais) "padronizada"? Se você é, então provavelmente é algo que vale a pena fazer. No entanto, diga se o seu software está sendo usado por um pequeno grupo de pessoas, você pode não precisar de qualquer qualquer documentação. (Ou você poderia 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 de seu software é ótima ... até que não seja. Eu não tenho certeza do que "controladores frontais escritos à mão" são exatamente, mas não há uma explicação óbvia de por que eles são inferiores ao código que aproveita o Spring. Você já pensou em encapsular a lógica comum em todos esses controladores em sua própria estrutura interna? Adotar o Spring, e reescrever todo o seu código existente, pode ser um imenso projeto de refatoração (ou, mais provavelmente, de reescrever) e essa pode não ser a melhor mudança que você poderia fazer no seu código . É claro que você não deve escrever todos do software que você usa - frameworks (e bibliotecas) são ótimos! Mas talvez não seja necessário usar o Spring (ou uma alternativa) para criar ótimos (ou bons) aplicativos da Web.

    
por 21.05.2015 / 18:02
fonte
5

Olhe em volta 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 sobre isso, ou o chefe de desenvolvimento? Uma conversa realmente informal seria um bom começo. O que faz você pensar que as pessoas acima de você não tiveram as mesmas ideias, mas não podem implementá-las porque a empresa não permite isso?

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 como replicá-lo. Introduza o TDD em um projeto em que você está trabalhando. Peça para fazer uma apresentação para o restante da equipe, ou mesmo para alguns outros, 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.

    
por 19.05.2015 / 17:23
fonte
5

Encontre uma falha. Corrigir uma falha Mostrar a correção.

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

É uma boa aposta que você será capaz de encontrar um caso real de dados inconsistentes. Você encontrou agora duas coisas:

  1. Um erro nos seus dados.

  2. Um erro no seu esquema de banco de dados.

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

Infelizmente, um dos motivos reais para resistir à normalização do banco de dados desordenado é que a questão sobre o que fazer com esses dados com bugs nem sempre é fácil, mas você terá encontrado um bug real.

(Esteja ciente de que existem razões pelas quais alguém pode, algumas vezes, desnormalizar alguns dados de propósito. Não confunda a quebra de conhecimento da regra da ignorância da regra; se você normalizar uma tabela que é deliberadamente desclassificada para velocidade de pesquisa , você não vai ganhar nenhum elogio, mas aqui mesmo, desnormalizar sendo carregado é algo que deve ser feito proceduralmente, então se a tabela desnormalizada não é criada automaticamente com base no conteúdo das tabelas normalizadas, ainda há progresso a ser feito. / p>

Para o resto, apresente-os quando eles ajudarem a curto prazo, para depois construí-los a longo prazo. Por exemplo. Se você receber um pequeno código para criar, escreva um teste de unidade para ele. Melhor ainda, se você receber um bug para consertar, escreva um teste de unidade que falhe por causa do bug e, quando tiver corrigido o erro, mencione o fato de ele passar quando você fechar os bugs (ou enviar um e-mail dizendo que está consertado) ou o que quer que seja).

* Aliás, não é muito moderno. A razão pela qual é chamada de normalização e não normalização ou qualquer outra coisa, é que na época era uma piada tópica colocar -ization no fim das coisas para tirar sarro do nome da política de Vietnamização do Richard Nixon.

    
por 20.05.2015 / 15:16
fonte
4

Eu vou na contramão e digo: encontre um novo emprego depois de passar um tempo nessa para construir um pouco seu currículo. Apontar por um ano ou mais. Embora muitas coisas sejam "chavões", questões como a falta completa de testes unitários são intratáveis para um único desenvolvedor, e as chances são de que, se os programadores que trabalham lá não desejarem testá-lo, você nunca conseguirá comprar e poderá comprometer sua posição. na empresa, fazendo as pessoas pensarem em você como um fanfarrão. Você precisa estar em um lugar onde você pode obter orientação, não tentando empurrar a cultura para a competência básica.

    
por 20.05.2015 / 17:35
fonte
1

Houve muitas propostas para melhorar o paradigma de programação . As palavras-chave mais quentes parecem agora ser de programação ágil e orientada a objetos. Ou são eles? Ambos se desvaneceram substancialmente em comparação com o que eram há apenas cinco anos.

Você pode ter certeza de que qualquer metodologia implementada está tentando alcançar o mesmo resultado final: ajudar os engenheiros a produzir economicamente um produto final que seja bom o suficiente.

Existe um paradigma que foi introduzido de forma controversa nos anos 60: programação estruturada : use apenas construções de "alto nível" como while , for , repeat , if / then / else , switch / case instruções em vez da instrução goto muito usada que foi aceita por padrão. Existem ainda debates sobre se goto tem algum uso legítimo.

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

Você mencionou agile metodologias como algo positivo. Eu estava 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 é renomeado. Talvez por re-agrupar e revender idéias para se comunicar alguém ganha a vida e as empresas podem se sentir bem sobre "ver" o roupas novas do imperador .

A lição mais valiosa da Agile, que era conhecida há muito tempo, é que a flexibilidade para encontrar um caminho melhor para o produto acabado é 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:

The art of programming is the art of organizing complexity, of mastering multitude and avoiding its bastard chaos as effectively as possible.

—Dijkstra, in: Dahl, Dijkstra & Hoare 1972, pg. 6. (see page 6 here.)

    
por 24.05.2015 / 05:05
fonte