Como evitar que um colega introduza extrema complexidade e abstração?

Estou passando por um momento muito difícil, porque meu colega parece exibir

Esforços de otimização prematuros / desnecessários
Desduplicação prematura com abstrações questionáveis
Por exemplo, usamos uma arquitetura VIPER modificada. Ele introduziu uma classe base para o componente Router (usando genéricos) como parte da implementação da primeira pilha viper sem saber o que exatamente será duplicado em outros roteadores. Agora, não podemos fornecer um tipo UseCaseque contenha casos de uso, mas a maioria dos roteadores não possui vários casos de uso, apenas um.
Inventando soluções de uso geral para recursos futuros potenciais especulativos
Por exemplo, ele escreveu um gerente para preencher visualizações de tabela de células estáticas quando tínhamos apenas duas telas como esta no aplicativo e ele não sabia que o design passaria de formas verticais chatas para mais personalizadas UIs para que o gerente seja inútil.
Optando pela complexidade incidental

Como eu luto contra isso quando ele também exibe uma barreira no idioma com o péssimo inglês?

architecture

— Earl Grey
fonte

Você já tentou revisões obrigatórias de código para dar uma oportunidade para discutir o que está acontecendo? Você já tentou o embarque branco com ele para encontrar uma boa solução antes que ele se sente para começar a codificar?

— Becuzz

Você pode dar um exemplo em que situações como 2 ou 3 podem acontecer?

— morbidCode

Sinto sua dor, @EarlGrey. Provavelmente nunca vi um caso em que a codificação "genérica" super antecipada realmente funcione como planejado no futuro.

— Graham

Conheço pessoas que chamam de quicksort, em vez de bolhas, para uma otimização prematura. Qual é o seu limite?

— Pieter B

Seu colega parece estar esquecendo / inconsciente do princípio de YAGNI .

— Bart van Ingen Schenau

Sua descrição soa como a codificação que fiz nos anos 90. Atuar adequadamente no mundo moderno não é fácil. Eu recomendo focar nos seguintes fatores:

Emparelhamento. Dois pares de olhos podem ajudar a proteger contra uma pessoa ótima, mas implementação complicada.
Revisão de código. Lojas modernas revisam 100% de todas as alterações de código por várias pessoas
Cobertura de teste. Verifique se há testes simples. Testes excessivamente complicados podem refletir código excessivamente complicado
Muita discussão sobre o produto mínimo viável. Divida os recursos nos menores componentes possíveis. Não há problema em ter um ticket para alterar o banco de dados, outro para preencher as tabelas de referência e um terceiro para atualizar a interface do usuário (a parte que realmente ficará visível para os usuários finais), mas parecerá contra-intuitivo desde o início. provável.
Discussões frequentes sobre como obter tickets e alterações menores.
Votação do ponto da história por toda a equipe para abrir discussões sobre complexidade e abordagem.
Educação. Certifique-se de almoçar e aprender, sessões de treinamento etc. para que as pessoas possam se expor a boas práticas e por que elas são boas.

Pelo exposto, meus dois principais pontos de foco seriam revisões de código e histórias menores.

No final do dia, acho que a melhor solução para mudar o comportamento existente é ter uma pessoa dedicada liderando a mudança. Nas organizações ágeis (provavelmente a maioria hoje), é necessário que uma pessoa dedicada, como o scrum-master, esteja constantemente fazendo as perguntas certas e orientando a abordagem de desenvolvimento. Na minha última organização, tínhamos uma dúzia deles, um em cada equipe, para ajudar a orientar as pessoas sobre esses tipos de problemas. Isso elimina a necessidade de um desenvolvedor de um membro da equipe tentar convencer os outros de que "seu caminho é o certo", o que geralmente pode levar a trocas acrimoniosas e sangue ruim.

— Michael Durrant
fonte