Inexistência de Confiança
Acho que ter checagens por null por todo o código é o indicador mais óbvio que as pessoas não confiam no código com que estão trabalhando.
Se a pessoa escrevendo o código tivesse fé em seus colegas que escreveram o código que ele precisa agora, acho que seria mais provável que ele confiaria que o código fará a coisa certa e não se sentiria na necessidade de ser tão defensivo.
Medo do Conflito
Medo do conflito em uma equipe parece se manifestar da maneira mais óbvia em código quando temos muitas duplicações acontecendo (síndrome do “copy & paste”) – existem diversas razões para duplicações mas acho que uma delas é quando as pessoas não estão engajadas em discussões quando eles não concordam com alguma coisa que um colega escreveu e por isso acabam escrevendo suas próprias versões de alguma coisa que já foi feita.
Isso provavelmente se manifesta de maneira ainda mais óbvia quando você acaba com múltiplos diferentes frameworks na mesma base de código e todos fazendo as mesmas coisas só porque as pessoas não querem engajar em conversações para escolher qual a equipe toda vai usar.
Falta de Comprometimento
Esse é um que parece cruzar muito com os dois anteriores, embora uma maneira específica que este se manifesta em código quando vemos erros básicos ou falta de cuidado demonstrado em código (síndrome de “fazer nas coxas”) – um exemplo disso pode ser mudar o nome da classe e então não garantir que todos os lugares onde o nome antigo era usado tenham sido atualizados.
Isso deixa o código numa situação meia-boca e torna muito difícil para as outras pessoas trabalharem e eles precisam ficar limpando as coisa antes de conseguir efetivamente fazer algum trabalho.
Evitar Responsabilidade
O anti-padrão de código que mais salta aos meus olhos é quando nós permitimos que as pessoas escrevam código sem testes e colocamos no repositório de código.
Pela minha experiência até agora isso nunca funcionou bem e eu acho que isso demonstra falta de respeito pelo resto da equipe já que não temos uma maneira simples de verificar se o código efetivamente funciona e as outras pessoas não podem usar isso em outro lugar com nenhum grau de segurança.
Falta de Atenção a Resultados
Membros da equipe colocando suas necessidades individuais antes da equipe se manifesta no código quando acabamos com código que foi escrito de tal maneira que apenas quem escreveu o código é capaz de entendê-lo.
Acho que isso se manifesta em “código esperto” que não tem problema se o projeto for só seu, mas no contexto de uma equipe é muito detrimental à medida que você se torna o gargalo quando outras pessoas querem fazer mudanças nessa área do código e não podem porque não conseguem entender o que está acontecendo.
Outra coisa que cai nesta mesma situação é quando existem convenções a serem seguidas mas decidimos sair por fora e fazer do nosso jeito. Tudo bem, algumas vezes não tem problema se estamos trabalhando para tornar o código realmente melhor e o resto da equipe sabe e concorda com isso. Caso contrário, não é algo inteligente de se fazer.
Em Resumo
Acho intrigante que em minha mente, pelo menos, alguns dos problemas que vemos em código parecem ter alguma correlação aos problemas que vemos nas equipes.
Uma coisa que eu me lembro ao ler Os Segredos de Consultoria, de Gerald Weinberg é sua afirmação de que não importa qual seja o problema, sempre é um problemas de pessoas – se de fato isso for verdade então, em teoria, problemas que vemos em código devem ser indicativos de problemas com pessoas, que eu acho que até certo ponto realmente é verdade.
Eu acho certamente que nem todo problema de código está ligado às disfunções de equipes – certamente alguns anti-padrões entram no seu código devido à inexperiência de membros da equipe, mas de qualquer forma isso também demonstraria a falta de sêniors na equipe trabalhando de forma mais próxima com seus colegas!
Talvez possamos identificar maneiras de como melhorar nossas equipes começando dando uma olhada no seu código.
Ranting
por AkitaOnRails: de fato, estou muito convencido que problemas que acontecem no código são apenas sintomas de problemas estruturais das equipes e das organizações.
Começa pela falta de respeito: quando membros da equipe vêem seu chefe (não usem “líderes” para designar chefes hierárquicos. Eles nunca são “líderes” de verdade) usando de “carteirada” para conseguir as coisas com outras equipes, entre desenvolvedores também fica uma briga de braço do tipo: “eu fiz minha parte, se o outro reclamar mando meu chefe falar com eles e pronto.” Na minha experiência, quase todos os problemas de equipes ineficientes e problemáticas é o gerente.
Gerentes que exercitam “comando-e-controle” são exatamente os tipos que devem ser execrados de uma organização. Gerentes que não confiam na equipe, que gritam, que usam de força do cargo, que insistem em ser o gargalo da comunicação, que insistem que tudo tem que passar por eles, que não tem conhecimento real – o que é notório na sua falta de capacidade de argumentação. Gerentes que não sabem dar feedback honesto e diário, pelo bem ou pelo mal, e deixam para jogar tudo na cara dos outros meses depois – que, para mim, é a maior demonstração de covardia em alguém que deveria ser um “líder”.
O Gerente que gosta de “micro-gerenciar” quando bem lhe convém, mas não explica quais são suas expectativas e cujo feedback é positivo ou negativo não de acordo com o trabalho feito, mas de acordo com seu humor em geral, o que torna as coisas muito cômodas para ele, óbvio. Os gerentes que, para parecerem que não são tão ruins, gastam seu tempo tentando fazer as outras equipes parecerem ruins: os famosos caçadores de pelo em ovo, aqueles que vão procurar os motivos triviais como horário, vestimenta, pequenas conversas, e coisas desse tipo como desculpas para falar mal, em vez de resultados reais como lucro, custo, etc.
Se você está realmente preocupado em porque suas equipes não estão performando como deveriam, olhe para a camada de gerentes. Especialmente, ou principalmente, aqueles que estão há muitos anos na mesma organização. Viciados, que já conhecem todos os “jeitinhos” da organização. Eles são perigosos: sorriem para todo mundo, parecem confiantes, parecem eficientes, a maioria dos seus subordinados o elogiam (porque estão sob efeito de coerção, obviamente).
A equipe reflete o sistema e a estrutura que lhes é colocado sobre eles. Tire-lhes a autonomia, trate-os como crianças, deixe-os confusos e com medo e é exatamente esse o resultado que você vai ter: trabalho mal feito, de má qualidade, que dá defeitos o tempo todo, que custa caro. Alguns acham que isso é exagero, especialmente diretoria alheia e pouco participativa (qualquer coisa diferente de ‘todos os dias’ não é participação) ao que acontece no chão de fábrica, eles ficam surpresos ao ver que seus funcionários se tornaram não somente estagnados, incompetentes, obsoletos mas também distantes e despreocupados com o futuro da organização. A única coisa que os preocupa nesse momento, são seus empregos.
Enquanto isso, os tais “gerentes”, continuam em situações confortáveis: quando as coisas – por sorte, e apenas sorte – dão certo, recebem os louros. Quando as coisas dão errado a culpa é de membros da equipe que eles já iam dar um jeito mesmo, ou a culpa é de outras equipes, a culpa é da organização inteira que não o ajudou, a culpa é das decisões históricas que agora não tem mais jeito. Mas a culpa nunca é dele mesmo. Lembrem-se: anos de casa não pode significar imunidade. Anos de casa deve ser irrelevante se a intenção da organização é ser eficiente. E não se preocupe em mandar um gerente desses embora com o medo “mas só ele sabe como fazer as coisas”; as “coisas” não vão desandar, confie nas equipes, devolva-lhes a autonomia, elas saberão o que fazer.
Portanto, sim, a grande maioria das disfunções de uma equipe é resultado direto das disfunções de sua organização. Não adianta tentar aplicar técnicas localizadas como pregar pair programming, test driven development, refactoring, etc se a organização permanece a mesma. Quer mudar? Mude tudo. Ou nem se dê ao trabalho.