Como realmente descobrir o que deve ser feito no design orientado a objetos?

Primeiro um aviso: eu realmente não sei se essa pergunta se encaixa neste site, mas ainda acho uma questão relevante não apenas para mim, mas para outras pessoas que são iniciantes. Se a pergunta puder ser aprimorada para caber aqui, aponte os comentários. Se não se encaixar, informe-me também e, se possível, informe onde isso pode ser discutido, porque não encontrei bons fóruns para isso.

Aprendi a programar em 2009 quando estudei PHP. Mais tarde, em 2012, mudei para C # e .NET. Enfim, codificar não é o problema, escrever algoritmos não é problema meu. Meu problema real é saber o que deve ser codificado para atingir um requisito e onde ele deve ser codificado.

A maioria dos cursos disponíveis na Web aborda como - como escrever código em um determinado idioma, como usar alguns conjuntos de APIs, etc. Esse não é o meu ponto aqui.

Nestes anos, li muito sobre várias coisas: análise e design orientados a objetos, padrões de design, design orientado a domínio e assim por diante. Entendo, por exemplo, os princípios do SOLID, algumas das principais idéias do DDD, como a necessidade de envolvimento de especialistas em domínio, o desenvolvimento de uma linguagem onipresente e assim por diante. Ousaria dizer que tenho uma base teórica pelo menos razoável.

Mas quando se trata de praticar, sinto que sou um desastre. Algum tempo atrás, eu precisava continuar o desenvolvimento de um sistema financeiro que já estava sendo desenvolvido por outra pessoa. É esse tipo de "sistema antigo" desenvolvido com C # e WinForms. Foi a primeira vez que escolhi um projeto com complexidade de domínio real, com muitas regras de negócios e assim por diante.

Confesso que, quando recebo os requisitos na maioria das vezes, penso "como isso pode ser feito?" - Eu não tenho idéia de como começar a trabalhar nos requisitos para descobrir o que deve ser feito. Minhas principais confusões, acredito, são o que devo codificar, que classes, interfaces e para onde vai cada parte da lógica, em qual classe cada coisa deve estar. O problema é que não sei por onde começar.

Na maioria das vezes, com muito pensamento, acabo com algumas idéias, mas nunca sei como julgar se minha ideia está correta ou não.

Quero dizer, não acho que seja uma falta de teoria, pois disse que li sobre um monte de coisas sobre arquitetura de software e orientação a objetos que me foram recomendadas, mas não ajudou muito a identificar o que deve ser feito na prática. .

Então, como posso aprender a realmente fazer design orientado a objetos? O que eu quero aprender é: dado que os requisitos sabem como começar a trabalhar neles em um processo que leva a descobrir o que precisa ser feito e aonde cada parte do código pertence. Como também posso aprender a julgar se minha ideia está correta ou não?

Acredito que explicar completamente isso como resposta aqui não seria possível. O que eu estou procurando, no entanto, que possa estar de acordo com o estilo do site, são respostas que dão uma visão geral e apontam algumas referências (livros, cursos on-line, etc.) que podem ser usadas para expandir as idéias e realmente aprender essas coisas.

Então, como posso aprender a realmente fazer design orientado a objetos? O que eu quero aprender é: dado que os requisitos sabem como começar a trabalhar neles em um processo que leva a descobrir o que precisa ser feito e aonde cada parte do código pertence. Como também posso aprender a julgar se minha ideia está correta ou não?

Bem, primeiro de tudo, pare de pensar no design orientado a objetos como correto. É como pensar no inglês como correto.

O paradigma orientado a objetos não está correto. Tem certas vantagens e desvantagens. É um ideal. Não é o nosso único. É melhor que nada, mas certamente não é tudo.

Eu tenho codificado por décadas agora. Eu estudei essas coisas por quase tanto tempo quanto as idéias existiram. Eu ainda estou aprendendo o que isso significa. Os especialistas ainda estão aprendendo o que isso significa. Todo o nosso campo tem menos de 100 anos.

Então, quando você pega uma pilha de requisitos e cria um código que os satisfaz, mas parece que o código que você escreveu é uma bagunça trágica, você não está sozinho. Código de trabalho é simplesmente o primeiro passo para obter um ótimo código. Código que não só funciona, mas que outros podem ler e entender facilmente. Código que pode ser adaptado rapidamente quando os requisitos mudam. Código que faz você querer sentar e dizer "Uau, isso é tão simples".

