¿Debería preocuparme si resuelvo muchos de mis problemas de la misma manera?

Realmente disfruto programar juegos y crear / juegos de rompecabezas. Me encuentro diseñando muchos de estos problemas de la misma manera y, en última instancia, utilizando una técnica similar para programarlos con los que me siento realmente cómodo.

Para darle una breve idea, me gusta crear gráficos donde los nodos se representan con objetos. Estos objetos contienen datos como coordenadas, posiciones y, por supuesto, referencias a otros objetos vecinos. Los colocaré a todos en una estructura de datos y tomaré decisiones sobre esta información en un "ciclo de juego".

Si bien este es un breve ejemplo, no es exacto en todas las situaciones. Es solo una forma con la que me siento realmente cómodo. ¿Es esto malo?

No, esta bien.

El objetivo de la programación práctica es encontrar soluciones que posiblemente sean útiles en muchos desarrollos similares. Acabas de encontrar uno.

No puede ni debe crear soluciones diferentes solo por el hecho de que sean diferentes. Pero definitivamente debe tener una mirada crítica a sus soluciones cada vez y preguntarse si aún son buenas o si la industria ha progresado desde entonces y necesita alinearse con ellas en consecuencia.

Si funciona bien, llámelo patrón de diseño. Si no es así, pero no lo sabes mejor, es el antipatrón de martillo dorado.

Siendo realistas en nuestros trabajos diarios, tendemos a plantearnos una buena cantidad de problemas bastante similares.

En estas situaciones, seguir con lo que sabes puede ser bueno. He visto más ejemplos de malas soluciones de personas que implementan algo que no entendieron que alguien usa bien una técnica no ideal.

Si conoce algo bien, es probable que pueda flexionarlo según sea necesario y que su implementación sea sólida y efectiva. Es probable que esas cosas no sean ciertas desde sus primeros intentos de nuevas técnicas.

Pero la otra cara es que si todo lo que tienes es un martillo, todo parece un clavo. Deberías estar haciendo cosas para hacerte consciente de las alternativas y cuando quizás estés presionando demasiado a tus favoritos.

¿Quizás elija algunos cambios no urgentes / no críticos y utilícelos para ponerse al día con soluciones alternativas?

Buena pregunta, y tengo que admitir que esto es algo que también me persigue.

Cuando esta bien? Haga un análisis de rendimiento de su código: si ve que está en O (log n) u O (n) u O (n log n) y, como tal, el problema se puede asignar a estructuras de datos conocidas, generalmente está bien.

¿Cuándo no está bien? Su complejidad de tiempo o espacio es O (n ^ 2) o peor, o el problema por definición es NP completo. En estas situaciones, debe aplicar un poco de heurística, aplicar el conocimiento de otros dominios, etc.

Ejemplo rápido: en el diseño de chips, elegir cómo organizar las puertas en el circuito para una potencia mínima es NP-complete. Solo los gráficos por sí solos no le harán mucho bien, aunque es una necesidad. Necesita leer material adicional, mucho interdisciplinario a veces y aplicar el conocimiento en su dominio. Por ejemplo, los algoritmos genéticos (algoritmos que imitan los cruces genéticos y la mutación, como se define en biología 101) tienen mucha aplicación en el diseño de chips de hardware.

No necesariamente, si es una buena forma de resolverlos :)

Por lo general, cuando trabajo en una "solución", voy por estas cosas en orden:

• simplicidad ,
• reutilización ,
• y solo la última actuación .

No es que el rendimiento no importe: diseño con el rendimiento en mente, pero sin llevarlo demasiado lejos (así que si necesito hacer llamadas a un método de utilidad como StringUtils.isEmpty o algo así en el mismo flujo, gané ' t mente). Si se necesita rendimiento (caso de negocio o problema de experiencia del usuario), entonces voy por un enfoque diferente al simple y reutilizable. Ser pragmático

Aunque parezca extraño, al codificar en C, me importa mucho más el rendimiento que cuando se codifica en Java ... Fuerza de hábito :))

Mientras el problema se resuelva de manera eficiente, no hay que preocuparse.

Creo que el gráfico es un diseño adecuado para diseñar juegos para representar decisiones \ elecciones. Solo tenga en cuenta que probablemente esto se puede refinar y hacer más eficiente, y esta puede no ser la mejor solución para otros dominios.

Si funciona, está bien.

Si le preocupa confiar demasiado en una sola técnica, intente como ejercicio encontrar variaciones de algún problema resuelto que haga que su solución sea inviable. Puntos adicionales si puede generalizar los cambios para definir el espacio de aplicabilidad de su proceso habitual.

Si resuelves el problema, está bien. Y no importa de qué manera hasta que no genere más problemas.

"Developer Art" en realidad tiene la respuesta correcta si su objetivo es producir un producto. Y si su "fábrica" ​​produce los productos que satisfacen, entonces genial.

Pero...

Si alguna vez quieres aprender nuevas (y potencialmente mejores) formas de hacer las cosas, tienes que cambiar las cosas. Esto producirá fallas, pero solo a través de la falla se aprende realmente. Y a través de este nuevo aprendizaje, es posible que pueda producir un software aún mejor y más atractivo.

Esto en realidad está respaldado a través de la investigación neurológica. Ahí vas.