Cómo resolver cualquier problema de programación

Hola a todos!

Hoy, su atención está invitada a traducir, a su manera, un artículo irremplazable que lo ayudará a abordar correctamente incluso los conocimientos tradicionales más insidiosos y no triviales, que a primera vista no comprende. Lo principal es no rendirse y formular preguntas de manera inteligente. El Sr. Justin Fuller del Bank of America describe amablemente cómo hacerlo bien.



Que tengas una buena lectura!

Así que este día ha llegado. Tal vez este es tu primer día de trabajo, o tal vez has estado trabajando en este lugar durante diez años, no importa. Le sucede a todos: finalmente te encuentras con una tarea que simplemente no entiendes.

Que hacer ¿Solo comenzar y esperar que todo funcione solo? ¿O admitirle al jefe que no puedes hacer esto porque no lo entiendes?

¡Creo que has adivinado que la respuesta correcta no es ni una ni la otra!

Noté que en la programación, como en cualquier otra profesión, es casi imposible vivir una semana laboral (y a veces un día laboral) sin tener que enfrentar una tarea completamente incomprensible.

Pero no te preocupes! Hay buenas noticias No solo puede resolver este problema, sino que también puede beneficiarlo.

Después de todo, al hacerlo, tendrá que ampliar sus conocimientos y habilidades en comparación con todo lo que hizo y sabía antes.

A continuación, le diré cómo cerrar la brecha entre los requisitos que se han establecido para usted y el conocimiento que necesita para completar la tarea.

Sobre los "requisitos"

Como ya notó, uso la palabra "requisitos". Dependiendo de dónde trabaje exactamente, esta palabra puede tener ciertas connotaciones.

En mi experiencia, en las grandes empresas les gustan los requisitos, y en las pequeñas empresas a veces "no presentan requisitos". Creo que esto es de lo que deberíamos hablar aquí.

El hecho es que, en última instancia, todos los programadores hacen lo mismo: resuelven problemas.
Puede obtener un TK exhaustivo de cien páginas sobre cómo resolver este problema (una vez asistí a una reunión de una hora sobre el texto en un botón). O tal vez de esta manera: el CEO pasa por delante de su escritorio y, sin darse cuenta, le pregunta: "¿Podrá hacer frente a esta tarea el viernes?"
En ambos casos, la tarea está establecida para usted y debe asegurarse de comprenderla completamente; ¡La única forma de acercarte a ella bien!

Sobre las etapas

No todos los pasos enumerados a continuación serán necesarios para ninguna tarea. Solo las tareas más complejas pueden requerir la finalización cuidadosa de todos los pasos que se discutirán en este artículo.

Es posible que muchas preguntas no puedan responderse sobre la base de requisitos expresados ​​o debido a la insuficiencia de su experiencia personal.

¡Es posible que deba consultar con otros desarrolladores, líderes de equipo, propietarios de productos, analistas de negocios o incluso abuelas! ¡Y tal vez con cada uno de ellos, antes de que se pueda resolver el problema!

Sin embargo, esto es normal. Esto significa que acumulará conocimientos dispares y los reunirá en un solo conjunto, ¡para que pueda lograr el mejor resultado posible!

Finalmente, la última advertencia: ¡no te excedas con la formalización! Lo más importante aquí es comprender rápidamente la tarea. ¡No se necesitan barreras artificiales y cintas rojas! Todo lo que se necesita es un plan sistemático para resolver un problema que actualmente no comprende.

Etapa uno: analizar el problema

En esta etapa, estamos tratando de entender lo que se le pidió que hiciera. ¡Hasta que tratemos de decidir cómo lo haremos!

Es importante captar esta diferencia. Puede ser peligroso pasar a una carrera sin darse cuenta de todas las consecuencias o, lo que es peor, no comprender completamente qué es exactamente lo que se le pidió que hiciera.

Clasificamos el problema

Clasificar una tarea significa determinar qué trabajo habrá que hacer para resolverla. Aquí hay algunos ejemplos de tipos de tareas:

• Corrección de errores
• Nueva característica
• Nueva aplicación
• Tarea de investigación
• Optimización del rendimiento

Recuerde que esta lista de opciones no se limita a.

En este caso, debemos decidir qué tipo de trabajo se espera de usted. Esto es importante porque afectará directamente qué tipo de trabajo realizará.

Esta etapa es especialmente importante con los requisitos difusos, por ejemplo: "Necesitamos una forma de borrar de algún modo los cachés de nuestros clientes después de actualizar el sitio".

Aquí hay algunas posibles interpretaciones de este requisito.

