Dicas sobre como espalhar práticas orientadas a objetos [fechado]

Eu trabalho para uma empresa de médio porte com cerca de 250 desenvolvedores. Infelizmente, muitos deles estão presos a uma maneira processual de pensar e algumas equipes constantemente entregam grandes aplicativos de Script Transacional , quando na verdade o aplicativo contém uma lógica rica. Eles também falham em gerenciar as dependências de design e acabam com serviços que dependem de outro grande número de serviços (um exemplo limpo de Big Ball of Mud ).

Minha pergunta é: você pode sugerir como espalhar esse tipo de conhecimento?

Eu sei que a superfície do problema é que esses aplicativos têm uma arquitetura e design ruins. Outra questão é que existem alguns desenvolvedores que são contra a gravação de qualquer tipo de teste.

Algumas coisas que estou fazendo para mudar isso (mas estou falhando ou a mudança é muito pequena) são

• Execução de apresentações sobre os princípios de design (SOLID, código limpo etc.).
• Workshops sobre TDD e BDD.
• Treinamento de equipes (isso inclui o uso de sonar, findbugs, jdepend e outras ferramentas).
• Palestras sobre IDE e refatoração.

Algumas coisas que estou pensando em fazer no futuro (mas estou preocupado que elas possam não ser boas)

• Forme uma equipe de evangelistas de OO, que divulgue um modo de pensar de OO em diferentes equipes (essas pessoas precisariam mudar de equipe a cada poucos meses).
• Executando sessões de revisão de design, para criticar o design e sugerir melhorias (mesmo que as melhorias não sejam feitas devido a restrições de tempo, acho que isso pode ser útil)

.

Algo que encontrei com as equipes que treino é que, assim que as deixo, elas voltam às antigas práticas. Eu sei que não passo muito tempo com eles, geralmente apenas um mês. Então, o que quer que eu esteja fazendo, não fica.

Sinto muito que esta pergunta esteja repleta de frustração, mas a alternativa para escrever isso foi bater com a cabeça na parede até eu desmaiar.

Não tente empurrar OOP, isso só vai piorar as coisas. Não porque OOP é uma má ideia em geral: não é. Mas porque parece que quem é responsável por esse código de bola de pêlo não possui apenas as ferramentas para evitar esses problemas, mas também a experiência e, mais importante, a motivação.

As pessoas que desejam escrever código limpo o farão em qualquer paradigma, seja OOP, procedimental, funcional etc. Mas nem todos os programadores são assim, e se você colocar qualquer ferramenta de código limpo nas pessoas que não o fazem Para entender a necessidade, você acabará com essas ferramentas abusadas da mesma forma que as ferramentas que já estão lá. Você verá métodos não relacionados agrupados em uma classe, classes herdadas de classes não relacionadas, visibilidade do método definida com base na depuração por tentativa e erro em vez de design consciente, métodos estáticos que não devem ser estáticos e métodos não estáticos que devem, em resumo , você estará perdendo seu tempo.

Em vez disso, veja se você pode investir em aumentar a consciência para manter a manutenção e a elegância. Afinal, os objetivos principais do OOP não são diferentes de qualquer outra estratégia de gerenciamento de complexidade (que é realmente o que são os paradigmas de programação): encapsulamento, modulatização, acoplamento flexível, baixo grau de interdependência, mantendo o estado mutável e seu escopo para um mínimo, etc. etc. OOP certamente não é o único paradigma que fornece as ferramentas necessárias para alcançar isso.

O que me leva ao último ponto: OOP é uma ótima idéia e funciona bem para certos tipos de problemas, mas (e estou falando de minha própria experiência e parafraseando a opinião de algumas grandes mentes aqui) para muitos tipos de problemas, é completamente inadequado. Quando você entra no OOP, e o código de espaguete semi-processual é a única alternativa com a qual você está familiarizado, o OOP aparece naturalmente como um presente do céu (e de um modo relativo, é) e é provável que você se aproxime todos os problemas como pregos para o seu martelo OOP. Isso é natural, e levar o POO a (e além disso) suas limitações é uma boa maneira de desenvolver suas habilidades em POO, por isso nem tudo é negativo. Mas talvez (apenas talvez) essa base de código específica não precise de OOP, afinal. Talvez se beneficiasse muito mais com uma arquitetura procedural,

TL; DR: Se você quiser evangelizar alguma coisa, que sejam boas práticas de codificação (independente de plataforma), não um paradigma ou metodologia em particular.

Você não pode mudar ninguém que já não queira mudar. É por isso que as equipes que você treinou voltaram aos seus hábitos antigos.

Realmente, sua pergunta deve ser "como faço para que os desenvolvedores desejem mudar para as abordagens OO?"

Comece simples, comece pequeno, deixe as coisas crescerem a partir daí. Mostre os benefícios para o desenvolvedor individual em vez de benefícios abstratos ou filosóficos para o código, outros desenvolvedores ou a empresa.

Mostre como as várias técnicas de OO levarão a menos código que eles precisam escrever e a tempos de desenvolvimento mais rápidos. Quase qualquer desenvolvedor ouvirá uma proposta que facilitará seu trabalho.

Em seguida, comece a demonstrar como as técnicas de OO levarão a um código de manutenção mais fácil. Todo mundo nesse tipo de ambiente tem medo de fazer " a mudança " que oblitera um terço do aplicativo de produção. O encapsulamento é a chave para evitar esse risco e permite que cada camada (em breve) do aplicativo mantenha seu contrato com as outras camadas.

Eu veria como os dados estão sendo transmitidos. Se for sempre uma longa lista de variáveis, considere agrupar algumas delas em uma estrutura (ou ofegue! Uma classe !!!) como uma etapa preliminar. Simplesmente agrupar os dados em um objeto é o início dos contratos entre as camadas.

Em um nível mais amplo - considere a adesão da gerência a esse esforço, se você ainda não o fez. A gerência precisa ver os benefícios concretos da diminuição de defeitos e menor risco de fazer alterações. Eventualmente, o processo de refatoração deve levar a tempos de desenvolvimento mais rápidos, mas isso é um benefício a longo prazo.

Suas idéias de equipes de revisão e evangelistas de OO são boas. Precisa ser mais do que apenas você quem está empurrando essa agenda.

Minha experiência é que mudar de mentalidade processual para mentalidade OO é um grande obstáculo. Requer perseverança que muitos desenvolvedores não conseguem suportar. Isso ocorre principalmente porque os fundamentos do OO são examinados.

Forme uma equipe de evangelistas de OO, que divulgue um modo de pensar de OO em diferentes equipes (essas pessoas precisariam mudar de equipe a cada poucos meses).

É uma boa ideia. Isso deve ser completo e o OO deve ser discutido desde o início. Quando eu estava aprendendo OO, as histórias históricas ajudaram muito.

Eu também sugeriria

• Como a motivação é a chave, motive-os detalhando como o OO pode melhorar seu trabalho, especialmente a manutenção do código.
• Faça uma revisão do código e mostre como refatorar a aplicação da composição, herança, polimorfismo e padrões.
• Introduzir um bom processo como o SCRUM e envolver desenvolvedores nele.
• Torne obrigatórios os livros de leitura como 'Refatoração' e 'Refatoração para padrões'.

Eu concordo com Shuvo Naser. É um grande obstáculo, então trate-o mais como uma subida. Aprender a projetar um aplicativo inteiro usando OOP levará tempo.

1. Identifique aqueles que entendem OOP e aproxime-os dos líderes de equipe, treinadores, designers, revisores de código etc.
2. Use um projeto existente como uma referência de treinamento. Possivelmente aqueles no # 1 estavam nessa equipe.
3. Refatorar alguns projetos existentes. Isso pode ajudar algumas pessoas a construir uma ponte entre o código processual e o código OO. Comece com o básico. Eles precisam ver quando, onde e por que você usa esses princípios.
4. Envolva-os em sessões de design com pessoas que sabem o que estão fazendo.
5. Coloque-os em equipes de desenvolvimento com alguém que possa fornecer orientação de design e garantir que o projeto atenda aos princípios de OO (supondo que você queira fazer isso em primeiro lugar é porque isso melhorará o desenvolvimento).

