Resumo do problema:

Resumindo, eu herdei uma base de código e uma equipe de desenvolvimento que não tenho permissão para substituir e o uso de Objetos Divinos é um grande problema. Daqui para frente, quero que façamos a refatoração das coisas, mas estou sendo rejeitado pelas equipes que querem fazer tudo com os Objetos de Deus “porque é mais fácil” e isso significa que eu não teria permissão para refatorar. Eu recuei, citando meus anos de experiência em desenvolvimento, que sou o novo chefe que foi contratado para saber dessas coisas, etc, e também o representante de vendas de contas de empresas offshore terceirizadas, e isso agora está no nível executivo e minha reunião é amanhã e quero entrar com muita munição técnica para defender as melhores práticas porque acho que será mais barato no longo prazo (e eu pessoalmente acho que é isso que preocupa o terceiro) para a empresa.

Meu problema é de nível técnico, sei que é bom a longo prazo, mas estou tendo problemas com o ultracurto prazo e o prazo de 6 meses e, embora seja algo que “sei”, não posso “provar referências e recursos citados fora de uma pessoa (Robert C. Martin, também conhecido como Tio Bob), pois é isso que me pedem para fazer, conforme me disseram, tendo dados de uma pessoa e apenas uma pessoa (Robert C. Martin) não é bom o suficiente como um argumento.

Pergunta:

O que são alguns Os recursos que posso citar diretamente (título, ano de publicação, número da página, citação) por conhecidos especialistas na área que dizem explicitamente que o uso de Objetos / Classes / Sistemas de “Deus” é ruim (ou bom, já que estamos procurando o solução mais tecnicamente válida)?

Pesquisa que já fiz:

  1. Tenho vários livros aqui e pesquisei em seus índices o uso das palavras “objeto de deus” e “classe de deus”. Achei estranhamente que quase nunca é usado e a cópia do livro GoF que tenho, por exemplo, nunca usa (pelo menos de acordo com o índice à minha frente), mas 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 concordo com o que diz, 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 muito antigo para ser válido pelas pessoas com quem estou debatendo esses pontos técnicos como argumento eles estão fazendo é que “já foi considerado ruim, mas ninguém poderia provar, e agora o software moderno diz que os objetos” deus “são bons de usar”. Pessoalmente, acredito que essa afirmação está incorreta, mas quero provar a verdade , seja o que for.
  3. Em “Agile Principles, Patterns and Practices in C #” de Robert C Martin (ISBN: 0-13-185725-8, capa dura) whe na página 266 afirma “Todo mundo sabe que classes de deus são uma má ideia. Não queremos concentrar toda a inteligência de um sistema em um único objeto ou função. Um dos objetivos do OOD é o particionamento e a distribuição do comportamento em muitas classes e muitas funções. – E continua dizendo que às vezes é melhor usar God Classes de qualquer maneira, às vezes (citando microcontroladores como exemplo).
  4. Em Robert C Martin “s” Clean Code: A Handbook of Agile Software Craftsmanship “página 136 (E somente esta página) fala sobre a” classe de Deus “e a chama de exemplo primordial de violação da regra” as classes deveriam ser pequenas “que ele usa para promover o Princípio da Responsabilidade Única” a partir da página 138 .

O problema que tenho é que todas as minhas referências e citações vêm da mesma pessoa (Robert C. Martin) e venho da mesma pessoa / fonte. Disseram-me que, porque ele é apenas uma visão, meu desejo de não usar “Aulas de Deus” é inválido e não é aceito como uma prática recomendada padrão na indústria de software. Isso é verdade? Estou fazendo coisas erradas de uma perspectiva técnica ao tentar seguir os ensinamentos do Tio Bob?

Objetos de Deus e programação e design orientado a objetos:

Quanto mais penso nisso, mais acho que é mais algo que você aprende quando estuda OOP e nunca é explicitamente mencionado; é implícito para o bem design é o meu pensamento (sinta-se à vontade para me corrigir, por favor, como eu quero aprender), o problema é que eu “sei” isso, mas nem todo mundo sabe, então, neste caso, não é considerado um argumento válido porque estou efetivamente chamando ele é apresentado como uma verdade universal quando, na verdade, a maioria das pessoas o ignora estatisticamente, já que estatisticamente a maioria das pessoas não é programadora.

