Como eu provo ou refuto que “os objetos de Deus” estão errados?

Resumo do Problema:

Para encurtar a história, herdei uma base de código e uma equipe de desenvolvimento que não tenho permissão para substituir e o uso de God Objects é um grande problema. No futuro, quero que refizemos as coisas, mas estou recebendo críticas das equipes que querem fazer tudo com o God Objects "porque é mais fácil" e isso significa que não seria permitido refatorar. Recuei citando meus anos de experiência em desenvolvimento, que sou o novo chefe que foi contratado para saber essas coisas etc., e o mesmo aconteceu com o representante de vendas da conta de empresas offshore, e agora isso é no nível executivo e na minha reunião é amanhã e quero entrar com muita munição técnica para defender as melhores práticas, porque sinto que será mais barato a longo prazo (e eu pessoalmente acho que é isso que preocupa os terceiros) para a empresa.

Meu problema é de nível técnico, eu sei que é bom a longo prazo, mas estou tendo problemas com o ultra curto prazo e o prazo de 6 meses, e enquanto isso é algo que eu "sei", não posso provar isso com referências e recursos citados fora de uma pessoa (Robert C. Martin, tio Bob), pois é o que me pedem para fazer, porque me disseram que ter dados de uma pessoa e que apenas uma pessoa (Robert C Martin) não é argumento suficiente .

Pergunta, questão:

Quais são alguns dos recursos que posso citar diretamente (título, ano de publicação, número da página, citação) por especialistas renomados na área que dizem explicitamente que o uso de "Deus" Objetos / Classes / Sistemas é ruim (ou bom, pois estamos procurando para a solução mais tecnicamente válida)?

Pesquisa que já fiz:

1. Eu tenho vários livros aqui e procurei em seus índices pelo uso das palavras "objeto de deus" e "classe de deus". Descobri que, estranhamente, quase nunca é usado e a cópia do livro do GoF que eu tenho, por exemplo, nunca o usa (pelo menos de acordo com o índice à minha frente), mas eu o encontrei nos dois livros abaixo, mas quero mais Eu posso usar.
2. Eu verifiquei a página da Wikipedia em busca de "God Object" e atualmente é um esboço com poucos links de referência. Embora eu pessoalmente concorde com o que diz, ele não tem muito que eu possa usar em um ambiente onde a experiência pessoal não é considerada válida. O livro citado também é considerado velho demais para ser válido pelas pessoas com as quais estou debatendo esses pontos técnicos, pois o argumento é que eles "já foram considerados ruins, mas ninguém poderia provar isso, e agora o software moderno diz" deus "objetos são bons de usar". Pessoalmente, acredito que esta afirmação está incorreta, mas quero provar a verdade, seja ela qual for.
3. Nos "Princípios Ágeis, Padrões e Práticas em C # de Robert C Martin" (ISBN: 0-13-185725-8, capa dura), onde na página 266 ele afirma: "Todo mundo sabe que as classes de Deus são uma má idéia. Não queremos concentrar toda a inteligência de um sistema em um único objeto ou em uma única função. Um dos objetivos do OOD é particionar e distribuir o comportamento em muitas classes e muitas funções ". - E então continua dizendo que às vezes é melhor usar Classes de Deus de qualquer maneira (citando microcontroladores como exemplo).
4. Na página "Código Limpo: Um Manual do Artesanato em Software Ágil", de Robert C Martin (pág. 136) (e somente esta página) fala sobre a "classe Deus" e a destaca como um excelente exemplo de violação das regras "as classes devem ser pequenas" ele usa para promover o Princípio da Responsabilidade Única ", começando na página 138.

O problema que tenho é que todas as minhas referências e citações são da mesma pessoa (Robert C. Martin) e da mesma pessoa / fonte. Disseram-me que, como ele é apenas uma visão, meu desejo de não usar "Classes dos Deuses" é inválido e não é aceito como uma prática recomendada padrão na indústria de software. Isso é verdade? Estou fazendo coisas erradas do ponto de vista técnico, tentando seguir os ensinamentos do tio Bob?