A adoção raramente precede a visualização dos benefícios. Estamos falando de design complexo e não usando folhas de rosto de relatório TPS .

Você já tem boas idéias

As idéias que você descreve em sua pergunta são excelentes. É uma grande surpresa que você não esteja encontrando sucesso. Estamos em 2012 e a revolução orientada a objetos já passou do estado da arte para o estado da prática. Parece que, a menos que você tenha uma rotatividade muito baixa e poucas contratações, seria difícil não conseguir várias dezenas ou mesmo cem bons programadores sólidos de orientação a objetos.

Ágil ou Orientado a Objetos?

Você menciona algumas tecnologias Agile como TDD e alguns conceitos mais recentes, portanto, não seja muito duro com as pessoas por não abraçarem algo que ainda é combatido ativamente por algumas equipes de gerenciamento. Alguns afirmam abraçar o Agile, mas quando falam sobre isso, significa o que dizem. A organização não se caracteriza por equipes que tomam decisões e se adaptam, mas pelo forte controle hierárquico no estilo de contrato.

Mas voltando ao objeto orientado. Você não menciona análise ou design orientado a objetos, e não tenho certeza de qual linguagem de programação está dando lugar a qual linguagem de programação orientada a objetos. Eu sei que a UML está tendo problemas de popularidade entre muitos programadores orientados a objetos. Tendo sido completamente treinado em OOAD, acredito que pode ser como aprender a cultura e a história de um país cuja língua natural você deseja aprender. Por exemplo, se eu quisesse aprender grego, poderia aprender o alfabeto, vocabulário e gramática, mas se ignorasse a rica história e cultura, sentiria muita falta. De qualquer forma, se você aprender tudo sobre uma linguagem de programação orientada a objetos, mas nada sobre o OOAD, acho que uma oportunidade importante foi perdida.

Problemas a Superar?

Ponte muito longe? Se você pedir às pessoas que aprendam uma coisa pequena por semana, em um ano, entre as pessoas que participam, haverá muitas mudanças. Se você pedir que eles mudem tudo o que sabem, será bem-vindo por alguns, difícil para muitos e impossível para outros. Algumas alterações, como controle de origem, estão localizadas. Você faz a transição de não fazer isso antes, teve um treinamento que não estava estressando os limites da memória, alguém o acompanhou pela primeira vez e o dia-a-dia foi bem fácil.

Outras mudanças são generalizadas. Por exemplo, despejar C e alternar para Java requer treinamento, configuração e grandes mudanças no dia-a-dia para adotar um novo IDE, novo compilador, nova linguagem, nova API, novo modelo de implantação etc. Esse é o tipo coisa que acontece com mais frequência em conjunto com um programa piloto ou reestruturação corporativa.

Liderando uma revolução? Se as pessoas que estão atualmente fazendo o trabalho têm um histórico de serem recompensadas e a empresa não parece correr o risco de falhar, qual é a motivação delas para mudar? Se você parece um estranho que quer apontar a direção e deixá-los responsáveis ​​pelos resultados que não podem prever, pode parecer que todos os riscos, nenhuma recompensa.

Poder de posição ou liderança de idéias? Muitas organizações operam com base no poder da posição. Se você não tem o apoio visível de gerentes, chefes de seção, diretores e vice-presidentes, você é apenas um líder de idéias. Algumas pessoas estão na posição perigosa de ter uma idéia e não serem capazes de aceitar uma segunda. Se você pode mostrá-los ao invés de contar, isso ajudará bastante a acalmar os céticos e a interessar aliados talentosos.

Base de suporte muito pequena? Faça uma triagem entre essas 250 pessoas e as classifique em três categorias: prontas para abraçar, dispostas a aprender e dispostas a aprender. Você tem bons motivos para ficar frustrado com algumas pessoas que não têm interesse em fazer uma mudança. Você também pode estar empurrando uma corda. Isso é esforço desperdiçado. Se você tem uma idéia de quem apóia a mudança, pode descobrir o que lhes interessa.

Ao contrário de uma triagem médica em que a escolha ética e prática é ajudar o grupo intermediário que pode ajudá-lo, você pode investir sua energia e tempo com base em seu julgamento e preferência. Para o seu sucesso, por que não cultivar o grupo que está pronto para abraçar novas idéias? Eles podem ser poucos no começo, mas, como uma bola de neve, sua visibilidade e credibilidade como defensor crescerão. Em breve, as pessoas perguntarão quando será o próximo treinamento.

Nele para o longo prazo? Até você cultivar um campeão para levar as coisas depois de você, você deve esperar investir tempo construindo relacionamentos. Pode ser necessário permanecer com as equipes que você treina por mais de um mês. Até que a equipe possua práticas aprimoradas para si, você é apenas um policial de tecnologia ou metodologia. A tutoria é um processo que pode levar anos. Há muitas coisas que seus desenvolvedores não querem fazer e que você acha importantes (você mencionou especificamente o teste de unidade, eu acho). Pode demorar um pouco para construir uma visão compartilhada do valor que isso traz. Eu sei disso por experiência, porque uma vez defendi uma ferramenta de cobertura de código em uma empresa da Fortune 500 que tinha uma ótima reputação de qualidade, mas gerentes e colegas estavam cautelosos em se comprometer com ela.

Especialista ou de base? Muito mais rápido que a orientação seria promover o apoio de base que vem de cada membro da equipe. Começando com uma equipe de dez especialistas em software, se eu tivesse minha escolha de ter uma pessoa trabalhando no processo o tempo todo ou dez pessoas trabalhando no processo 10% do tempo, eu escolheria o segundo. O processo de base permite que os advogados sintam o impacto da abordagem e que a abordagem seja adaptada para melhor resolver os problemas da equipe que possui o trabalho.

Você vê a Linha da Liberdade? Parte da introdução das "Melhores Práticas" é levar as pessoas a desistir de alguma liberdade para fazer as coisas de maneira comum. Desistir do critério do programador será mais agradável se você procurar oportunidades para deixar muitas opções para os desenvolvedores. O que eles escolhem é delineado pelo que é mandatado por uma partição que podemos chamar de linha da liberdade. Pode ser necessário divisões semelhantes e bem justificadas sobre práticas organizacionais, regionais / locais, equipes e práticas pessoais.

Isso deveria ter sido um comentário, mas, como aparentemente ainda não sou capaz de comentar algumas coisas, pode ser uma resposta.

A coisa mais importante de todos os tempos nesse tipo de inovação (seja OOP ou qualquer outra mudança de paradigma, digamos, programação funcional ou o que sair no próximo ano) é FAZER REVISÕES DE CÓDIGO E PROGRAMAÇÃO POR PARES . Acompanhe-os, conduza as equipes a uma maneira diferente de fazer coisas que os ajudarão.

Meu caminho pessoal para a programação orientada a objetos começou quando algumas críticas aleatórias que faziam revisões de código me castigavam por fazer as coisas de maneira modular e mantendo o estado sem ter o C ++ OO completo; pense código como

extern float clients_total;

void client_add(float sum);  
void client_substract(float sum);
float client_get_total();

(observe que customers_total pode ser totalmente redundante, sendo um exemplo particularmente mal planejado)

E acabei fazendo isso apenas quando um colega mais velho apenas apontou para a minha tela e disse: "olha, se você escrever a mesma coisa mais de uma vez, use um procedimento ou uma função e chame repetidamente".

Palestras, reuniões e práticas opcionais não farão com que eles mudem de paradigma ou introduzam uma nova prática, já que não há nenhum impulso real para fazê-lo além da pura curiosidade. Por outro lado, não fazer algo ruim ou geralmente desaprovado aumenta a taxa de adoção muito bem.

Esteja preparado para o desenvolvimento lamentável e orientado para a classe que ocorrerá até que eles incorporem o design adequado ao que estão fazendo. Você verá muitas coisas que o farão morrer por um tempo, mas é assim que o caminho para o aprendizado se parece.