Conclusão:

Não sei o que pesquisar para obter os melhores resultados adicionais para citar, uma vez que eles estão fazendo uma afirmação técnica e eu quero saber a verdade e ser capaz de prová-la com citações como um verdadeiro engenheiro / cientista, mesmo que eu seja preconceituoso contra objetos divinos devido à minha experiência com o código que os utilizou. Qualquer ajuda ou citações seriam profundamente apreciadas.

Comentários

  • Peça a documentação de objetos de Deus como uma boa prática.
  • Fugir! Você não ‘ não quer trabalhar lá.
  • Defina sua compreensão do ” Objeto Deus ” e como se relaciona com a sua pergunta. Você gasta 4 parágrafos dizendo que God Class não é ‘ t um termo padrão na literatura. Então por que você está usando? Se você usar termos padrão da indústria e puder mostrar como esses conceitos se aplicam ao seu projeto atual, você pode convencer algumas pessoas do seu ponto de vista. Usar palavras inventadas em uma reunião de negócios só vai minar seu argumento. Existem termos padrão da indústria – você não é ‘ a primeira pessoa a ver um pesadelo de tudo-é-global ou de objeto único, ou o que quer que esteja tentando descrever.
  • Você ‘ está faltando o termo ” antipattern “. Fazer uma pesquisa no Google por ” antipadrão de objeto deus ” retorna toneladas de páginas sobre os motivos pelos quais eles ‘ é ruim.
  • Você não deve ‘ estar atacando o objeto deus, mas os problemas que ele cria. Tipo: nós temos um acoplamento muito forte entre tudo e uma mudança em A requer também mudanças em B, C e D. Então, para ajudar contra isso, ‘ iremos extrair classes. Ou: queremos que o código esteja em uma estrutura de teste e não podemos ‘ fazer isso, o que vamos fazer? Além disso, tente evitar o uso do termo ” Deus “, as pessoas não receptivas vão pensar que você ‘ re-usando hipérboles.

Resposta

O caso para qualquer mudança de prática é feito identificando os pontos problemáticos criado pelo design existente. Especificamente, você precisa identificar o que é mais difícil do que deveria ser por causa do design existente, o que é frágil, o que está quebrando agora, quais comportamentos não podem ser implementados de uma maneira simples como resultado direto (ou mesmo indireto) de a implementação atual ou, em alguns casos, como o desempenho é afetado, quanto tempo leva para trazer um novo membro da equipe para a velocidade, etc.

Em segundo lugar, o código de trabalho supera qualquer argumento sobre teoria ou bom design Isso é verdade mesmo para códigos ruins, infelizmente. Então, você terá que fornecer uma alternativa melhor, o que significa que você, como defensor de melhores padrões e práticas, precisará refatorar para descobrir um design melhor. Encontre um plano de estilo marcador estreito através do design existente e implemente uma solução que, talvez, para a iteração um, mantenha a implementação do objeto deus funcionando, mas adia a implementação real para o novo design. Em seguida, escreva algum código que tire proveito desse novo design e mostre o que você ganhou com essa mudança, 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 demorar mais do que você gostaria para entregar algum valor inicial, e o retorno inicial pode não ser tão impressionante para todos, mas você também pode trabalhar para encontrar alguns defensores de sua nova abordagem se formar parceria com membros da equipe que sejam pelo menos um pouco simpáticos.

Lamentar o objeto de Deus só funciona quando você está pregando para o coro. É 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. Consertar o objeto Deus ganha a discussão.

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

