O que fazer quando seu colega de trabalho não entende o design que está tentando manter [fechado]

Um projeto de software em que estou trabalhando envolve eu e outro programador. O projeto envolveu um back-end de mecanismo com um front-end MVC. Inicialmente, fiz um monte de trabalho no projeto e, portanto, configurei algumas metodologias simples de design, principalmente em torno da abstração e da estratégia de modelos.

Por um bom tempo, estive fora do back-end do motor e trabalhei no site. No entanto, ainda mantive um interesse no motor, pois fui informado de que poderia voltar a usá-lo em algum momento.

O projeto tem um prazo muito apertado, por isso estamos todos prontos para finalizá-lo no front-end e no back-end.

Eu não me considero um ótimo programador e, portanto, nunca tento impor qualquer design ou conjunto de metodologias específico às pessoas, pois nem sempre tenho certeza de que estou certo e gostaria que outras pessoas oferecessem suas opiniões para tentar encontre melhores soluções. No entanto, notei alterações sendo feitas neste código do mecanismo que realmente está começando a me irritar. Quando confrontei o desenvolvedor para sugerir que ele fizesse o trabalho de outra maneira, ele disse que não entendia o ponto, pois parecia haver pouco benefício, considerando os prazos apertados.

Eu tive que tentar explicar que o truque que ele havia colocado poderia significar mais desenvolvimento após o lançamento, e não achei justo fazer com que outros entendessem a folga quando pudéssemos corrigi-la agora. Passei cerca de 30 minutos analisando o que havia feito e, no final, ele me pediu para escrever o código para que ele pudesse copiá-lo.

A base do que eu tinha inicialmente configurado foi:

• Uma classe abstrata x
• Uma classe de fábrica abstrata para criar instâncias concretas de x

O que aconteceu foi que ele colocou algumas instruções if que poderiam facilmente ter sido colocadas como métodos virtuais / abstraciais na classe abstrata e, em seguida, implementadas conforme a nova mudança já seguia o mesmo princípio de outros métodos na classe abstrata.

Isso me parece trivial, no entanto, ele não conseguiu entender isso, mesmo quando eu mostrei a ele as aulas envolvidas.

Agora minha pergunta é:

1. É injusto supor que ele deveria ter entendido esse conceito. Percebo que temos prazos apertados, mas achei que era trivial. O programador deve ter pelo menos um nível intermediário.
2. Isso já aconteceu em vários lugares e sempre tentei fazê-lo mudar, mas ele não parece. Devo simplesmente ignorá-lo?
3. Devo levantar essa questão em outro lugar ou simplesmente sugá-la e, quando voltar ao projeto, mude todas essas coisas.

Sua parte do projeto não será concluída e é por isso que terei que voltar e ajudá-lo. Eu realmente não quero muito, pois ele pegou um projeto com arquitetura não muito boa, mas ok, e realmente inseriu um monte de código confuso que, na maioria das vezes, não seguia o que estava tentando ser alcançado.

Se a pergunta for muito vaga ou correta, entre em contato e tentarei editar de acordo.

EDITADO: Espera-se que o projeto continue após o prazo inicial, pois já existe o trabalho de acompanhamento planejado e o trabalho em que não nos encaixamos e que foi acordado em ser implementado posteriormente.

Da supervisão de talvez mais de 200 desenvolvedores nos últimos 25 anos, eu acho - a proporção de desenvolvedores que são intuitivamente confortáveis ​​com o tipo de abstrações de design de que você está falando - é algo como um terço. Minha abordagem evoluiu da expectativa de consertar isso com treinamento, treinamento e incentivo, para ainda trabalhar no treinamento, etc. - mas reconhecendo que esse conforto tem uma qualidade inata, e que muitas vezes você não pode mudar. Você perguntou se é justo. Eu acho que o que não é justo é que sua gerência espere que um membro da equipe de desenvolvimento assuma a responsabilidade por essa tensão e pelo impacto dela. Se você tem um líder por perto - tente explicar a tensão para eles em seus termos, não nos seus. Não é sobre o outro desenvolvedor - é sobre eficiência, impacto e risco futuros = resultado final e, portanto, uma clara responsabilidade de gerenciamento. Busque soluções organizacionais que explorem suas habilidades relevantes. Você pode fazer mais trabalho de orientação de projeto, e o outro cara faz mais do acabamento. Não presuma que todos os desenvolvedores não desejam esse papel - muitos desenvolvedores adoram ser bons em terminar as coisas para satisfazer os clientes rapidamente - e são gratos por um ambiente de design de qualidade ser fornecido por outra pessoa.

Às vezes não é o conceito, mas o tempo necessário para grocá-lo. As pessoas não entendem as coisas quando lhes são explicadas rapidamente por alguém, mas dão-lhes tempo para procurar por si mesmas e então elas conseguem. Às vezes, leva um pouco de tempo para que o conceito penetre.

Entendo que os prazos eram apertados, e o conhecimento é limitado, o que pode ter tido mais impacto do que você gostaria, mas neste caso (e faço suposições aqui), você o apontou para um documento de padrão de projeto de fábrica ou você apenas espere que ele entenda seu código, agitando-o debaixo do nariz, gritando "você simplesmente não entende, cara, você simplesmente não entende" :)

Eu mesmo poderia ter feito o mesmo - mostrei o código às pessoas, espero que elas entendam instantaneamente, fiquem frustradas quando ficam em branco, vasculhe-o em uma tentativa inútil de fazê-las entender, ficam irritadas quando ficam ainda mais confusas, depois ou acotovelá-los para fora do caminho e faça-o sozinho ou seja instruído a se afastar e fazer isso sozinho, se eu for tão esperto. O que é uma reação compreensível às minhas más tentativas como professor.

Classes abstratas, fábricas de classe, não me interpretam mal, mas soa como uma artilharia para matar um pássaro. Os padrões existem para resolver problemas e não para criá-los. Você admitiu que o projeto é de 2 pessoas.

O que seu colega está fazendo de errado, porém, é que ele não está seguindo as diretrizes. Isso causará alguma confusão a jusante. Se o projeto for abstraído de todas as formas, ele deve tentar segui-lo.

Você não queria forçar o padrão nele desde o início, mas poderia ter tido uma breve discussão sobre algumas das coisas que fez. Sob as restrições de tempo, duvido que ele seja capaz de entender seu conceito o suficiente para implementá-lo tão rápido quanto seu 'hack'. Você quer que ele conserte as coisas agora para impedir que outra pessoa / você precise consertá-las mais tarde, mas o projeto não será concluído a tempo. Ou ele não entende o que você estava fazendo ou sente que levará muito tempo e não vale a pena arriscar um atraso.

Saiba quando o projeto pode ser concluído e suscite preocupações sobre essas limitações no futuro e a necessidade de tempo adicional. Você terá alguma dificuldade em fazer com que todos vejam do seu jeito, se o cliente estiver satisfeito. Pode não estar certo, mas é realidade.

Provavelmente não é um problema técnico, definitivamente não é um problema de programação. Parece nada mais do que o debate tradicional "programação para o possível futuro versus cumprimento dos prazos de hoje", que é um caso específico de "não gosto da maneira como o outro cara faz seu trabalho, quero que ele faça do meu jeito" " Acontece todos os dias em todos os locais de trabalho com mais de um funcionário.

Suas habilidades de gerenciamento e vendedor serão mais importantes que qualquer superioirty técnico em seu projeto, se você quiser "vencer" este.

Sugiro a leitura de livros como "Como conquistar amigos e influenciar pessoas" e "De que cor você pára de falar" e outros livros de habilidades pessoais.