1. Debe implementar rápidamente un cierto mecanismo para borrar la memoria caché, de modo que los clientes siempre reciban las actualizaciones más recientes.
2. Es necesario estudiar todas las formas de almacenar estos cachés de clientes y determinar las mejores opciones para deshacerse de estos cachés después de cada actualización del sitio.
3. Las memorias caché del cliente ya deberían haberse borrado, y debe buscar y corregir un error que lo impida.

En esta etapa, si no está absolutamente seguro de lo que significaba la interpretación, debe buscar una aclaración y solo entonces continuar trabajando.

Formule la esencia del problema en forma de una o dos declaraciones simples.

Resuma el requisito complejo, como si respondiera la pregunta "¿en qué está trabajando hoy?" Puede que no sea tan simple, pero debe intentar reducir la esencia del problema a una o dos oraciones.

Si el resumen de la tarea de esta manera falla, esto puede significar que debe dividirse en varias subtareas. En principio, este paso se convierte en una prueba de fuego, indicando si logró organizar sus tareas en forma de fragmentos suficientemente pequeños.

Aquí hay un buen ejemplo de tal resumen: "Al actualizar un sitio, adjuntamos un número único a los archivos, para que el navegador comprenda que debe usar la última versión del código".
Esta tarea pasó la "prueba de fuego" por simplicidad y, tal vez, no es necesario dividirla en fragmentos más pequeños.

Y aquí hay un mal ejemplo: "Al actualizar un sitio, adjuntamos un número único a los archivos, por lo que el navegador comprende que debe usar la última versión del código. También debemos enviar un mensaje a nuestro CDN, notificándolo de esta manera sobre la necesidad de actualizar los archivos. También será necesario prever que las aplicaciones para iOS y Android envíen una actualización al mercado de aplicaciones. Más ... "

En este caso, la prueba es definitivamente un fracaso. Se requiere mucho trabajo, y quizás cada tarea debe identificarse y rastrearse por separado.

Destacar detalles críticos

Ahora debe (en forma gratuita, lo más conveniente para usted) hacer una lista de las principales cosas que deben hacerse.

Esto, nuevamente, debería ser un simple apretón de cada una de las etapas principales.

Esta no es una guía de solución de problemas detallada o paso a paso.

Recuerde eso mientras continúa analizando la tarea que se le asignó. En esta etapa, recomiendo tomar notas escritas. Personalmente, uso la aplicación de Notas para esto.

Nuestra tarea de almacenamiento en caché es muy simple y, posiblemente, no es necesario delinearla de esta manera. Veamos un ejemplo más complejo en este caso.

Nuestra próxima tarea es aprovechar una nueva oportunidad: “Cada usuario debe recibir publicidad dirigida de nuestro producto interno. Este anuncio debe adaptarse a las necesidades del usuario en función de los datos que recopilamos ".

Para aislar los elementos principales de esta tarea, debemos imaginar claramente qué se debe hacer para implementar cada elemento.

• Nuestros anuncios existentes deberán distribuirse de tal manera que se correlacionen con algún parámetro específico del usuario.
• Para nuestro departamento de marketing, necesitamos proporcionar una forma que nos permita correlacionar nuevos anuncios con uno o más datos de usuario (en este caso, ¡los especialistas en marketing no deberían programar nada!)
• El sistema tendrá que agregar parámetros de usuario que sean relevantes en el contexto de nuestra publicidad.
• Finalmente, debe crear algún tipo de sistema que reciba una identificación de usuario y muestre anuncios.

¡La belleza de tales listas es que pueden acordarse rápidamente con el equipo o el jefe! Entonces, en este ejemplo, podría mostrar esta lista al líder de su equipo, y él decidió que faltaba otro punto muy importante de la lista:

• Los usuarios deben poder decirnos que ya no quieren ver ciertos anuncios.

Después de todo, al final, ¡lo último que queremos molestar es a nuestros usuarios favoritos! Tomando el tiempo y reflexionando sobre la tarea por solo un par de minutos adicionales, nos ahorraremos horas y días de problemas en el futuro. Por lo tanto, es importante formular y planificar una tarea importante, y solo luego proceder al código.

Antes de continuar, me gustaría responder a sus posibles críticas.

Tal vez piense: "En un negocio normalmente entregado, este tipo de trabajo debe realizarse antes de que se establezcan los requisitos sobre la mesa para el desarrollador", ¡y estoy totalmente de acuerdo con usted!