Acho que você encontrou recursos suficientes para justificar seu argumento; as pessoas nessas reuniões só prestarão atenção ao resumo de sua pesquisa e deixarão de ouvir depois que você mencionar duas ou três fontes corroboradoras.Seu foco inicial deve ser fazer com que a aprovação resolva o problema que você vê, não necessariamente provar que outra pessoa está errada 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 às metas de negócios, então o mais importante para apresentar seu caso aos executivos é o que trabalho fará para esses objetivos. Como você também é considerado o “cara novo”, não pode simplesmente esperar que as pessoas joguem fora seu trabalho ou que caiam na linha rapidamente; você precisa construir alguma confiança, provando que pode entregar. 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 se apegar às especificações do resultado. Agora você está lá para fornecer orientação estratégica, remover obstáculos táticos ao progresso de sua equipe e oferecer orientação a ela, não vencer batalhas de credibilidade com os membros de sua própria equipe.

Tomar uma decisão de cima para baixo raramente seja confiável, a menos que você tenha alguma aparência no jogo; se você estiver em uma situação semelhante novamente, você deve se concentrar mais na construção de consenso dentro de sua organização, em vez de escalar 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 de longo prazo com base em sua experiência e que está de acordo com o trabalho de profissionais conhecidos como tio Bob e cia., e que você gostaria de passar alguns dias / semanas liderando pelo exemplo em uma refatoração limitada do aspecto mais alto custo-benefício, para demonstrar como deve ser sua visão de um bom design. No entanto, você precisará alinhar qualquer que seja o seu caso a objetivos de negócios específicos além de suas preferências pessoais.

Comentários

  • Bom ponto sobre ser um problema social. Deve ser por isso que há tantos códigos mal escritos e aplicativos mal projetados por aí.
  • +1 por amarrá-los com ‘ linguagem de negócios ‘ como tal; procure torná-lo o mais relevante possível para o seu público. Se você ‘ estiver falando com executivos, faça fale sobre como o padrão de código tem um link direto com manutenção e desempenho, e discuta como isso se relaciona com as finanças gerais do projeto, estabilidade de longo prazo e assim por diante. Parece que você ‘ fui contratado devido ao seu conhecimento; lembre-se disso. (Apenas não ‘ não se torne um gerente idiota que pensa ele sempre sabe o que é melhor – mas, neste caso, você ‘ está 100% correto.)
  • +1 para ” código de trabalho supera qualquer argumento sobre teoria ou bom design. ” Algo que frequentemente esquecemos em nossa busca para um código perfeito.
  • Ótima resposta, muita sabedoria para aspirantes a líder de equipe.

Resposta

Primeiro, você precisa apresentar que qualquer organização mensurável precisa adotar as práticas recomendadas do setor. Dizendo que “simplesmente funciona para nós!” não pode ser medido, nem em tempo nem em 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 God Object é 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 comerciais ou engenharia de software que pode ser comumente usado, mas é ineficaz e / ou contraproducente na prática.

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

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

    cada classe deve ter uma única responsabilidade, e essa responsabilidade deve ser totalmente encapsulado pela classe. Todos os seus serviços devem estar estreitamente alinhados a essa responsabilidade.

  4. O 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 o objeto acoplamento .

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

    Onde ter 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 de objetos significa menos coesão, e vice-versa. Objetos de Deus são um bom exemplo de acoplamento estreito, pois sabem mais do que deveriam, sobrecarregando-os com responsabilidade e limitando muito a capacidade de reutilização do código.

  6. Ao projetar um aplicativo complexo, simplicidade deve vir à mente. Grandes problemas devem ser decompostos em problemas menores, mais fáceis de gerenciar, testar e documentar. Isso é especialmente verdadeiro em um paradigma orientado a objetos.

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

  7. Você tem razão 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 em universidades, especialmente em faculdades de engenharia. O que é triste. Mas, como qualquer boa prática, aqueles que se esforçam para melhorar a si próprios geralmente aprendem alguns padrões de design básicos e, eventualmente, entendem como se misturar entre o acoplamento e a coesão.

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

Comentários

  • Linguagens de programação orientadas a objetos geralmente exigem que, se dois assemblies de origem independentes forem responsáveis para diferentes aspectos do comportamento de um objeto ‘, instâncias de objetos independentes precisarão ser criadas para encapsular esses comportamentos. Infelizmente, embora em muitos casos as subdivisões mais lógicas de funcionalidade entre conjuntos de código não ‘ t coincidam com a subdivisão mais lógica de funcionalidade entre instâncias de objeto, eu ‘ não vi muita discussão sobre como distinguir os dois tipos de subdivisão.
  • Eu acredito que este é um pouco fora do tópico desta questão. Nós ‘ não estamos falando sobre o antipadrão de Objeto Divino, aqui, mas sobre acoplamento e coesão de código, que é um tópico muito amplo e subjetivo.

