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

13

Realmente disfruto programando juegos y creadores de rompecabezas / juegos. 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 brindarle una breve descripción, me gusta crear gráficos donde los nodos están representados con objetos. Estos objetos contienen datos como coordenadas, posiciones y, por supuesto, referencias a otros objetos vecinos. Los colocaré todos en una estructura de datos y tomaré decisiones sobre esta información en un "bucle de juego".

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

    
pregunta Bryan Harrington 07.12.2010 - 11:00

10 respuestas

26

No, está 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 puedes y no debes crear soluciones diferentes solo por el hecho de que sean diferentes. Pero definitivamente debería tener una mirada crítica a sus soluciones cada vez y preguntarse si siguen siendo buenas o tal vez la industria ha progresado desde entonces y debe alinearse con ellas en consecuencia.

    
respondido por el user8685 07.12.2010 - 11:03
12

Si funciona bien, llámelo patrón de diseño. Si no lo hace, pero no lo sabes bien, es el martillo dorado antipattern.

    
respondido por el user281377 07.12.2010 - 11:47
5

De manera realista, en nuestros trabajos cotidianos, tendemos a plantearnos una gran cantidad de problemas bastante similares.

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

Si sabe algo bien, es probable que pueda hacerlo 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ía estar haciendo cosas para estar al tanto de las alternativas y cuando quizás esté presionando demasiado a sus favoritos.

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

    
respondido por el Jon Hopkins 07.12.2010 - 11:06
4

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

¿Cuándo está esto 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, por lo general 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, la elección de cómo organizar las puertas en el circuito para una potencia mínima es NP-completa. Solo los gráficos solos no le servirán de nada, 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, tal como se definen en la biología 101) tienen muchas aplicaciones en el diseño de chips de hardware.

    
respondido por el Fanatic23 07.12.2010 - 14:51
3

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

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

  • simplicidad ,
  • reutilización ,
  • y solo duran rendimiento .

No es que el rendimiento no importe: diseño pensando en el rendimiento, pero sin presionarlo demasiado (así que si necesito hacer llamadas a un método de utilidad como StringUtils.isEmpty o algo así en el mismo flujo, No me importará). Si el rendimiento es, entonces, necesario (caso de negocio o problema de experiencia del usuario), opto por un enfoque diferente al simple y reutilizable. Ser pragmático.

Por extraño que parezca, cuando codifico en C, me importa mucho más el rendimiento que cuando codifico en Java ... Fuerza de hábito :))

    
respondido por el haylem 07.12.2010 - 15:10
2

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

    
respondido por el Manoj R 07.12.2010 - 11:21
2

Creo que el gráfico es un diseño adecuado para diseñar juegos que representen decisiones y elecciones. Solo tenga en cuenta que probablemente esto puede refinarse y hacerse más eficiente, y puede que esta no sea la mejor solución para otros dominios.

    
respondido por el Gaurav 07.12.2010 - 12:19
2

Si funciona, está bien.

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

    
respondido por el Javier 07.12.2010 - 15:30
2

Si solucionas el problema es bueno. Y no importa de qué manera hasta que no genere más problemas.

    
respondido por el Dainius 07.12.2010 - 17:01
0

"Arte de desarrollador" en realidad tiene la respuesta correcta si tu objetivo es producir un producto. Y si su "fábrica" produce los productos que satisfacen, entonces se enfrían.

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 ellas, uno realmente aprende. Y a través de este nuevo aprendizaje, podrá producir un software aún mejor y más convincente.

Esto está realmente respaldado a través de la investigación neurológica. Así que ahí tienes.

    
respondido por el ElGringoGrande 19.03.2012 - 00:26

Lea otras preguntas en las etiquetas