Devo ficar preocupado se resolver muitos dos meus problemas da mesma maneira?

Eu realmente gosto de jogos de programação e criadores / jogos de quebra-cabeças. Eu me pego criando muitos desses problemas da mesma maneira e, finalmente, usando uma técnica semelhante para programá-los com os quais estou realmente confortável.

Para fornecer uma breve visão, eu gosto de criar gráficos nos quais os nós são representados com objetos. Esses objetos contêm dados como coordenadas, posições e, é claro, referências a outros objetos vizinhos. Vou colocá-los todos em uma estrutura de dados e tomar decisões sobre essas informações em um "loop de jogo".

Embora este seja um breve exemplo, não é exato em todas as situações. É apenas uma maneira de me sentir realmente confortável. Isso é ruim?

Não, está bem.

O objetivo da programação prática é encontrar soluções que possivelmente serão úteis em muitos desenvolvimentos semelhantes. Você acabou de encontrar um.

Você não pode e não deve criar soluções diferentes apenas para que sejam diferentes. Mas você definitivamente deve ter uma visão crítica de suas soluções a cada vez e se perguntar se elas ainda são boas ou se o setor progrediu desde então e você precisa se alinhar com elas de acordo.

Se funcionar bem, chame-o de padrão de design. Se não, mas você não sabe melhor, é o antipadrão do martelo de ouro.

Realisticamente, em nossos empregos do dia a dia, tendemos a apresentar um número razoável de problemas semelhantes.

Nessas situações, manter o que você sabe pode ser bom. Eu já vi mais exemplos de soluções ruins de pessoas implementando algo que eles não entendiam que alguém usava bem uma técnica não ideal.

Se você conhece algo bem, é provável que você possa flexioná-lo conforme necessário e que sua implementação será sólida e eficaz. Provavelmente essas coisas não serão verdadeiras em suas primeiras tentativas de novas técnicas.

Mas o outro lado é que, se tudo o que você tem é um martelo, tudo parece um prego. Você deve fazer coisas para se conscientizar de alternativas e quando talvez esteja levando demais seus favoritos.

Talvez escolha algumas alterações não urgentes / não críticas e use-as para se atualizar com soluções alternativas?

Boa pergunta, e tenho que admitir que isso também é algo que me assombra.

Quando isso está bom? Faça uma análise de desempenho do seu código - se você perceber que está em O (log n) ou O (n) ou O (n log n) e, como tal, o problema pode ser mapeado para estruturas de dados conhecidas, geralmente você está bem.

Quando isso não está bem? Sua complexidade de tempo ou espaço é O (n ^ 2) ou pior, ou o problema por definição é NP completo. Nessas situações, você precisa aplicar um pouco de heurística, aplicar conhecimentos de outros domínios etc.

Exemplo rápido: no design de chips, a escolha de como organizar os portões no circuito para obter o mínimo de energia é NP-complete. Apenas os gráficos por si só não farão muito bem, embora seja necessário. Você precisa ler material adicional, muitas vezes interdisciplinar às vezes, e aplicar o conhecimento em seu domínio. Por exemplo, algoritmos genéticos (algoritmos que imitam cruzamentos genéticos e mutações, conforme definido na biologia 101) têm muita aplicação no design de chips de hardware.

Não necessariamente, se é uma boa maneira de resolvê-los :)

Normalmente, ao trabalhar em uma "solução", busco estas coisas em ordem:

• simplicidade ,
• reutilização ,
• e apenas o último desempenho .

Não que esse desempenho não importe: eu o desenvolvo com o desempenho em mente, mas sem ir muito longe (por isso, se eu precisar fazer chamadas para um método utilitário como StringUtils.isEmpty ou algo parecido no mesmo fluxo, vencerei ' mente). Se o desempenho for necessário (caso de negócios ou problema de experiência do usuário), adotarei uma abordagem diferente da abordagem simples e reutilizável. Ser pragmático.

Estranhamente, ao codificar em C, eu me preocupo muito mais com o desempenho do que ao codificar em Java ... Força do hábito :))

Enquanto o problema estiver sendo resolvido de maneira eficiente, não será necessário se preocupar.

Eu acho que o gráfico é um design adequado para projetar jogos para representar decisões \ escolhas. Lembre-se de que provavelmente isso pode ser refinado e tornado mais eficiente, e essa pode não ser a melhor solução para outros domínios.

Se funcionar, está tudo bem.

Se você se preocupa em usar uma única técnica, tente, como exercício, apresentar variações de algum problema resolvido que tornaria sua solução impraticável. Pontos extras se você puder generalizar as alterações para definir o espaço de aplicabilidade do seu processo usual.

Se você resolver o problema, é bom. E não importa como, até que não crie mais problemas.

"Developer Art" realmente tem a resposta correta se seu objetivo é produzir um produto. E se a sua "fábrica" ​​produz os produtos que satisfazem, então esfrie.

Mas...

Se você quiser aprender novas (e potencialmente melhores) maneiras de fazer as coisas, precisará mudar as coisas. Isso produzirá falhas, mas somente através da falha alguém realmente aprenderá. E com esse novo aprendizado, você poderá produzir um software ainda melhor e mais atraente.

Na verdade, isso é feito através de pesquisas neurológicas. Então lá vai você.