Resposta

Oh, lá vou eu, perguntando sobre outra velha questão, mas vou adivinhar que você não ganhou este argumento e aqui está por quê.

Parece um problema cultural

Você é o gerente, mas você não pode substituí-los e você tem que ir aos seus gerentes a fim de levá-los a fazer o que você acredita que eles deveriam estar fazendo, o que, neste caso, suponho, é pelo menos terminar com os objetos divinos avançando. Parece-me um caso clássico de código espelhando a cultura em que nasceu. Em outras palavras, o objeto de Deus é como essa empresa funciona. Quer fazer qualquer tipo de mudança significativa? Você está sempre indo para o mesmo lugar por isso em última análise, uma vez que todas as decisões aparentemente precisam ser aprovadas no topo. rivy a várias tentativas fracassadas de limpezas de código legado e mudanças de política de código Eu agora sou da opinião de que você não pode lutar contra a cultura que tornou o código possível em primeiro lugar quando essa cultura ainda está firmemente enraizada ou, pelo menos, a cultura de luta está um trabalho árduo e árduo que “é improvável que alguém possa me pagar o suficiente ou me dar força suficiente para sentir que foi um esforço que vale a pena ter sucesso novamente.

Antes que possa haver mudança, eles têm que estar motivados para mudar e, infelizmente, como programadores que se importam o suficiente para ler Stack ocasionalmente, é difícil para nós entender que nem todo mundo é motivado pelas mesmas coisas. Eu ganhei muitos argumentos racionais em minhas experiências, mas no final do dia a empresa sofre de desenvolvedores intelectualmente preguiçosos por um motivo.

Talvez as preocupações de negócios tenham sido motivadas a pensar apenas no amanhã, em vez de na próxima semana ou daqui a 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 mudanças.Talvez eles valorizem a antiguidade excessivamente, a ponto de a cadeia de comando não significar nada, mesmo quando eles têm que contratar de fora para trazer um líder ou gerente de equipe de desenvolvimento, porque eles reconhecem que ninguém em sua equipe inteira cresceu o suficiente em seu tempo lá (ou porque os ditos vidas não querem o risco associado à responsabilidade). Ou, e eu vi isso, talvez seja o fenômeno muito real e deprimente da mediocridade se defendendo porque sabe no fundo que pode ” competir com qualidade e quando há tolice suficiente para contornar, é impossível descobrir a quem culpar quando tudo regularmente desmorona.

Como você luta contra problemas que, em última análise, estão enraizados no medo ou métricas quebradas para o sucesso? Vou lhe dizer uma coisa, é preciso muito mais do que uma equipe de desenvolvimento de qualidade comprometida e você tinha muito menos do que isso no momento em que este Q foi postado.

No evento não impossível, que não é um problema cultural intratável …

Agora, supondo que estejam no topo são muito receptivos à mudança e estão realmente dispostos a confiar em você para fazê-lo. Na verdade, você só precisa pontuar todas as suas discussões com dinheiro e oportunidades perdidas.

Cada vez que leva mais tempo para treinar alguém novo nesta base de código ridícula, toda vez que leva mais tempo para modificar ou adicionar um novo recurso a algo, toda vez que se torna proibitivamente difícil expor endpoints para outro sistema de uma empresa com a qual você deseja fazer parceria, está custando dinheiro. O mais importante é que deixa uma janela aberta para um concorrente menor e mais ágil entrar, colocando você em uma posição em que tudo o que você pode fazer é reagir a eles muito devagar e, por fim, arrancar tudo de você.

Apenas reconheça que uma cultura particularmente teimosa e estúpida manterá o status quo a todo custo, mesmo se o teto físico da empresa estiver de fato pegando fogo porque dele.