O problema é que não estamos sendo pagos para fazer tudo isso. Fazemos tudo isso porque somos profissionais. Temos que fazer tudo isso quando o chefe não está olhando, porque sempre há um prazo. Mas queremos voltar daqui a 5 anos e dizer aos novatos: "Ah, sim, eu escrevi isso. Ainda funciona né? Legal."

Como se chega lá? Prática. Não aceite QUALQUER idéia de design com fé. Alguém não cala a boca sobre como o design orientado a eventos simplifica esse design? Não tem certeza se eles estão certos? Crie seu próprio projeto de brinquedo em casa que use o padrão de observador. Mexa com isso. Tente encontrar coisas com as quais não ajuda.

Ler. Questão. Teste. Repetir.

Quando você chegar ao ponto de fazer isso por 80% da sua vida, ficará tão confuso quanto eu.

Confesso que, quando recebo os requisitos na maioria das vezes, penso "como isso pode ser feito?" - Eu não tenho idéia de como começar a trabalhar nos requisitos para descobrir o que deve ser feito. Minhas principais confusões, acredito, são o que devo codificar, que classes, interfaces e para onde vai cada parte da lógica, em qual classe cada coisa deve estar. O problema é que não sei por onde começar.

Eu costumava me sentir da mesma maneira. Então eu descobri a alegria de refatorar. Esteja disposto a adaptar os designs à medida que codifica. Tentar resolver tudo no papel antes do tempo é a maneira mais difícil de fazê-lo. Escreva um código que possa ser provado errado, prove errado e corrija-o.

O desenvolvimento de software se resume à entrega do software em funcionamento, dentro do prazo e do orçamento, atendendo a todos os seus critérios de aceitação. Supondo que você tenha conseguido fazer isso, a qualidade percebida do código ou de sua estrutura é uma preocupação secundária.

O problema, é claro, é que escrever um novo código greenfield tende a ser muito mais barato e mais fácil do que manter o código legado; portanto, em vez de ficar muito preocupado com a qualidade ou a arquitetura do código, lembre-se de que seu problema real é a manutenção.

Normalmente, o código é considerado sustentável quando os custos, tempo e riscos associados à alteração desse código são proporcionalmente baixos o suficiente para que a correção de bugs ou a implementação de alterações nos requisitos ainda sejam econômicas e, ao implementar essas alterações, você não está perpetuando uma "espiral da morte" "da entropia de código.

Por outro lado, o código é considerado insustentável quando você não pode alterar ou refatorar com confiança, sem um sério risco de quebrar algo ou gastar tempo / dinheiro excessivo para garantir que nada seja quebrado - ou seja, quando o tempo, custo e risco envolvidos no trabalho com esse código são desproporcionalmente alto em comparação com os benefícios de fazer alterações (ou seja, seu empregador ou cliente não está perdendo dinheiro adicionando novos recursos, corrigindo bugs, etc.)

Lembre-se de que mesmo a bagunça de espaguete mais diabólica pode ser potencialmente mantida se você tiver provisões suficientes ao redor da bagunça para se proteger contra mudanças de quebra (embora esses casos sejam raros). O problema com uma bagunça de espaguete é que protegê-la contra mudanças quebradas tende a ser bastante cara e ineficiente - especialmente se você estiver fazendo isso retrospectivamente.

Talvez a maneira mais confiável de garantir que você tenha escrito código de manutenção seja escrever (sempre que possível) um conjunto adequado de testes automatizados ao mesmo tempo (além de aproveitar ao máximo todas as outras ferramentas de análise estática disponíveis).

Você não precisa seguir particularmente uma metodologia de desenvolvimento rigorosa, como TDD / BDD, para terminar com testes automatizados suficientes para permitir refatoração; você só precisa o suficiente para proteger o código contra alterações significativas acidentais no futuro.

Se seu código é coberto por testes automatizados, você pode relaxar sobre o design e a estrutura sabendo que está coberto por esses testes; você pode refatorar agressivamente posteriormente ou até jogá-lo fora e começar de novo.

Isso levanta a questão de como escrever código facilmente testável; esse é geralmente o principal argumento para seguir os princípios do SOLID; de fato, a marca registrada do código que segue os princípios do SOLID é que é fácil e economiza tempo / tempo escrever testes de unidade.

Obviamente, às vezes você também não tem tempo para escrever testes de unidade; no entanto, se você escreveu todo o seu código, tendo em mente a pergunta "Como escrevo testes automatizados para isso?" (mesmo que você não tenha implementado esses testes), provavelmente também conseguiu encontrar um design que seja razoavelmente sustentável.