Objetos de Deus e Programação e Design Orientados a Objetos:

Quanto mais penso nisso, mais penso que isso é algo que você aprende quando estuda OOP e nunca é explicitamente chamado; Está implícito no bom design o meu pensamento (sinta-se à vontade para me corrigir, por favor, como quero aprender), o problema é que eu "sei" isso, mas nem todo mundo sabe, portanto, neste caso, não é considerado um argumento válido porque Estou efetivamente chamando isso de verdade universal quando, na verdade, a maioria das pessoas é estatisticamente ignorante, já que estatisticamente a maioria das pessoas não é programadora.

Conclusão:

Estou sem saber o que procurar para obter os melhores resultados adicionais, pois eles estão fazendo uma afirmação técnica e quero saber a verdade e poder prová-la com citações como um verdadeiro engenheiro / cientista, mesmo que Sou tendencioso contra objetos divinos devido à minha experiência pessoal com o código que os usou. Qualquer assistência ou citações seria profundamente apreciada.

O argumento para qualquer mudança de prática é feito através da identificação dos pontos problemáticos criados pelo design existente. Especificamente, você precisa identificar o que é mais difícil do que deveria por causa do design existente, o que é frágil, o que está quebrando agora, quais comportamentos não podem ser implementados de maneira simples como um resultado direto (ou até um pouco indireto) de a implementação atual ou, em alguns casos, como o desempenho sofre, quanto tempo leva para acelerar a atualização de um novo membro da equipe etc.

Segundo, o código de trabalho supera quaisquer argumentos sobre teoria ou bom design. Isso é verdade mesmo para códigos ruins, infelizmente. Portanto, você precisará fornecer uma alternativa melhor, o que significa que você, como defensor de melhores padrões e práticas, precisará refatorar para apresentar um design melhor. Encontre um plano estreito, do estilo marcador-bala, através do design existente e implemente uma solução que, talvez, para a iteração 1, mantenha a implementação do objeto god funcionando, mas adie a implementação real para o novo design. Em seguida, escreva um código que aproveite esse novo design e mostre o que você ganha por causa dessa alteração, seja desempenho, manutenção, recursos, correção de bugs ou condições de corrida ou redução da carga cognitiva para o desenvolvedor.

Muitas vezes, é um desafio encontrar uma área de superfície pequena o suficiente para atacar em sistemas mal arquitetados; pode levar mais tempo do que você gostaria de fornecer algum valor inicial, e o retorno inicial pode não ser tão impressionante para todos, mas você também pode trabalhar em encontrar alguns defensores de sua nova abordagem, se você a associar a membros da equipe que sejam pelo menos um pouco simpáticos.

Lamentar o Deus Objeto só funciona quando você está pregando para o coral. É uma ferramenta para nomear um problema e só funciona para resolvê-lo quando você tem um público receptivo sênior e motivado o suficiente para fazer algo a respeito. Fixar o objeto de Deus vence o argumento.

Como sua preocupação imediata parece ser a adesão de executivos, acho melhor você substituir o código que precisa ser um objetivo estratégico e vinculá-los aos objetivos de negócios pelos quais você é responsável. Eu acho que você pode argumentar que pode fornecer alguma orientação técnica, trabalhando primeiro em um pico técnico sobre o que você acha que deve ser feito para substituí-lo, de preferência envolvendo recursos de uma ou duas pessoas técnicas que têm reservas sobre o design atual.

Eu acho que você encontrou recursos suficientes para justificar seu argumento; as pessoas nessas reuniões prestarão atenção apenas ao resumo de sua pesquisa e deixarão de ouvir depois que você mencionar duas ou três fontes corroboradoras. Inicialmente, seu foco deve ser conseguir que o buy-off funcione com o problema que você vê, não necessariamente provando que alguém está errado ou que você está certo. Este é um problema social, não lógico.

Em uma função de liderança em tecnologia, você precisa vincular qualquer uma de suas iniciativas aos objetivos de negócios; portanto, o mais importante para defender seus executivos é o que o trabalho fará para esses objetivos. Como você também é considerado o "cara novo", não pode esperar que as pessoas joguem fora seu trabalho ou que rapidamente entrem na fila; você precisa criar confiança, provando que pode cumprir. Como uma preocupação de longo prazo, em um papel de liderança, você também precisa aprender a se concentrar nos resultados, mas não necessariamente estar ligado às especificidades do resultado. Agora você está lá para fornecer orientação estratégica, remover obstáculos táticos do progresso de sua equipe e oferecer orientação para sua equipe, e não vencer batalhas de credibilidade com seus próprios membros.

Tomar uma decisão de cima para baixo raramente será credível, a menos que você tenha alguma skin no jogo; se você estiver em uma situação semelhante novamente, concentre-se mais na construção de consenso em sua organização, em vez de aumentar quando sentir que a situação está fora de controle.

Mas, considerando onde você está agora, eu diria que sua melhor aposta é argumentar que sua abordagem trará benefícios mensuráveis ​​a longo prazo com base em sua experiência e que está alinhada com o trabalho de profissionais conhecidos como tio Bob e companhia. e que você gostaria de passar alguns dias / semanas liderando pelo exemplo em uma refatoração restrita do aspecto mais alto do que o necessário, para demonstrar como deve ser sua visão de bom design. No entanto, você precisará alinhar qualquer que seja o seu caso com objetivos de negócios específicos, além de suas preferências pessoais.

Primeiro, você precisa apresentar que qualquer organização mensurável precisa adotar as melhores práticas do setor. Dizendo que "simplesmente funciona para nós!" não pode ser medido, nem no tempo nem nos recursos, pois é simplesmente imprevisível. A engenharia de software é uma ciência tanto quanto qualquer outro campo da ciência, e esses conceitos foram estudados, pesquisados, testados e documentados.

1. o Objeto de Deus é um anti-padrão que afirma que

   Na engenharia de software, um antipadrão (ou antipadrão) é um padrão usado em operações sociais ou de negócios ou engenharia de software que pode ser comumente usado, mas é ineficaz e / ou contraproducente na prática.

2. Na conferência do Google IO de 2009 , esse assunto foi parcialmente explicado quando o padrão MVP foi explicado. Pode não ser relevante para o Objeto Deus, mas pode lhe dar munição.

3. Além disso, o uso desse antipadrão viola o princípio de responsabilidade única nos projetos orientados a objetos, que afirma que:

   toda classe deve ter uma única responsabilidade e essa responsabilidade deve ser totalmente encapsulada pela classe. Todos os seus serviços devem estar estreitamente alinhados com essa responsabilidade.

4. O blog Decaying Code também fala sobre isso e sobre sua solução.

5. Não podemos falar sobre o princípio da responsabilidade única sem falar sobre acoplamento de objetos .

   [...] acoplamento ou dependência é o grau em que cada módulo de programa depende de cada um dos outros módulos.

   Onde um sistema fortemente acoplado pode causar assembly of modules [to] require more effort and/or time [to maintain] due to the increased inter-module dependency.Um nível mais alto de acoplamento a objetos significa menos coesão e vice-versa. Os objetos de Deus são um bom exemplo de acoplamento rígido, pois eles sabem mais do que deveriam, sobrecarregando-os com responsabilidade, limitando muito a reutilização do código.

6. Ao projetar um aplicativo complexo, a simplicidade deve ser lembrada. Grandes problemas devem ser decompostos em outros menores, mais fáceis de gerenciar, testar e documentar. Isto é especialmente verdade em um paradigma orientado a objetos.

   Com esse argumento, voltamos ao argumento antipadrão, mas esse paradigma trata de padrões, representação de objetos do mundo real e, finalmente, encapsulamento de dados.