Comentários

  • Saí da empresa logo depois. eles tentaram me contratar em tempo integral e fazer com que eu me mudasse de Seattle para NY para aceitar a oferta; Eu basicamente disse a eles ” De jeito nenhum, ‘ não vou me mudar para NY quando a equipe que eu gerenciaria estiver em Bellevue, WA ” e nesse ponto eu basicamente atravessei a rua e consegui um emprego na MSFT até encontrar algo melhor.
  • @honestduane Sim, esse conjunto de expectativas sozinho fala muito. Bom para você no GTFO.

Resposta

Você poderia citar alguns dos princípios OOP mais básicos, como acoplamento fraco e alta coesão. Um “objeto de Deus” soa como um par de classes não relacionadas e tem baixa coesão.

Resposta

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

A questão é que é tão óbvio para pessoas com algum senso que, uma vez explicitado, não precisa ser referenciado novamente por uma infinidade de autores. Só precisa haver uma fonte.

Outros termos com os quais você pode querer começar ao procurar por fontes são:

  • SÓLIDO
  • Lei de Demeter
  • Grande bola de lama

Todos esses expressam conceitos relacionados que podem gerar fontes de referência viáveis, embora não os chamem dessa forma.

Em última análise no entanto, você é o chefe. A razão para fazer isso é porque você diz isso e, embora para ser 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 é sua equipe fazer o que for mandado.

Comentários

  • ” se ainda houver resistência, o curso de ação correto é sua equipe fazer o que ‘ disse ” Talvez o curso de ação correto seja desistir em vez de deixar sua equipe infeliz ..?
  • O gerente ‘ s a decisão foi adequadamente justificada e se a equipe não ‘ não concordar, então o problema é com a equipe. O OP foi contratado por sua experiência e não pôde usá-lo para beneficiar a empresa porque os colegas conseguiram ‘ t se comportar de maneira razoável não ‘ t aceitável. Vamos ‘ s virar sua afirmação de cabeça para baixo – por que não ‘ os membros resistentes da equipe desistem se sua visão do trabalho é incompatível com o da empresa?
  • Ponto justo. Depende de como você deseja comandar a equipe. Mas, em minha experiência, forçar as pessoas a fazerem coisas contra sua vontade só leva ao sofrimento. Eu preferiria ver os Objetos de Deus em toda a base do código do que uma equipe de desenvolvimento miserável. Talvez a resposta seja enviá-los para um treinamento. Todo mundo adora um curso de treinamento. Vencer / Vencer.
  • O desenvolvedor / gerente líder / o que quer que seja deve absolutamente tomar todas as medidas razoáveis para garantir que a equipe mantenha um bom relacionamento de trabalho entre si. Se o treinamento adicional for útil, considere-o sem dúvida como uma opção – mas isso parece ser um caso de ignorância intencional, e dizer a alguém que ela precisa ser treinada para entender sua ideia quando o que eles pensam que ‘ O que fazer é discordar, ao invés de não entender, pode sair pela culatra. Tenho dificuldade em imaginar maneiras de lidar com pessoas que não ‘ querem aprender.

Resposta

Como posso provar ou refutar que os objetos “deuses” estão errados?

Você não pode.

Este 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” com medidas quantificáveis dos efeitos do uso de objetos divinos, você descobrirá que:

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

E que está ignorando a questão de decidir quando um determinado objeto é 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.

O que você está realmente fazendo é debater os prós e os contras dos objetos “deuses” com o objetivo de mudar as opiniões de outras pessoas “ … e então a prática de sua organização.

Não use palavras como “prova”, ou as pessoas com quem você está debatendo podem rir da sua cara.

Resposta

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

Extrair:

(Principal) Ele isola funcionalidade potencialmente independente dentro de uma classe […] (Menor) Pode desencorajar a extensão da classe com nova funcionalidade […]

Resposta

Não tenho certeza se sua equipe está realmente interessada na prova acadêmica de 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 la: “a equipe fez um trabalho ruim”, 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”: explodir custos para adicionar novos recursos devido ao aumento de bugs causados por efeitos colaterais.

Está muito fazer perguntas específicas 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

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *