language agnostic - ¿Cuál es su Modus Operandi para resolver un problema(de programación)?

language-agnostic (30)

Creo que, ¿qué estoy buscando?
¿Qué método mejor resuelve este problema?
Implementarlo con lógica sólida - sin código
Pseudo código
codificar un corte áspero
ejecutar

Mientras resuelve cualquier problema de programación, ¿cuál es su modus operandi ? ¿Cómo arreglas un problema?
¿Escribes todo lo que puedas sobre los comportamientos observables del error o problema?

Llévame a través de la lista de verificación mental de las acciones que llevas a cabo.

(Como dicen: First, solve the problem. Then, write the code )

Lo pienso. Me tomo de unos minutos a unas pocas semanas para reflexionar sobre el problema y desarrollar un plan general de ataque.
Martillee una solución inicial. Esta solución probablemente esté medio cocida y es posible que uno o más aspectos no funcionen.
Refina esa solución. Siga trabajando en el problema hasta que tenga algo que resuelva el problema.
(y esto se puede hacer en cualquier paso del proceso) Haga preguntas sobre desbordamiento de pila para aclarar cualquier dificultad que tenga en este momento.

escribe el problema
pensar muy duro
escribe la respuesta

¡Nadie ha mencionado las tablas de verdad! Pero eso es probablemente porque generalmente solo son medianamente útiles;) (aunque su kilometraje puede variar) Usé uno por primera vez ayer en mis 8 años de programación.

Diagramar en pizarras o papel siempre me ha sido muy útil.

Agregue el problema a , espere de 5 a 10 minutos y ¡generalmente tendrá una solución brillante! :)

Cada problema que he tenido que resolver en una computadora ha tenido algo que ver con la solución de una tarea en el mundo real. Por lo tanto, aprendí a ver cómo lograría algo en el mundo real y lo correlacioné con el problema de la computadora.

Ejemplo:

Necesito hacer un seguimiento de las calificaciones de mis estudiantes y presentar una calificación final que es un promedio de todas las calificaciones durante el año.

Bueno, guardaría las calificaciones en un registro (base de datos) y tendría una página para cada alumno (FieldID de estudiante) y así sucesivamente ...

Cuando te enfrentas a errores muy extraños. De esta manera: JPA deja de funcionar después de redesplegarse en glassfish

Comienzo desde cero. Haz un nuevo proyecto. ¿Funciona? Sí. Comience a recrear los componentes de mi aplicación una sola vez. DB. Comprobar. Desplegar. Comprobar. Hasta que se quiebre. Continúa hasta que se rompa. Si nunca se rompe. De acuerdo. Acabas de recrear toda tu aplicación. Descartar de la anterior. Cuando se rompe Identificaste el problema exacto.

Dejo de trabajar en eso hasta mañana. Normalmente resuelvo mi problema en la ducha al día siguiente. Me parece alejarse del problema, y permitir que mi cerebro se despeje, permite una nueva perspectiva sobre el tema.

El pensamiento y aprendizaje pragmático de Andy Hunt tiene mucho que decir sobre esta cuestión.

Este algoritmo nunca me ha fallado:

Tomar acción. A menudo, simplemente sentarse allí y estar aterrorizado o molesto por el problema no ayudará a resolverlo. Además, a menudo, ninguna cantidad de pensamiento resolverá el problema. Entonces tienes que ensuciarte las manos y lidiar con el problema de frente.
Prueba. ¿Bajo exactamente qué condiciones, valores de entrada o estados, ocurre el problema? Haga un modelo mental de por qué estas condiciones particulares pueden causar el problema. Verifique condiciones similares que no causen el problema. Pon a prueba lo suficiente para que tengas una comprensión clara del problema.
Visualizar. Coloca el código de depuración, volca el contenido de la variable, el código de un solo paso, lo que sea. Haga cualquier cosa que aclare exactamente qué está pasando en dónde, dentro de las condiciones del problema.
Simplificar. Eliminar o comentar el código, introducir valores en variables, ejecutar determinadas funciones con determinados valores. Haga todo lo posible para llegar al meollo del problema cortando la paja o cosas que no tienen relevancia para el problema en cuestión. Copie el código en un proyecto separado y ejecútelo, si es necesario, para eliminar dependencias.
Aceptar. Un gran hombre dijo: "lo que quede, aunque sea improbable, debe ser la verdad". En otras palabras, después de simplificar tanto como pueda, lo que quede debe ser el problema, sin importar cuán extraño pueda parecer al principio.
Lógica. Doble, triple, comprueba la lógica del problema. ¿Tiene sentido? ¿Qué tendría que ser cierto para que tenga sentido? ¿Hay algo que te estás perdiendo? ¿Es incorrecto tu entendimiento del algoritmo? Si todo lo demás falla, rediseñe el problema.

Como complemento al paso 3, como último recurso, a menudo utilizo el método de búsqueda binaria para encontrar el código caprichoso. Simplemente comente la mitad del código y vea si el problema desaparece. Si lo hace, entonces debe estar en esa mitad (y viceversa). Mitad del código restante y continuar.

Estos son mis métodos priorizados

Analizar
a. Intenta encontrar el origen de tu problema
segundo. Definir el resultado deseado
do. Lluvia de ideas sobre soluciones
Probar el error (si no quiero analizar)
Google un poco alrededor de a. Por supuesto, mira a tu alrededor en
Cuando te enojes, aléjate de la PC por una taza de café
Cuando sigas enojado después de 10 tazas de café, ve a dormir una noche para pensar sobre el problema

CONSEJO DE ORO
Nunca te rindas. La persistencia siempre ganará

Estoy interpretando esto como arreglar un error, no un problema de diseño.

Aislar el problema. ¿Siempre ocurre? ¿Ocurre solo la primera vez que se ejecuta en un conjunto de datos nuevos? ¿Ocurre con valores específicos, pero no con otros?

¿El sistema está generando algún mensaje de error que aparece relacionado con el problema? Verifique que los mensajes de error no se generan cuando el problema no ocurre.

¿Ha habido algo cambiado recientemente? Esos son probablemente lugares para comenzar a buscar.

Identifique la brecha entre lo que sé que está funcionando (por ejemplo, puedo iniciar la aplicación e intentar hacer una consulta) y lo que sé que no está funcionando (por ejemplo, me da un error en lugar de los resultados esperados). Encuentre un punto intermedio en el código donde parece posible buscar un problema (¿esto contiene datos válidos en este punto?). Esto me permite aislar el problema de un lado u otro del punto que miré.

Lee los rastros de la pila. Si tiene un seguimiento de pila, busque la primera línea que mencione el código interno. El problema no está en tus bibliotecas. Tal vez lo sea, pero olvídate de eso posiblemente primero. El error está en tu código. No es un error en Java, no es un error en el cliente HTTP de apache commons, está en un código escrito en su organización.

Pensar. Piensa en algo que el sistema pueda estar haciendo y que pueda causar los síntomas que ves. Encuentre una forma de validar si eso es lo que está haciendo el sistema.

No hay posibilidad de que el error esté en tu código? Busca cualquier cosa que se te ocurra relacionada con Google. Tal vez sea un error en la biblioteca o una documentación deficiente que lo lleve a usarlo incorrectamente.

Lápiz, papel y una pizarra. Si necesita más organización, use una herramienta como MindManager .

Lógica.

Rompe el problema, usa tu propio cerebro y conocimiento de cada componente del sistema para determinar exactamente qué está sucediendo y por qué; luego, sobre la base de esto, descubrirá dónde no está el problema y, por lo tanto, determinará dónde debe estar.

Lo escribo en un pedazo de papel y comienzo con mi horrible diagrama de clase o diagrama de flujo. Luego lo escribo en notas adhesivas para dividirlo en "HACER".

1 nota adhesiva = 1 tarea. 1 nota adhesiva arrojada = 1 tarea terminada. Esto funciona muy bien para mí hasta ahora.

Lo siguiente se aplica a un error en lugar de construir un proyecto desde cero (pero incluso así podría hacer ambas cosas si fuera reformulado un poco):

Contexto : ¿Cuál es el problema a mano? ¿Qué está previniendo, haciendo mal o no haciendo?
Control : ¿Qué variables (en el amplio sentido de la palabra) están involucradas? ¿Se puede reproducir el problema?
Hipótesis : con suficientes datos sobre lo que está ocurriendo o requiriendo, es posible formular una hipótesis, es decir, dibujar una imagen mental del problema en cuestión.
Evaluar : ¿Cuánto esfuerzo, costo, etc. requerirá la corrección? Determine si es un tapón de muestra o un irritante menor. En este punto, puede ser demasiado pronto para decirlo, pero incluso eso es una forma de evaluación. Esto permitirá la priorización.
Plan : ¿cómo se abordará el problema? ¿Requiere especificaciones? Si es así, hazlo primero.
Ejecutar : AKA La parte divertida.
Prueba : AKA The not-so-fun-part.

Repita para la satisfacción. Finalmente:

Comentarios : ¿cómo llegó a ser de esta manera? ¿Qué nos llevas aquí? ¿Pudo haberse evitado esto y, de ser así, cómo?

EDITAR:

Realmente resumido, detener, analizar, actuar.

Mi método, algo analítico-sinético:

Cálmese. Tomar una respiración profunda. Enfoca tu atención en lo que vas a resolver. Esto puede incluir salir a caminar, limpiar la pizarra blanca, conseguir papel rayado y pedir lápices, algunos refrigerios, etc. Evite el estrés.
Comprensión de alto nivel del problema. En caso de que sea un error, ¿cuándo sucedió? en que circunstancias? Si se trata de una tarea nueva, trate de diferenciar qué resultados son necesarios. Recordar datos, evidencia, obtener descripciones de aceptación, tal vez documentación o una charla con alguien que sabe sobre el tema.
Configura el patio de pruebas. Intenta sentirte feliz con las herramientas necesarias. Use los datos recopilados en el paso anterior para automatizar algo, ojalá el error si ese es el caso, de lo contrario, fallarán algunas pruebas.
Comience a sintetizar, resuma lo que sabe, reflejando eso en el código. Ejecutando una vez y una vez más. Si no está contento con los resultados, vuelva al paso dos con ideas renovadas, diverja más: tal vez aplique herramientas (en orden de costo) que ayudaron antes, es decir, dividir y conquistar, depurar, multihilo, desmontar, perfil, herramientas de análisis estático. métricas, etc. Entre en este ciclo hasta que pueda aislar el problema y pasar la prueba por teléfono .
Ahora es el momento de arreglarlo, pero tiene todas las herramientas configuradas. No será tanto problema. Comience a escribir código, aplique refactorización, disfrute describiendo su solución en los documentos.
Haga que alguien pruebe su solución. Ella eventualmente puede llevarte al paso 2 pero está bien. Refina tu solución y vuelve a implementarla.

No puedo creer que nadie haya publicado esto ya:

Escribe tu problema en y deja que otras personas lo resuelvan por ti.

Parafraseando a Douglas Adams, la programación es fácil. Solo necesita mirar una pantalla en blanco hasta que su frente sangra. Para las personas que son aprensivas con sus frentes, mi arquitecto ideal y la construcción para los problemas más grandes sería algo como esto. (Para problemas más pequeños, como George Jempty, solo puedo recomendar el algoritmo de Feynman ).

Lo que escribo está redactado en una configuración comercial en el sitio, pero hay análogos en los equipos de código abierto o distribuidos. Y no puedo fingir que todos, o incluso la mayoría, de los proyectos funcionan de esta manera. Esta es solo la serie de eventos con los que sueño y, ocasionalmente, suceden.

Obtenga una advertencia avanzada y concisa de cómo se verá el problema. Esta no es la reunión final completa, sino una discusión informal. La incertidumbre en ciertos detalles de especificación está bien, siempre y cuando el cliente (o gerente) sea honesto. Luego tome una hoja de papel o un editor de texto, y trate de condensar lo que aprendió hasta cinco puntos esenciales, y luego intente condensarlos en una sola oración. Sea feliz de que pueda imaginar el (los) problema (s) central (es) a resolver sin hacer referencia a ninguna parte de su documentación.
Piénselo por un par de horas, tal vez jugando con código y creación de prototipos, pero no con la arquitectura completa: incluso debería hacer otras cosas, si tiene tiempo o salir a caminar. Es fantástico si puedes aprender sobre un trabajo una hora antes de la hora local para poder tomar una decisión al mediodía del día siguiente, de modo que puedas dormir con él. Dedique su tiempo a buscar bibliotecas potenciales, marcos de trabajo, estándares de datos. Intente vincular al menos dos idiomas o recursos (por ejemplo, Javascript en HTML generado por PHP, u obtenga un código auxiliar de Python que indique RPC a un servicio web). Completa los problemas centrales; ampliar los detalles; aleja para asegurarte de que toda la forma sea distinta y tenga sentido.
Envíe cualquier pregunta al cliente o gerente mucho antes de una reunión para analizar tanto el problema como la solución propuesta. Invite a todos los interesados y a sus compañeros de programación a lo largo de la conveniencia (y con la satisfacción de su gerente). Explíqueles el problema, tal como lo ve, luego proponga su solución. Explica todo lo que puedas; eche los detalles técnicos a su audiencia, pero también permita que sus explicaciones llenen más detalles en su propio modelo mental.
Itere en 2 y 3 hasta que todos estén felices. La felicidad es específica del dominio. Su industria puede requerir diagramas UML y citas de artículos de línea, o podría estar contento con algo anotado en una pizarra con un marcador de secado en seco casi invisible. Asegúrese de que todos tengan las mismas expectativas de lo que está por construir.
Cuando su cliente o gerente esté contento de que comience, borre todo. Cierre Twitter, mensajería instantánea, IRC y correo electrónico durante una hora o dos. Comience con la estructura general tal como la ve. Coloque algo de su código de prototipo y vea si se siente bien. Si no lo hace, cambie la estructura lo antes posible. Pero sobre todo, asegúrese de que sus colegas le den un par de horas de espacio. Intenta no luchar contra los incendios en este momento. Comience con buen corazón y ánimo, e interés en el proyecto. Cuando estés atascado más tarde, te alegrará la claridad que surgió de esas primeras horas.

La forma en que su programación procede desde allí depende de lo que realmente es y de las tareas que el código final debe realizar. Y la forma en que finalmente se crea el código, y qué recursos externos se usan, siempre estará dictado por su experiencia, preferencia y conocimiento del dominio. Pero brinde a su proyecto y a su equipo de partes interesadas el inicio más esperanzador, emocionante y comprometido que pueda.

Pregunta relacionada que puede ser útil:

Puntos de vista, conceptos o maneras de pensar sobre los problemas que todo novato debería saber

Pregunta: ¿Cómo se come un elefante?

Respuesta: un bocado a la vez.

Primero, voy a una tienda de bicicletas ; u otro

Una vez que imagino que nadie inventó esa bicicleta en particular,

Determine las estructuras de datos apropiadas para el dominio y el problema, y luego haga un mapa de los algoritmos necesarios para tratar con esas estructuras de datos de la forma que necesite.
Divide y conquistaras. Resolver subconjuntos del problema

Probablemente una sobresimplificación burda:

CONCEBIR. PLAN. EJECUTAR. http://i36.tinypic.com/wv8vif.png

Pero en realidad, esto es 100% cierto.

CONCEBIR

¿Qué estás sin una idea? Puede tener un problema, pero primero debe definirlo de manera más explícita. Tienes una pizza congelada que quieres comer. ¡Tienes que cocinar esa pizza! En la programación, esta suele ser su sesión de tormenta de ideas para encontrar una solución desde la cadera. Aquí decides cuál es tu enfoque.

PLAN

Bueno, por supuesto, ¡necesitas cocinar esa pizza! ¡Pero cómo! ¿Usaras el horno? No. Demasiado fácil . Desea construir una cocina solar, para que pueda comer esa pizza congelada en cualquier lugar donde el sol le otorgue poder para hacerlo. Esta es tu fase de diseño. Esta es su fase de lápiz y papel. Aquí es donde comienza a formar un método de implementación cohesivo y paso a paso.

EJECUTAR

Bueno, vas a construir un horno solar para cocinar tu pizza congelada; usted ha decidido . AHORA HAZLO . Escribir código Prueba. Cometer. Refactor Cometer.

Responda estas tres preguntas en este orden:

Q1: ¿Cuál es el resultado deseado?
No me importa si se trata de una servilleta con garabato. Quiero algo tangible que me muestre cómo se supone que debe ser el resultado final. Si no llego al menos hasta aquí, entonces me detengo.

Q2: ¿Cuál es la entrada?
Descubro en qué datos estoy ingresando. De dónde provienen estos datos. Qué fórmulas puedo necesitar ¿Qué dependencias podría haber en A pasando antes que B ? Qué permisos son necesarios para obtener estos datos. Luego hago la pregunta 3.

Q3: ¿hay suficiente entrada para crear la salida?
Si la respuesta es No , vuelvo a la Q2 y obtengo más información de quien me la puede dar.

Para problemas muy grandes, los descompongo en Fases y aplico Q1 Q2 y Q3 a cada fase.

Siempre tomo un problema primero en un blog. sería un buen lugar para comenzar. ¿Por qué perder el tiempo reinventando la rueda cuando otra persona ya pudo haber resuelto un problema similar en el pasado? En todo caso, obtendrá algunas buenas ideas para resolverlo usted mismo.

Una técnica que me gusta usar para proyectos realmente grandes es entrar en una sala con una pizarra y un montón de notas cuadradas de post-it.

Escriba sus tareas en las Notas Post-it y luego empiece a pegarlas en la pizarra.

A medida que avanza, puede reemplazar las tareas que son demasiado grandes con múltiples notas.

Puede cambiar notas para cambiar el orden en que ocurren las tareas.

Use diferentes colores para indicar diferente información; A veces uso un color diferente para indicar cosas sobre las que necesitamos investigar más.

Esta es una gran técnica para trabajar con un equipo. Todos pueden ver el panorama general y pueden contribuir de una manera altamente interactiva.

Uno de mis ex colegas tenía un Modus Operandi único. Cada vez que enfrenta un problema de programación difícil (por ejemplo, problema de Knapsack o algún tipo de problema de optimización no estándar) se drogaría con weed, reclamando su capacidad para visualizar el estado complejo (como el de la función recursiva haciendo operaciones en el conjunto pasado en la pila ) fue muy mejorado. La única dificultad, al día siguiente, no podía entender su propio código. Entonces eventualmente le mostré TDD y dejó de fumar ...

Yo uso el método científico :

Basado en la información disponible sobre el problema de programación, se me ocurre una hypothesis sobre cuál podría ser el motivo.
Luego diseño / pienso un experimento que rechazará o confirmará la hipótesis. Esto podría estar observando algo en un depurador o salida de pantalla / archivo. O cambiando el programa un poco.
Si la hipótesis es rechazada, repita 1. La información reunida en 2. puede ayudar a encontrar una nueva hipótesis.
Si la hipótesis se confirma, la hipótesis puede refinarse o volverse más específica (repetir 1.). O quizás ya esté claro cuál es el problema.

Esta forma dirigida de encontrar el problema es mucho más efectiva que cambiar las cosas al azar, observar lo que sucede e intentar (incorrectamente) usar estadísticas.

Aléjese de la computadora y agarre un poco de papel y un bolígrafo o un lápiz si lo prefiere.

Si estoy cerca de la computadora, trato de programar una solución en ese momento y normalmente no funciona bien o simplemente es una porquería. La pluma y el papel me obligan a pensar un poco más.

Google es ideal para buscar mensajes de error y problemas comunes. En algún lugar, alguien generalmente ha encontrado su problema antes y ha encontrado una solución.
Lápiz y papel. Pseudo Código y diagramas de flujo de trabajo.
Habla con otros desarrolladores al respecto. Realmente ayuda cuando tienes que obligarte a simplificar el problema para que alguien más lo entienda. También pueden tener otro ángulo. A veces es difícil ver el bosque a través de los árboles.
Ir a caminar. Saca tu cabeza del problema Da un paso atrás y trata de ver una imagen más amplia de lo que quieres lograr. Asegúrate de que el problema que "tratas" de resolver sea el que "necesitas" resolver.
Una gran pizarra es genial para trabajar. Úselo para escribir flujos de trabajo y relaciones. Hable sobre lo que está sucediendo con otro miembro del equipo
Siga adelante. Hacer algo más. Deje que su subconsciente trabaje en el problema. Permita que la solución venga a usted.