Sin embargo, lamentablemente, nuestro mundo es imperfecto. A veces, los requisitos que incumben al desarrollador de ninguna manera se exponen en los estantes. Por lo tanto, debemos hacer todo lo posible para evaluar correctamente los requisitos antes de embarcarnos en el desarrollo.

Identifique los problemas que está tratando de resolver.

Responda la pregunta: "¿por qué alguien tendría que usar esto?" o "¿Cuál es el problema real o percibido que estoy tratando de solucionar en este caso?"

Espero que la respuesta sea obvia. En nuestro primer ejemplo, dado aquí, la respuesta es: "los usuarios siempre verán las últimas actualizaciones". En el segundo caso, con la publicidad, "los usuarios siempre verán notificaciones relevantes, no aquellas que no les interesen".

¡El uso de ambas respuestas debería ser obvio! Una comprensión más profunda de la tarea y sus objetivos, puede tomar decisiones más razonables y hacer una implementación que satisfaga adecuadamente sus objetivos comerciales. Si es posible identificar malas soluciones y tareas sin sentido, entonces será posible no perder tiempo y energía en búsquedas que, por definición, no ayudarán a resolver el problema.

Etapa dos: interpretar y evaluar los requisitos

En esta etapa, ya deberías imaginar lo que tienes que hacer y por qué.
A continuación, debe comprender los detalles de lo que va a hacer, cómo lo va a hacer y por qué lo hará de esa manera.
Aclare términos importantes relacionados con su tarea.

Este paso es probablemente más importante para un desarrollador novato como parte de un equipo, o si trabaja en una gran empresa. En ambas situaciones, es muy probable que te encuentres con términos desconocidos en los requisitos.

Estos pueden ser conceptos comerciales, como nombres de productos, clientes o procesos. Puede haber términos relacionados con el desarrollo, por ejemplo, los nombres de herramientas, aplicaciones, modelos, servicios o bibliotecas.

Debe asegurarse de que comprende todos los términos importantes de manera absolutamente clara, de modo que pueda estar seguro de que está implementando la tarea correctamente.

Quizás ya comprenda que necesita inventar una forma de acceder a la información agregada del usuario, pero ¿comprende lo que significa "agregarlo a dao"?
Probablemente entienda que necesita formatear los datos publicitarios, pero ¿tiene alguna idea de qué es "MADF" (marcado para feeds de noticias publicitarias)?

No entiendo ni lo uno ni lo otro.

Es por eso que necesita aislar y definir todos los términos importantes. Confundirse en las definiciones es la forma correcta de resolver un problema incorrectamente.

Decide cómo se debe hacer la tarea.

En esta etapa, ya debe descubrir cómo se realizará la tarea. Los detalles de este proceso pueden variar mucho dependiendo de dónde trabaje y qué tarea específica se le asigne.

En algunos equipos, nadie le explicará exactamente cómo implementar los requisitos, simplemente le dirá qué funcionalidad debe obtenerse en la salida.

En otros, cada paso que das será detallado.

Lo más probable es que te encuentres en algún tipo de situación intermedia.

Si el equipo no le dio instrucciones, entonces en esta etapa no podrá hacer casi nada. Si ha recibido instrucciones, comience a familiarizarse con las etapas por las que tiene que pasar.

Este paso parece completamente natural, pero es importante prestar atención exactamente al orden en el que procedemos.

Naturalmente, nos gustaría sumergirnos en todos los detalles de la tarea a la vez y estudiarlos hasta que el objetivo que establezcamos esté completamente claro para nosotros.

Sin embargo, dado que ya se ha tomado el tiempo para comprender el problema, ahora debe tener una idea más clara de todo el problema, evaluando los pasos que deben seguirse para lograrlo.

Determine si las tareas se están abordando.

En esta etapa, las etapas de análisis e interpretación se fusionan. En la fase de análisis, se enfoca en una imagen holística y objetivos a gran escala: lo que hacemos y por qué.

En la fase de interpretación, concéntrese en los detalles, cómo lo hacemos.

La segunda etapa se llama "interpretación y evaluación", porque ahora puede correlacionar "cómo" y "qué y por qué". Interpretas los detalles en función de la imagen general. Evalúa los detalles y determina si se resolvió el problema original.

Pregúntese: ¿los pasos que se me indicaron que condujeran al resultado, que fue designado como el objetivo final de la tarea? ¿El resultado planificado realmente resuelve el problema original?

Si está seguro de que todos los problemas pueden resolverse y los detalles son significativos, ¡puede ponerse a trabajar! De lo contrario, es necesario pasar a la tercera etapa para resolver todo tipo de conflictos.

