Mais notíciasDesenvolvedores de software criaram a ideia de um “antipadrão” para alertar outros desenvolvedores sobre o que não fazer. Esses antipadrões se tornaram tão úteis que são transmitidos entre os desenvolvedores com tanta reverência quanto os padrões de design funcional que descrevem como alguém deve fazer as coisas.
O gerenciamento de projetos de software tem seus próprios “antipadrões”: práticas aparentemente sólidas que a experiência duramente conquistada sugere que não deveríamos realmente fazer. Alguns antipadrões nos ajudam a evitar certas coisas. Mas o que eles realmente pedem é moderação.
A seguir estão 11 antipadrões de gerenciamento de desenvolvimento de software. Pense neles como hábitos aparentemente sadios a serem evitados ao lidar com os desenvolvedores.
1 - Não há espaço para individualismo no trabalho em equipe
Robert Frost gostava de dizer que boas cercas fazem bons vizinhos. Precisamos dos nossos próprios espaços e o mesmo é verdadeiro para os desenvolvedores. Há sempre a tentação de adicionar mais desenvolvedores a uma equipe, na esperança de que muitas mãos fiquem leves. Mas muitas vezes os desenvolvedores acabam em conflito uns com os outros, lutando para atualizar as mesmas seções de código. De repente, as revisões de código são empilhadas e ninguém quer passar e mesclar o código linha por linha.
A arquitetura de microsserviços tem muitas falhas, mas pode dar espaço para os desenvolvedores respirarem. Eles podem trabalhar de forma independente em seus próprios cantos do código. E podem desenvolver seu código, criar testes e avançar sem sincronizar etapas, respeitando apenas as diretrizes gerais. Dividir desenvolvedores e deixá-los trabalhar em seu próprio espaço faz toda a diferença.
2 - Dividir para conquistar
O único problema em manter os desenvolvedores separados é quando eles finalmente precisam fazer com que as partes de código funcionem em conjunto. De repente, uma API oferece strings, enquanto a outra quer inteiros. Ou talvez uma equipe espere dados em linhas enquanto a outra espera em colunas. Há tantas maneiras de um esboço rápido no quadro branco ser interpretado... E, claro, todos os testes são aprovados porque cada grupo escreveu os testes para seu próprio código usando sua própria visão.
A solução é mais controle central e testes mais centralizados. Algumas equipes designam alguns desenvolvedores para monitorar constantemente a integração para garantir que todas as partes possam ser reunidas da maneira mais suave possível. Conseguir que as peças funcionem juntas é o mesmo que construir as peças. Manter os desenvolvedores se movendo na mesma direção é um trabalho em si.
3 - Siga sua visão
Se eu tivesse um dólar para cada momento em que imaginava uma linda pilha de código à distância, bem, eu seria capaz de contratar uma equipe de desenvolvedores para criá-lo. Todo desenvolvedor conhece a explosão do gênio criativo que oferece toda a visão da pilha inteira. Todo desenvolvedor também sabe que isto é seguido por um período de super poderes imaginados, onde cada característica parece que pode ser combinada em apenas algumas linhas de código. Quantas vezes nós simplesmente acionamos o editor de código e começamos a correr em direção a esta miragem?
É por isso que precisamos de uma metodologia - algo que nos force a deixar de lado o glorioso sonho e a esboçar o plano em detalhes. O planejamento pode ser uma tarefa real, mas é mais rápido que a depuração do código.
4 - Paute-se pela escrita
Para cada metodologia, há livros, conferências e consultores prontos a dizer o que devemos fazer e o que devemos, a todo custo, evitar. Eles são muito bons em entregar essas regras com autoridade absoluta.
O problema é que nada se ajusta perfeitamente às suas rubricas. Você pode escrever especificações por meses, mas sempre descobrirá algum novo ângulo ou problema quando estiver quase terminando de implementá-las. Você pode tentar se manter flexível e ágil, mas dificilmente consegue antecipar algo que seria muito mais fácil de corrigir durante o estágio de planejamento. Há sempre uma pegadinha.
Os melhores gerentes escolhem uma metodologia e, em seguida, encontram uma maneira de antecipar onde a metodologia falhará. Nenhum de nós pode fazer isso o tempo todo, mas quando fazemos isso, parece que encontramos um caminho.
5 - Confie no processo
Enquanto o desenvolvimento de software tem seus momentos de magia em que tudo se une no tempo, não acompanhar os detalhes por medo de mexer com o processo criativo pode ter consequências. Há quanto tempo a nova instalação do banco de dados é feita? Quando essa equipe prometeu reprojetar a API de logon único? Quantas pessoas estão trabalhando no check-in de código para refatorar a sobra de dívida técnica do último sprint?
As pessoas responsáveis ??sempre têm uma longa lista de obstáculos e problemas que a atrasaram. O desafio da liderança é encontrar uma maneira elegante de observar o que está acontecendo e acompanhar com detalhes suficientes para tomar decisões inteligentes. As métricas de desenvolvimento de software podem ser bastante imprecisas, mas, desde que você não espere muito, elas permitirão que você siga quem está trabalhando no quê.
6 - Você não pode administrar o que você não mede
É um velho slogan que soa fresco hoje, graças ao crescente foco na importância dos dados. E não é que as métricas de software sejam ruins; eles simplesmente não fazem um bom trabalho de capturar tudo o que está acontecendo. Há muito tempo, os gerentes tentaram contar o número de linhas de código que os desenvolvedores criaram e os desenvolvedores rapidamente descobriram como adicionar comentários extras ou outras informações não-funcionais para multiplicar sua performance.
Atualmente, alguns gerentes atribuem “pontos” abstratos a tarefas e, em seguida, somam os pontos ao final de um trimestre ou ano. Mas descobrir o número certo de pontos é quase tão difícil quanto resolver o problema em primeiro lugar. As equipes mais agressivas pedem aos desenvolvedores que ofereçam trabalho em pontos, colocando-os uns contra os outros na busca de uma avaliação mais precisa. Isso não ajuda a camaradagem entre os membros da equipe ou a colaboração.
O maior perigo é que os desenvolvedores evitem os tickets mais difíceis ou imprevisíveis, sabendo que são apenas pântanos que não os recompensarão com pontos suficientes no final do trimestre ou do ano. A solução é não colocar muita fé nessas métricas. Acompanhe o número de pontos, se você quiser, mas não os trate como a medida absoluta de valor.
8 - Os desenvolvedores devem ser livres
Desenvolvedores não querem que alguém limite sua capacidade de inovar e imagine novos códigos maravilhosos.
O problema é que os desenvolvedores, deixados à sua própria razão, seguirão em direções diferentes. É por isso que precisamos de alguns padrões. As vantagens de ter alguma consistência no código são fáceis de entender. O código é mais legível se os padrões e ritmos visuais forem previsíveis.
As melhores soluções podem ser aplicadas automaticamente. Alguns editores de código (Atom, por exemplo) usam regras para reformatar todo o código de acordo com as regras definidas (o ESLint também) Isso evita que os desenvolvedores se preocupem com os detalhes dos padrões e, ao mesmo tempo, assegurem que os resultados estejam limpos o suficiente.
9 - A padronização ajuda a economizar
Mas, frequentemente, os padrões podem alimentar raiva e ressentimento, dando aos desenvolvedores outra razão para lutar. Eles adoram flogar os padrões em revisões de código, inserindo linhas de código para os menores não-documentados. Por exemplo, alguém na Airbnb dedicou tempo para pensar e escrever regras sobre onde os espaços são colocados no código. Colocar um espaço dentro das chaves é obrigatório ( 19.11 ), mas colocá-las dentro de colchetes é proibido ( 19.10). Se você acha que os desenvolvedores não vão perder tempo brigando por questões triviais, bem, você não está prestando atenção. Eles adoram usar a palavra “padrão”, pois códigos fora do padrão podem condenar um projeto à morte.
Muitos desses chamados padrões são puramente estéticos e não fazem diferença na velocidade de execução do código ou na sua correção. Espaços em branco extras são ignorados pelo compilador. A pior coisa que você pode fazer é forçar a adoção de padrões que fazem pouca ou nenhuma diferença na qualidade do código em execução. Toda a conversa estética sobre a localização dos espaços é apenas para humanos - e o objetivo é impedir que os humanos discutam demais. Se você for usar padrões, faça-os simples de seguir e se preocupe apenas com os detalhes com significado prático.
10 - Simplifique sua pilha
Uma das maneiras mais simples de se afirmar alguma disciplina sobre o código base é insistir em apenas uma linguagem. Tudo é consistente e fácil para todos lerem. Todos são contratados com as mesmas habilidades linguísticas e todos se dão bem.
É uma bela ideia e faz sentido segui-la. A pergunta complicada é o que fazer quando você é tentado a abandoná-la. Sempre haverá uma nova biblioteca ou uma pilha rica em recursos de código aberto que faz exatamente o que você quer - mas está escrito em outro idioma.
Se você for rigoroso, manterá a pureza da base de código ao custo de realizar algo com rapidez e eficiência. No final, os usuários não lêem nenhum código. Eles só se importam com o que o código faz. Às vezes, faz sentido tolerar um pouco de divergência na base de código - se isso faz os usuários felizes. O desafio é saber quando a troca vale a pena.
11 - Deixe os desenvolvedores escolherem o antipadrão das ferramentas
Chris adora novas linguagens funcionais, quanto mais estrito e mais verificado, melhor. Pat quer escrever um código que é quase um código de máquina. Bob ama tudo o que estava no último título.
Eles podem se dar bem? Não! É possível colar código de muitas linguagens diferentes em um arranjo de microsserviços que pareça limpo o suficiente em um fluxograma. Muitas linguagens podem ser transpostas para algo que é executado em um mecanismo JVM ou JavaScript , tornando possível vincular os idiomas favoritos de todos em um grande blob.
Ser flexível com as opções de idiomas faz com que você seja popular quando novos projetos estão sendo iniciados. O problema surge mais tarde quando o amante de Kotlin deixa a equipe e os defensores do PHP herdam o código que eles não podem começar a ler. Mesmo quando você consegue manter as equipes com os conjuntos de habilidades corretos, os codificadores JavaScript se encontrarão em um pântano se precisarem examinar o código escrito no Swift.
Tenha cuidado ao ser muito aberto e complacente.
* Texto com informações do Portal CIO
Data: 08/03/2019
Hora: 7h02
Seção: Notícias
Autor: ------
Foto: Internet
Link: https://cio.com.br/11-praticas-de-gerenciamento-que-podem-afundar-seu-projeto-de-software/
Destaques
Comentários