7. Você está certo quando diz que essas "boas práticas" são mais existentes nas salas de aula. No entanto, tenho experiências de ensino na faculdade (e em algumas universidades) e só vi esses princípios sendo ensinados nas universidades, especialmente nas faculdades de engenharia. O que é triste. Mas, como qualquer boa prática, aqueles que se esforçam para melhorar a si mesmos geralmente aprendem alguns padrões básicos de design e, eventualmente, entendem como mudar entre o acoplamento e a coesão.

   O que geralmente ensino aos alunos é que, pode parecer exigir mais esforços para adotar bons padrões de programação, mas sempre vale a pena a longo prazo. Um bom exemplo seria alguém pedindo a um programador que escrevesse uma função de classificação. O programador tem duas opções; 1) escreva uma função de classificação rápida de bolhas (menos de 5 minutos) que não será sustentável à medida que a lista de elementos crescer, ou 2) escreva um algoritmo de classificação mais complexo (também conhecido como otimizado) (classificação rápida etc.) que será dimensionado melhor com listas maiores.

Ah, aqui vou eu, fazendo outra pergunta antiga, mas acho que você não venceu esse argumento e aqui está o porquê.

Parece um problema cultural

Você é o gerente deles, mas não pode substituí-los e precisa ir até seus gerentes para fazer com que eles façam o que você acredita que eles deveriam estar fazendo, o que, neste caso, eu suponho que seja, pelo menos, parar com o deus objetos avançando. Parece-me um caso clássico de código que reflete a cultura em que nasceu. Em outras palavras, o objetivo de Deus é como essa empresa funciona. Deseja fazer algum tipo de mudança significativa? Você sempre está indo para o mesmo lugar, pois todas as decisões aparentemente precisam ser limpas no topo.

Tendo participado de várias tentativas fracassadas de limpeza de código legado e alterações de política de código, agora sou da opinião de que você não pode combater a cultura que tornou o código possível em primeiro lugar, quando essa cultura ainda está firmemente enraizada ou, pelo menos, combatendo a cultura é uma tarefa árdua e árdua que é improvável que alguém possa me pagar o suficiente ou me dar poder suficiente para sentir que foi um esforço que valeu a pena e que provavelmente teria sucesso novamente.

Antes que possa haver mudança, eles precisam ser motivados a mudar e, infelizmente, como programadores que se esforçam o suficiente para ler Stack ocasionalmente, é difícil entender que nem todos são motivados pelas mesmas coisas. Ganhei muitos argumentos racionais em minhas experiências, mas no final do dia a empresa sofre devs intelectualmente preguiçosos por um motivo.

Talvez as preocupações dos negócios tenham sido motivadas a pensar apenas no amanhã, e não na próxima semana ou nos próximos cinco anos (um cenário especialmente frustrante quando você é filho de imigrantes de um país que construiu um cofre de sementes no Ártico em caso de apocalipse). Talvez eles tenham medo de mudar. Talvez eles valorizem demais a antiguidade, a ponto de a cadeia de comando não ter sentido, mesmo quando eles têm que contratar de fora para contratar um líder ou gerente de equipe de desenvolvimento, porque reconhecem que ninguém na equipe de toda a vida cresceu o suficiente em seu tempo lá (ou porque os referidos levantadores não querem o risco associado à responsabilidade). Ou, e eu já vi isso, talvez seja o fenômeno muito real e deprimente da mediocridade se defendendo porque sabe no fundo que pode "

Como você lida com questões que estão finalmente enraizadas no medo ou em métricas quebradas para o sucesso? Vou lhe dizer isso, é preciso muito mais do que uma equipe de desenvolvedores de qualidade comprometida e você tinha muito menos do que isso no som da época em que este Q foi postado.

No evento não impossível que não é um problema intratável da cultura ...

Agora, assumindo que as pessoas no topo são muito receptivas à mudança, e estão realmente dispostas a confiar em você para fazê-lo, você realmente só precisa pontuar todos os seus argumentos com dinheiro e oportunidades perdidas.

Toda vez que leva mais tempo para treinar alguém novo nessa ridícula base de código, toda vez que leva mais tempo para modificar ou adicionar um novo recurso a alguma coisa, toda vez que fica proibitivamente difícil expor pontos de extremidade para outro sistema de uma empresa com a qual você deseja fazer parceria , está custando dinheiro. Muito dinheiro. O mais importante é que deixa uma janela aberta para que um concorrente menor e mais ágil entre, coloque-o em uma posição em que tudo o que você pode fazer é reagir a eles muito lentamente e, finalmente, arrebatar tudo.

Apenas reconheça que uma cultura particularmente teimosa e estúpida manterá o status quo a todo custo, mesmo que o teto físico real da empresa esteja de fato pegando fogo por causa disso.

Você pode citar alguns dos princípios mais básicos de POO, como acoplamento flexível e alta coesão. Um "objeto de Deus" parece que combina classes não relacionadas e tem baixa coesão.

Você sempre pode perguntar ao próprio tio Bob.

O fato é que é tão óbvio para as pessoas com algum sentido que, uma vez explicado, não precisa ser referenciado por vários autores. Só precisa haver uma fonte.

Outros termos que você pode querer começar ao procurar fontes são:

• SÓLIDO
• Lei de Deméter
• Grande bola de lama

Todos esses conceitos expressos relacionados podem gerar fontes de referência viáveis, mesmo que na verdade não o nomeiem como tal.

Em última análise, porém, você é o chefe. A razão para fazer isso é porque você diz isso e, embora seja considerado um bom gerente, você realmente deve estar preparado para justificar suas decisões; você fez isso e, se ainda houver resistência, o curso de ação correto é para sua equipe fazer o que é solicitado.

Como eu provo ou refuto objetos "deuses" que estão errados?

Você não pode.

Esse tipo de conjectura não é passível de prova matemática, e a prova matemática é o único tipo de prova que é sólida.

Mesmo se você tentar substituir a palavra emotiva "errado" por medidas quantificáveis ​​dos efeitos do uso de objetos divinos, você descobrirá que:

1. as medidas disponíveis são brutas,
2. existem poucos estudos confiáveis ​​em que essas medidas foram quantificadas para o código produzido por programadores profissionais
3. Existem poucos ou nenhum estudo credível em que construções de linguagem ou padrões de design (anti-) foram vinculados a essas medidas.

E isso está ignorando a questão de decidir quando um objeto em particular é um objeto "deus".

Na melhor das hipóteses, esses tipos de estudo só poderiam demonstrar uma correlação empírica. Não é uma prova genuína.

Na verdade, o que você está fazendo é debater os prós e os contras dos objetos "deus", com o objetivo de mudar as opiniões de outras pessoas ... e depois a prática de sua organização.

Não use palavras como "prova" ou as pessoas com quem você está debatendo podem rir na sua cara.

Você pode querer ver o guru da semana # 84 . É tudo sobre objetos divinos (monólitos) e como eles são ruins.

Extrair:

(Maior) Isola funcionalidade potencialmente independente dentro de uma classe [...] (Menor) Pode desencorajar a extensão da classe com novas funcionalidades.

Não tenho certeza se sua equipe está realmente interessada em acadêmico provar que "os objetos de Deus estão errados".

Do ponto de vista psicológico, sua abordagem de refatoração pode ser mal interpretada como um ataque à competência da equipe: "a equipe fez um mau trabalho", embora o programa esteja funcionando conforme o esperado.

O que você realmente quer fazer é lidar com os efeitos colaterais negativos de "código spagetti" e "objetos de Deus": custos explosivos para adicionar novos recursos devido ao aumento de erros causados ​​por efeitos colaterais.

Ser muito específico e fazer perguntas em vez de fornecer respostas pode ser mais útil:

manager > Why did implement the new tax-calculation schema took more than 4 weeks
team > because {reason a}
manager > And why was {reason a}?
team > because {reason b}
manager > And why was {reason b}?
...
team > because {reason z}
manager > what could we do to avoid {reason z} ?
team > refactor code