Fico continuamente sobrecarregado por grandes projetos, uma vez que eles atingem um certo nível de complexidade. Quando chego a um certo ponto de um projeto, meu progresso diminui e me vejo constantemente refazendo meus passos e resolvendo todos os tipos de confusão.

Fiquei muito bom em refatorar devido a essa minha fraqueza. E eu sempre tento decompor meus objetos em objetos menores e mais fáceis de administrar. Essa fraqueza provavelmente também me levou a prestar muita atenção ao design adequado das coisas.

Sei que, se conseguir dividir meus problemas em outros menores, poderei realizar sem problemas. Uma estratégia que vem à mente é o desenvolvimento orientado a testes. O que mais eu posso fazer?

pare de pensar no código

comece a pensar em camadas, recursos, módulos, serviços e outras abstrações de nível superior

você está ficando sobrecarregado porque está pensando em um nível muito baixo

Simplificar o complexo é fácil ; espere, pense que é o contrário.

Todo mundo luta com isso, não há uma solução direta que tenha extrema eficácia.

Como você não listou isso nas suas perguntas, minha sugestão seria:

Concentre-se na coesão funcional via:

O princípio de responsabilidade única declara que todo objeto deve ter uma única responsabilidade e que a responsabilidade deve ser totalmente encapsulada pela classe. Todos os seus serviços devem estar estreitamente alinhados com essa responsabilidade.

Se você pesquisar no Google entre os resultados da primeira página, encontrará dois ótimos recursos:

• " Princípio da responsabilidade única ", de Robert C. Martin (fevereiro / 2002): Este princípio discute a necessidade de colocar coisas que mudam por diferentes razões em diferentes classes.
• " Lei de Curly: faça uma coisa ", de Jeff Atwood (março / 2007): O Princípio da Responsabilidade Única diz que uma classe deve ter um e apenas um motivo para mudar.

O que é coesão na ciência da computação?

Coesão é uma medida de quão fortemente relacionadas ou focadas são as responsabilidades de um único módulo. Conforme aplicado à programação orientada a objetos, se os métodos que atendem a uma determinada classe tendem a ser semelhantes em muitos aspectos, diz-se que a classe tem alta coesão. Em um sistema altamente coeso, a legibilidade do código e a probabilidade de reutilização aumentam, enquanto a complexidade é mantida sob controle.

A coesão diminui se : - As funcionalidades incorporadas em uma classe, acessadas através de seus métodos, têm pouco em comum. - Os métodos realizam muitas atividades variadas, geralmente usando conjuntos de dados de granulação grosseira ou não relacionados.

As desvantagens da baixa coesão (ou "coesão fraca") são: - Maior dificuldade na compreensão dos módulos. - Maior dificuldade em manter um sistema, porque alterações lógicas no domínio afetam vários módulos e porque alterações em um módulo exigem alterações nos módulos relacionados. - Maior dificuldade em reutilizar um módulo, porque a maioria dos aplicativos não precisará do conjunto aleatório de operações fornecido por um módulo.

Se você tiver alguma dúvida me avise.

Decomponha os recursos no menor item possível. Por exemplo, um único campo em um formulário. Escolha a mais arriscada ou de alta prioridade e siga em frente como se fosse uma simples correção de bug, não um grande projeto. É verdade que você acabará refatorando mais tarde, mas pelo menos estará avançando.

Pela minha experiência, você respondeu sua própria pergunta com o comentário sobre o TDD. Para mim, muitas vezes senti o mesmo que você, o rápido sucesso rápido rapidamente se tornou atolado em pequenos detalhes quando o sistema atingiu um determinado tamanho. Descobri com o TDD que isso ajudou porque você podia lidar com cada parte do sistema como pequenos pedaços, sabendo que o restante do sistema deveria ou deveria continuar funcionando conforme você o deixava. Eu também acho que, com o TDD, isso ajuda a garantir que seu sistema seja claramente dividido em partes menores que possam ser testadas independentemente.

Algumas pessoas são boas em projetar programas modulares e facilmente compreensíveis, mas a maioria dos programadores não possui esse recurso, em menor ou maior grau. Não conheço nenhum livro, procedimento ou prática que possa transformar um dos primeiros tipos de programadores em outro, exceto, possivelmente, por muita experiência. Mas nem tenho certeza disso.

O ponto principal é que a maioria dos programadores lutará para se elevar acima do medíocre, alguns poucos conseguirão ficar bem (que é onde eu me colocaria e talvez 50% dos programadores profissionais (digamos) na indústria de IB), e muito pequena minoria será excelente. Devo dizer que nunca na minha longa carreira conheci um desses excelentes :-)

Eu acho que muitas pessoas tentam criar soluções em excesso. Eles adotam a abordagem "Adão e Eva", quando apenas um pouco mais prática simplificaria bastante as coisas.

Classes especializadas não são más, são a consequência natural do design de software de som.

Muitos programadores, na minha opinião, não conseguem entender isso e não há nenhum livro que conheça que torne isso claro.

Outra coisa que certamente ajuda é o TDD, que permite entender "como" você usará a classe na prática e, em muitos casos, pode salvar o dia, porque mostra eventuais problemas / limitações no início do dia.

Por último, outra coisa MUITO importante que eu procuraria se fosse você são os padrões de design. Padrões de design são como as pessoas mais inteligentes que você ou eu resolvem problemas de programação. A idéia por trás dos padrões, adivinhe ?, é que eles não devem ser usados ​​como livros de receitas, receitas que você acaba de lançar, mas com atenção e compreensão do domínio do aplicativo em primeiro lugar.

Um uso sábio do padrão reduzirá bastante a quantidade de detalhes que você precisa gerenciar.

Uma boa biblioteca de padrões de design projetada para atender às suas próprias necessidades será inestimável. Vamos ver um exemplo muito simples apenas para colocar as coisas em contexto:

imagine que você tem um formulário no qual, quando um botão é pressionado, outros formulários precisam se atualizar. Este é um padrão típico de "observador". Você tem um assunto e vários observadores, que se registram no assunto. Por que você precisa implementar uma interface? Você pode simplesmente adicionar os métodos, ou melhor ainda, usar uma interface para os observadores e uma lista genérica para o assunto. Agora você tem o melhor dos dois mundos: independência para os observadores e nada de coisas estranhas sobre o assunto.

Espero que faça sentido para você!

Andrea

O problema da velocidade e legibilidade do desenvolvedor pode surgir quando negligenciamos a necessidade de abstração. Em algumas das grandes bases de código em que trabalhei, o inimigo mais comum foi a quantidade de classes especializadas que possuem funcionalidades muito semelhantes que causam inchaço no código. Se dermos um passo para trás e entendermos os requisitos como um todo, não como partes do aplicativo, muitas abstrações virão à nossa mente.

Alguns passos simples que me ajudaram

• Use o analisador de similaridade (como o Simian) para encontrar blocos de código duplicados na base de códigos. Muito código duplicado significa menos abstração.
• Monitore o tamanho das classes e métodos, grandes classes e métodos significam poucos serviços ou controladores se tornando deuses.
• Torne os testes de unidade / integração obrigatórios, dê a você a confiança necessária para refatorar e também atua como uma especificação.
• Uma retrospectiva quinzenal com a empresa para entender se os termos técnicos / comerciais / de domínio que eles usam estão refletidos nos nomes das classes. Isso ajuda a entender e obter nomes para coleções de primeira classe, em vez de representar como conjuntos e listas simples. Algumas abstrações nas quais nunca pensamos também aparecerão quando nos sentamos com os empresários.