Estou procurando uma maneira eficiente, que também não seja um insulto, de introduzir conceitos de POO aos membros da equipe existentes? Meus colegas de equipe não são novos nos idiomas OO. Fazemos C ++ / C # há muito tempo, de modo que a própria tecnologia é familiar.
No entanto, olho em volta e sem grande infusão de esforço (principalmente na forma de revisões de código), parece que estamos produzindo um código C que, por acaso, está dentro de classes. Quase não há uso de princípio de responsabilidade única, abstrações ou tentativas de minimizar o acoplamento, apenas para citar alguns. Eu já vi classes que não têm um construtor, mas obtêm o memset como 0 toda vez que são instanciadas.
Mas toda vez que eu mostro OOP, todos sempre concordam e fazem parecer que sabem exatamente do que estou falando. Conhecer os conceitos é bom, mas nós (alguns mais que outros) parecemos ter muita dificuldade em aplicá-los quando se trata de entregar um trabalho real.
As revisões de código têm sido muito úteis, mas o problema com as revisões de código é que elas ocorrem apenas após o fato; portanto, para alguns, parece que acabamos reescrevendo (é principalmente refatoração, mas ainda leva muito tempo) o código que acabou de ser escrito. As revisões de código também fornecem feedback para um engenheiro individual, não para toda a equipe.
Estou brincando com a idéia de fazer uma apresentação (ou uma série) e tentar abrir o OOP novamente, juntamente com alguns exemplos de código existente que poderiam ter sido escritos melhor e que poderiam ser refatorados. Eu poderia usar alguns projetos realmente antigos que ninguém possui mais, pelo menos essa parte não deve ser uma questão delicada. No entanto, isso vai funcionar? Como eu disse, a maioria das pessoas faz C ++ há muito tempo, então meu palpite é que: a) elas ficam lá pensando por que estou dizendo coisas que já sabem ou b) elas podem realmente encarar isso como um insulto, porque dizendo que eles não sabem como fazer o trabalho que vêm realizando há anos, senão décadas.
Existe outra abordagem que atingiria um público mais amplo do que uma revisão de código, mas ao mesmo tempo não pareceria uma palestra de punição?
Eu não sou um garoto recém-formado que tem ideais utópicos de código perfeitamente projetado e não espero isso de ninguém. A razão pela qual estou escrevendo isso é porque fiz uma revisão de uma pessoa que realmente tinha um design decente de alto nível no papel. No entanto, se você imaginar as classes: A -> B -> C -> D, no código B, C e D implementam quase a mesma interface pública e o B / C tem funções de um liner, de modo que a classe A superior está fazendo absolutamente todo o trabalho (até gerenciamento de memória, análise de strings, negociações de configuração ...) principalmente nos métodos 4 mongo e, para todos os efeitos, chama quase diretamente para o D.
Atualização: Sou líder técnico (6 meses nessa função) e tenho total suporte do gerente do grupo. Estamos trabalhando em um produto muito maduro e os custos de manutenção estão definitivamente se tornando conhecidos.