Etapa tres: abordamos el problema de manera crítica

En esta etapa, debe poder afirmar con confianza que comprende tanto la tarea como la solución. Todo lo que queda por ver es si esta decisión es correcta.

Para crear un producto de la más alta calidad, todos debemos ser responsables y hablar si algunas cosas están claramente mal.

Por otro lado, no vamos a hacer reclamos inapropiados. No se puede decir que algo está mal, porque "parece que sí" o simplemente "no me gusta". Deben presentarse argumentos concretos y bien diseñados.

Entonces, describimos las reglas básicas de desacuerdo competente

Sepa cuándo estar en desacuerdo

• El desacuerdo es inaceptable, hasta que descubrí el problema a fondo.
  Decir "esto está mal" solo es posible con absoluta certeza de que comprende lo que no está de acuerdo con /
  Si no puede formular con confianza un problema y una solución planificada, no puede estar en desacuerdo. Si no está seguro de entender todo correctamente, no puede estar en desacuerdo. Solo asegurándose de que comprende el problema hasta el más mínimo detalle, puede permitirse el lujo de estar en desacuerdo.
  Si cree que no tiene toda la información necesaria, puede ser el momento de detenerse y revisar todos los pasos que se han completado antes de afirmar que los requisitos son incorrectos.
• Uno no puede dejar de estar de acuerdo por razones subjetivas. Busque problemas potenciales genuinos.
  "No me gusta cómo se hace esto" es un juicio subjetivo. "Esto conducirá a problemas de rendimiento porque hay muchas operaciones involucradas" es una razón objetiva. Ejemplos de otras razones subjetivas: "Y en otro proyecto lo hicimos de manera diferente" o "Hubiera implementado esta solución de manera un poco diferente, pero esto, por supuesto, es cuestión de gustos".
• Debe tener explicaciones bien pensadas listas para respaldar sus reclamos.
  Si no puede explicar por qué algo está mal, ¿puede estar seguro de que tiene razón? Le aconsejo que escriba las razones por las cuales la decisión le parece incorrecta y formule cómo se puede solucionar.

Si no puede ofrecer esa solución, cuénteme claramente desde el principio.

Tenga cuidado cuando no esté de acuerdo con los demás. Se necesita mucho tiempo para escuchar a todos y comprender todo, y solo entonces no puede estar de acuerdo.

Si hasta este punto se adhirió cuidadosamente a todos los pasos descritos, es muy probable que esté bien versado en todo. Sin embargo, trate de no encerrarse en sus cálculos, ¡podría haberse perdido algo!

Me gusta comenzar la discusión con las palabras: "No es que no esté de acuerdo contigo, simplemente no lo entiendo todavía". Más tarde, si es necesario, se puede expresar un fuerte desacuerdo, pero para empezar, resolverlo.

Saber estar en desacuerdo correctamente

Para garantizar que nuestro desacuerdo sea objetivo, tomaremos una serie de medidas que nos ayudarán a comprender si nuestros argumentos son legítimos.

El desacuerdo objetivo nos permite demostrar al menos uno de los siguientes hechos:

• La decisión no está bien informada
• La decisión está mal informada
• La tarea o solución es ilógica.
• La solución está incompleta.

La falta de información no es motivo de resentimiento; solo significa que al crear la solución, usted vino de datos incompletos. Quizás los redactores del TK no sabían sobre el sistema ya existente, capaz de realizar las acciones necesarias.

Estar mal informado significa crear una solución basada en información incorrecta.

Este es un caso cuando, en opinión de los redactores de TK, el sistema existente puede hacer algo, pero en realidad esta posibilidad no está prevista en él. Por ejemplo, el equipo de SEO le pidió que Google indexe la página con la cuenta de usuario en su aplicación. Google no puede hacer esto. Esto significa que su seokhniki no comprende las funciones del robot de búsqueda de Google.

Una tarea ilógica o una solución ilógica simplemente no tiene sentido. Un ejemplo típico (desde el punto de vista del desarrollador) es implementar una característica que derribará alguna otra característica. Tal requisito puede considerarse ilógico, ya que es más probable que cause daño que ayuda.

La solución está incompleta y, a veces, se hace a propósito. En el desarrollo de software, a menudo intentamos crear MVP (producto mínimo viable) para comenzar. Esto significa que en la primera operación, puede retrasar intencionalmente la implementación de una función que no es absolutamente necesaria.

De hecho, una decisión puede considerarse incompleta solo si no resuelve el problema que se le plantea, o si los pasos anteriores no son suficientes para crear un producto viable o una oportunidad completa.