Executando verificação de segurança...
Em resposta a Aprendizado Superficial: falhei em uma entrevista por não ter lido um livro
2
DevTiltado

Minha contrib:

Cara continuando um pouco a discussão, isso vai além dos princípios S.O.L.I.D, não sei se você chegou a entrar neste ponto, mas estes principios estão intimamente ligados ao processo de arquitetar um sistema, dentro deste processo estudamos algo que é chamado lei de Conway, essa lei nos diz que o design de um sistema é influenciado pela estrutura organizacional do grupo que o produz.

O caso que você passou reflete exatamente isso, peguemos pelo seu exemplo, a entidade Email para o ator RH tem um significado, para o ator Marketing significa outra coisa, e por que utilizar de um mesmo endpoint para enviar emails fere diretamente o principio S do S.O.L.I.D ? pq cada ator enxerga a entidade email de maneira diferente, isso implica que as regras de negócio para cada ator é diferente, enquanto a equipe de marketing utilizam de recursos que o email nos fornece, e ve cada email como um novo lead de capitação de clientes, o setor de RH os enxerga como possíveis candidatos, cada processo é diferente um do outro, em termos de objetivos, restrições e resultados.

Sobre a parte de duplicação de código nós entramos em Design, onde podemos utilizar dos principios estabelecidos e amplamente aceitos como Gang of Gour por exemplo para remediar essa questão.

Caso se interesse em aprofundar seus conceitos sobre arquitetura de sistemas recomendo 2 leituras fascinantes:

"Fudamentos de Arquitetura de Software: Uma Abordagem de Engenharia", Neal ford e Mark Richards

"Padrões de Aruitetura de Aplicações Corporativas", Martin Fowler

Ambos os livros nos dão um visão abrangente sobre como um software enterprise é desenvolvido, e sobre como um arquiteto de software deve pensar afim de alcançar seus objetivos.

Bons estudos!!

Carregando publicação patrocinada...
3
Oletros

Meus 2 cents extendidos,

Mas aqui acho que a pergunta na entrevista foi capciosa.

Numa situacao real, conversando com os atores e entendendo a especificacao - poderia ficar claro que cada um iria tratar o envio de forma diferente, dai a necessidade de separacao e conformidade SOLID.

Mas a pergunta foi (como apresentada): "dois departamentos diferentes que precisam enviar email, podem usar o mesmo endpoint ?" - ok, ate dou o desconto que um "depende" poderia ser uma resposta mais cuidadosa, mas olhando apenas o cenario estrito da pergunta, nao fica clara a ofensa ao SOLID porque nao ficou claro que cada ator teria uma interpretacao diferente no uso da classe.

Se a espeficacao nao eh clara, pode gerar interpretacoes (e por isso acho que perguntas de entrevistas/testes/etc precisam ser o mais inequivocas possivel).

Meu ponto eh: os principios SOLID fazem sentido ? Sim - mas o uso correto das especificacoes e pleno entendimento da situacao/contexto onde serao aplicados tambem precisa ser atendido.

2
DevTiltado
  • Autor
    Autor

Ai você tem um ponto muito bom, concordo plenamente que a pergunta ficou muito esparsa para o cenário descrito, em um cenário destes tomar o máximo de cuidado possível ao se afirmar algo é pouco rsrs, creio que em casos assim brecha é aberta para que o entrevistado retorne a pergunta ao próprio entrevistador afim de obter informações mais precisas, isso além de te colocar em um resultado provavelmente maior do que a expectativa, demonstra uma capacidade de lidar de forma criativa com situações difíceis, pois com algo tão abstrato assim existe a possibilidade de múltiplos cenários, pois em recurso(endpoint) que é literalmente apenas enviar o e-mail sem uma lógica e objetivos por trás não fere os princípios, pois ficaria algo genérico, mas nesse sentido concordo que fizeram uma questão um tanto capciosa.

2
victorVN

Olá, pessoal. Obrigado pelas respostas. Com certeza lerei os livros indicados e seguirei os conselhos nas próximas entrevistas.

Durante esta entrevista eu tentei tirar algumas dúvidas acerca da proposta que eles trouxeram, mas acredito que isso não me aproximou da resposta que os entrevistadores queriam. Talvez porque a minha compreensão sobre os princípios que eles estavam questionando era totalmente diferente da deles.

Neste post procurei não focar no processo seletivo, no conteúdo da pergunta ou na minha atuação na entrevista. Acredito que todos estes pontos poderiam ser explorados em outras postagens para abrir o debate.

A pergunta talvez tenha sido capciosa como pontuou o amigo, ou talvez eu não tenha tido maturidade para fazer as pergunta corretas (acredito fortemente que isso influenciou bastante rs) ou ainda os entrevistadores tinham uma convicção daquilo que é correto com base no conhecimento deles e no que eles aplicam no projeto e eu não pude corresponder.

Acho que todas essas reflexões cabem mas o que tentei trazer aqui foi meu espanto com a quantidade de material na internet que, na minha opinião, não tem o rigor técnico que tem um livro (a depender do livro, claro).

Ao ler o livro eu fui exposto a um ponto de vista que não tive em todos os mais de 10 artigos que li do assunto. É quase como se nenhum destes artigos tivessem sido baseados nos livro, ou como se um artigo tivesse "alimentado" o outro, gerando uma rede de informação que não diverge, não apresenta outro ponto de vista e portanto cria um consenso.

O consenso neste caso é de que ao separar duas funcionalidades em classes diferentes você já está atendendo ao princípio S de SOLID. Ao ler o livro do Uncle Bob eu vi que esse consenso não existe, uma outra interpretação do princípio me foi apresentada o que me levou a questionar a qualidade de algumas fontes.