Entrei para uma equipe que tem uma abordagem diferente para projetar a minha. Eu acredito na abordagem YAGNI ao design. Por exemplo, se um método (interface, classe) não for utilizado, ele deverá ser removido. É isso aí.
As pessoas da minha equipe estão criando um aplicativo modular e um dos módulos é percebido como "estrutura". O aplicativo é o único usuário dessa estrutura, e não há planos no momento para ter mais clientes. No entanto, partes do código nesta estrutura são gravadas e mantidas como se pudessem ser usadas posteriormente , e a consistência e a integridade vencem o YAGNI. Existem abstrações em lugares que talvez nunca precisem de abstrações etc.
Tentei argumentar algumas coisas, mas cada ponto leva muito tempo para persuadir, se é que existe, e tenho medo de que "empurrar" demais resultará na divisão da equipe em lados opostos.
Eu posso "acompanhar o fluxo" e escrever código extra sem problemas pessoais. Agora levarei mais tempo para codificar e, provavelmente, mais tempo para manter, no entanto , cada discussão para não fazer algo extra também leva tempo e aumenta a pressão.
A questão é, no caso de opiniões diferentes, o que fará um desserviço maior, código desnecessário, mas "adequado", ou argumentos constantes e dinâmica de equipe interrompida?
Respostas:
Manter uma estrutura imaginária é uma decisão arquiteturalmente significativa, então a questão se resume em "como criamos e evoluímos a arquitetura" na equipe. Você precisa começar com regras de tomada de decisão bem definidas, claras e adotadas por todos na equipe, porque não há jogo sem as regras .
Ao ingressar na empresa, uma das perguntas mais importantes que você pode fazer é:
Nenhum processo de tomada de decisão é pior que um processo de tomada de decisão ruim . se não houver processo, alguém precisa definir um. Caso contrário, a quantidade de bobagens cresce junto com a quantidade de desacordo dentro da equipe.
Acho que com isso estamos fechando o ciclo - ou você tem autoridade e poder para definir o processo de tomada de decisão quando está faltando OU você concorda com o processo atual / e como ele evolui. Escolha um.
fonte
Argumentos constantes e dinâmica de equipe quebrada nunca o levarão muito longe.
Eu tentaria entender por que existe uma estrutura em primeiro lugar.
Provavelmente, o motivo é que se espera que seja usado em outros sistemas posteriormente. Se for esse o caso, faz sentido fazer mais do que o necessário no momento.
A razão para isso é que, se um aplicativo está em produção, um novo aplicativo está em andamento, exigindo atualizações na estrutura, toda vez que algo é alterado na estrutura, talvez abstrações que não eram necessárias anteriormente sejam adicionadas, então o aplicativo original precisa ser atualizado e testado também.
É uma quantidade enorme de refatoração e reteste de algo em produção.
Se você optou por não incluir a estrutura atualizada no aplicativo antigo, possui duas estruturas para manter uma delas já obsoleta.
Manter código obsoleto também não é muito bom para o moral.
fonte
Se você é novo em uma equipe, tentar não ser um distúrbio na força deve ser sua primeira preocupação.
Suponho que você não esteja na posição de líder / arquiteto e que as decisões não são suas.
A segunda preocupação é aprender . Aprenda muito. Saiba por que eles tomaram as decisões que tomaram, por que a estrutura foi criada, qual é o racional por trás disso. Quando você tiver todas as informações, poderá tomar uma decisão informada sobre como abordar possíveis problemas, como engenharia excessiva e má comunicação.
Faça perguntas, de forma educada . Coloque-se na posição de aluno, e não de mestre. Tornará mais fácil para as pessoas "ensinarem" por que elas fizeram as coisas dessa maneira.
Agora você é o pária. Você está ingressando em uma equipe estrangeira e deve aprender os costumes deles e se adaptar.
Se você fizer seu trabalho da maneira certa, com uma abordagem educada com as pessoas, as pessoas naturalmente o ouvirão com o tempo. E então, se você estiver absolutamente certo de que sua abordagem é a melhor como um todo, poderá influenciar as pessoas a mudarem.
Eu mal conhecia alguém que gosta de trabalhar com uma pessoa que costuma criticar, mas não gera valor. Seja uma referência à sua equipe, alguém com quem eles se orgulham de trabalhar.
Também, leitura recomendada: https://www.amazon.com/How-Win-Friends-Influence-People/dp/0671027034
fonte
Há duas coisas fundamentais que acho que estão acontecendo. O primeiro é cultural. Você é novo na equipe e ainda não descobriu como trabalhar com essa equipe. Eles provavelmente têm políticas e práticas diferentes que podem realmente funcionar para eles. Além disso, um ou mais deles podem ter se candidatado à sua posição e, assim, sabotando ativamente seus esforços ou simplesmente não dizendo o que você precisa saber.
A segunda é que você possivelmente interpretou mal o design. A parte que você acha que é um código morto pode realmente ser uma generalização de outras partes do design ou pode estar trabalhando no sentido de oferecer suporte a algo que a empresa deseja eventualmente apoiar. Na verdade, pode ser um código morto. Pare de ficar obcecado com isso e entenda por que está lá. Na verdade, pode levar meses para descobrir.
Em setores avessos ao risco (ou seja, bancário, medial ...) onde existe a pequena possibilidade de que um pedaço de código possa ser usado, esse pedaço de código permanecerá por décadas.
Para destacar isso, uma das estruturas de banco de dados mais estranhas que eu já vi centrada em 6 tabelas. 3 deles estavam mapeando tabelas que conectavam os outros três. Não fazia sentido, pois o código indicava que apenas um deles estava sendo usado como um relacionamento muitos-para-muitos e os outros 2 estavam implementando um-para-muitos. Os designers originais haviam saído e ninguém poderia explicar exatamente como ou por que funcionava. Eventualmente, deparei com um documento comercial que explicava o design - então, meu palpite era que a empresa havia solicitado e algum DBA havia implementado de uma maneira que a empresa pudesse entender - apesar de suas limitações óbvias. 30 anos depois, ele ainda está lá, ganhando o dinheiro da empresa - mas, do ponto de vista do desenvolvimento, difícil de entender, manter e desenvolver.
fonte
Vejo alguns pontos positivos de ter uma parte desse aplicativo fora do aplicativo, mesmo que ninguém mais o use.
Isso pode impor o desenvolvimento de funcionalidades técnicas na estrutura com seus testes adequados fora do contexto funcional da aplicação (e em seu próprio roteiro).
Além disso, pode ser possível que você não queira que todos os desenvolvedores toquem nessa estrutura, mas apenas os mais seniores, portanto, obtê-lo novamente fora do aplicativo é uma vantagem.
Para as camadas de abstração não necessárias, bem, se elas já estiverem lá, não altere algo que já esteja funcionando.
No entanto, você deve se lembrar para a sua equipe no futuro que o objetivo da estrutura é aliviar o seu trabalho, sem ponderá-lo.
fonte
Lendo nas entrelinhas, estou inclinado para os membros de sua co-equipe. Tornar algo "mais complicado do que o necessário" não apenas abre caminho para possíveis funcionalidades futuras que talvez nunca sejam necessárias, mas também serve ao entendimento do desenvolvedor sobre o aplicativo, incorpora um modelo no software e documenta uma idéia.
E, ao fazê-lo, restringe o caminho para futuros desenvolvimentos. Isso evita que desenvolvedores que não compreendem completamente o design / intenção se desviem.
Um novo desenvolvedor pode, a princípio, se incomodar com o design "desnecessariamente complicado", mas também o guia na direção certa, o faz cair no poço do sucesso e dificulta a tarefa de "fazer as coisas do seu jeito", o que seria apenas uma outra maneira que realmente complicaria as coisas, pois levaria a diferentes abordagens no mesmo aplicativo, o que torna ainda mais difícil para o próximo cara entender o assunto.
YAGNI não significa (ou não deveria) "você pode pular o design" ou "fazê-lo rápido e sujo". Se sua equipe tem o luxo de pensar sobre as coisas, eu diria que isso é algo para valorizar, em vez de lutar.
fonte