💐 🌞 👨‍👨‍👧‍👦 Programación a las masas. ♀️ 😖 🍰

Comprender incluso los conceptos básicos de la programación puede simplificar las actividades humanas. Además de las cosas obvias, como el desarrollo del pensamiento abstracto o la capacidad de dividir la tarea en partes más pequeñas, propongo ir aún más lejos y utilizar los enfoques básicos para el desarrollo. Utilizando el ejemplo de crear un juego lógico clásico, dibujando una analogía entre la programación visual y la tradicional, quiero mostrar cómo las habilidades de desarrollo pueden ayudar a resolver un problema aplicado. Aquellos que deseen debatir sobre el tema o jugar "Toros y vacas" y ganar un premio, una llamada al gato.

Mi nombre es Zhenya y soy desarrollador de back-end en ManyChat. Hace algún tiempo, el equipo de recursos humanos se me acercó con una solicitud para implementar el juego "Toros y vacas", familiar para muchos desde la infancia, sobre la base de nuestro producto. Déjame agregar un poco de contexto. ManyChat es una herramienta para automatizar la interacción entre las empresas y sus clientes, lo que le permite responder preguntas comunes a través de Facebook y, más recientemente, SMS y correo electrónico. "Bulls and Cows" es un juego lógico, durante el cual, para varios intentos, es necesario adivinar el número adivinado. Muchos pueden saberlo del juego Fallout, donde necesitas hackear una terminal de computadora. Se pueden encontrar más detalles sobre las reglas al final del artículo.

Visualización

¿Qué hacemos antes de escribir código para una tarea compleja? Vamos al pizarrón con un marcador o tomamos un lápiz y papel y dibujamos un diagrama de bloques o un diagrama UML, porque la visualización es la forma más natural para que las personas presenten y perciban información. Flow Builder es el corazón de nuestro sistema, basado en varios objetos, elementos gráficos y las reglas por las cuales interactúan entre sí. Yo diría que esta es una continuación lógica de la programación orientada a objetos. Así que descarté las herramientas habituales e inmediatamente procedí a diseñar la lógica de comunicación entre el bot y el jugador.

Juego de Flow of the Bulls and Cows

Esto es muy conveniente, ya que el diagrama UML y Flow Builder son casi idénticos. En este paso, el diseño y la programación ya están combinados. Durante varias iteraciones, lancé flujo y designé los lugares de interacción con el usuario y con la API. El resultado obtenido fue algo diferente de la representación original en mi cabeza: la visualización brindó la oportunidad de ver la tarea desde una perspectiva diferente. Esto es bueno, ya que los cambios en el diagrama son más fáciles y baratos que codificar. Me parece que el significado de este enfoque se basa en el proverbio "medir siete veces, cortar uno". Los ingenieros deben ser especialmente familiares y comprensibles.

División de responsabilidad

¿Qué debería implementarse del lado de ManyChat y qué del lado del código? La respuesta a esta pregunta al principio no me pareció obvia. Hay dos herramientas para la interacción en nuestra plataforma: Dynamic Block y External Request. Son casi idénticos, excepto que el primero ejecuta la solicitud en el servidor remoto y pasa a la siguiente instrucción, y el segundo le permite comparar primero los datos de respuesta con las variables bot. En una de las primeras versiones, utilicé el bloque dinámico e implementé el envío de la clasificación del método API directamente a Facebook. Parece que no hay nada de malo en este enfoque. Pero si mira un poco más y asume que el jugador quiere jugar usando SMS, el código tendrá que averiguar sobre el canal de comunicación de un jugador específico. No parece necesario En la próxima versión, cambié el flujo para trabajar con Solicitud externa,agregó una entrada de respuesta a las variables de usuario y eliminó cualquier mención del canal del código. Ahora el código del juego se puede usar en otra aplicación e implementar cualquier interfaz de interacción deseada: desde la consola hasta la aplicación móvil. Si estaba separando la vista de la lógica de control de acuerdo con el patrón MVC o resaltando los contextos limitados de acuerdo con el enfoque DDD, decida usted mismo. Lo principal aquí es que, a pesar de la falta de requisitos, en un nivel subconsciente, identifiqué un posible cuello de botella en el sistema que podría crear problemas en el futuro.Si estaba separando la vista de la lógica de control de acuerdo con el patrón MVC o resaltando los contextos limitados de acuerdo con el enfoque DDD, decida usted mismo. Lo principal aquí es que, a pesar de la falta de requisitos, en un nivel subconsciente, identifiqué un posible cuello de botella en el sistema que podría crear problemas en el futuro.Si estaba separando la vista de la lógica de control de acuerdo con el patrón MVC o resaltando los contextos limitados de acuerdo con el enfoque DDD, decida usted mismo. Lo principal aquí es que, a pesar de la falta de requisitos, en un nivel subconsciente, identifiqué un posible cuello de botella en el sistema que podría crear problemas en el futuro.

Nomenclatura variable

La nomenclatura variable es uno de los dos principales problemas de programación. Además de las variables, la denominación de bloques es igualmente importante. Muchos usuarios no le dan importancia a esto, no tienen tiempo para mirar a su alrededor ya que el flujo se convierte en un conjunto de Copia 1, Copia 2, etc. Esto complica enormemente la comprensión. Todo es como con una mala clase: es imposible darse cuenta de lo que está haciendo sin entrar. Con más detalle este pensamiento fue revelado por mi colega. Si estás interesado, te sugiero que leas su publicación .

Steve McConnell en su libro "Código perfecto" escribió que el nombre debe describir de manera completa y precisa la entidad representada. Creo que es difícil discutir con eso. Por ejemplo, para las variables booleanas, prefiero usar el prefijo is. En este caso, el lector ya puede entender a qué se enfrenta con las dos primeras letras. En cuanto a la longitud, es deseable que no supere los 20 caracteres (Gorla, Benander y Benander, 1990). Cuanto más pequeño es el alcance de una variable, más corto puede ser su nombre. Pero dado que todas las variables en ManyChat tienen un alcance global, vale la pena usar el espacio de nombres. Para Bulls y Cows, utilicé el segmento inicial en forma de dos letras mayúsculas BC derivadas de Bulls and Cows. Dado lo anterior, obtuve el nombre de la variable BC Is Victory - bastante único y completo, en mi opinión.

SECO, BESO

El juego funciona y, al parecer, puedes exhalar con una sensación de logro. Pero sabemos que el siguiente paso es la auto revisión y la refactorización. Con un análisis más detallado, puedes ver cómo detener el procesamiento de textos y la victoria conducen a bloqueos similares: los jugadores requieren algunas acciones. Al mismo tiempo, la pérdida, por alguna razón, vive su propia vida. La combinación de estos lugares en uno parece ser un paso lógico para evitar la duplicación, lo que a su vez conduce a una mayor consistencia de comportamiento y facilidad de mantenimiento. Ahora, si los cambios son necesarios, debe realizarlos en la única unidad del sistema sin cambios en los demás, lo que indica que el principio No repetirse se aplica con éxito.

Fluir con SECO

Sin embargo, no te detengas allí. Las soluciones complejas son difíciles de mantener. Cuando se produce un error, no será fácil localizarlo, especialmente después de un momento en que se sale de contexto. Una nueva persona necesitará mucha energía para descubrir qué es qué. Y tendrá que familiarizarse con cada nodo, para no perderse nada importante. Por lo tanto, vale la pena usar el principio de mantenerlo simple, estúpido y difundir todas las acciones posibles en lugares separados. Después de la descomposición, obtuve 5 flujos bastante fáciles de entender. Como un bono agradable, esta refactorización satisface la responsabilidad individualprincipio. Cada flujo tiene una responsabilidad y esta responsabilidad está completamente encapsulada en él. El atractivo es a la caja negra, y por la naturaleza del problema se puede localizar más rápido.

Flujo compatible con KISS

YAGNI

En una de las primeras versiones de automatización, hubo logros al enviar recordatorios de un juego abandonado e instrucciones para que los ganadores recibieran regalos. La implementación de la primera idea fue complicada por las restricciones por parte de Facebook: recientemente, las condiciones para enviar mensajes fuera de la ventana a las 24 horas se han vuelto más duras. El segundo resultó ser insuficientemente trivial para la implementación del código. Ambas cuestiones se resuelven, pero la cantidad de esfuerzo necesaria no se justificó por las necesidades de una campaña única. Además, las tareas de sprint pisaron los talones, por lo que se decidió no implementar esta funcionalidad. Y aquí vino al rescate No lo vas a necesitarUn principio cuyo propósito es abstenerse de una funcionalidad excesiva. Esta es una situación normal cuando las condiciones cambian y mueren, aparecen más piezas innecesarias en el producto. La eliminación de los bloques correspondientes facilitó la comprensión del propósito del flujo y una vez más recordó la importancia de la negativa oportuna a agregar una nueva funcionalidad, que no es directamente necesaria.

Los desarrolladores experimentados saben que cualquier característica necesita soporte constante, desde la refactorización de código hasta la actualización de la documentación y el trabajo con comentarios de los usuarios. Por lo tanto, la adición de nuevas funcionalidades siempre debe considerarse con recelo, haciendo la pregunta, ¿es realmente necesario? En última instancia, en esta etapa, puede ahorrar muchos recursos.

vamos a jugar

Se pasan las etapas de auto revisión y refactorización, no hay funcionalidad innecesaria y el significado de todo el flujo es transparente para la comprensión. Esto significa que el juego está listo y es hora de competir por premios. Según los términos de la competencia, los 10 mejores jugadores que anoten la mayor cantidad de puntos antes del 22 de mayo de 2020 recibirán premios del equipo de ManyChat.

Un poco sobre las reglas. En nuestra implementación, el juego está diseñado para una persona. El bot crea una secuencia de 4 dígitos con números que no se repiten. El jugador intenta adivinar el número. El bot informa en respuesta a cuántos números se adivinaron sin coincidir con sus posiciones, es decir, el número de vacas y cuántos se adivinaron hasta la posición, es decir, el número de toros. Como resultado, el escenario del juego puede verse más o menos así:

se adivina el número 1234. El
participante hace la primera suposición: 4321
Obtiene la respuesta: 0 toros y 4 vacas.El
participante hace la segunda suposición: 1678
Y recibe la respuesta: 1 toro y 0 vacas.

Para probar, siga el enlace y siga las indicaciones. Déjame recordarte que el juego pasa por Facebook Messenger. Ofrecemos 2 niveles de dificultad: un juego para un número limitado e ilimitado de movimientos. Ganar en uno difícil te traerá 3 puntos, en uno simple: 2. Perder, independientemente del nivel, tomará 1 punto.

El juego se implementó en una pila de tecnología estándar: Nginx 1.17, PHP 7.4, PostgreSQL 12.1. Si lo desea, puede clonar el repositorio en su servidor, instalar la plantilla en su página ManyChat y organizar su propio torneo.

recomendaciones

"Todos en este país necesitan aprender a programar en una computadora porque te enseña a pensar". Creo que la relevancia de esta declaración ha ido más allá de las fronteras de un solo país. La programación no es caracteres secretos en la terminal, es difícil de percibir para una persona no iniciada y un programador no es elegido. En primer lugar, es una forma de pensar y un conjunto de habilidades para resolver problemas.

Volviendo al título del artículo y el eslogan original, quiero reformularlo: “La programación pertenece a la gente. Debe tener sus raíces más profundas en las profundidades de las amplias masas trabajadoras. Debe ser entendido por estas masas y amado por ellas ".

Nunca hubiera pensado que en un artículo citaría a Steve Jobs y Lenin.

Estoy seguro de que los pensamientos presentados aquí me vinieron a la mente no solo a mí. Algunos incluso los considerarán capitanes. Pero sé por mí mismo que a veces necesitas escuchar la misma información varias veces para comenzar a usarla. El principio banal es simplificar las cosas tan simples como parecen. Todos los programadores saben que el código del proyecto se descontrola rápida y fácilmente si no se les presta la debida atención. Pero a veces tienes que recordarte esto de nuevo.

Algo no estaba encendido en absoluto. Por ejemplo, en este artículo no se abordaron técnicas de programación extremas, como la programación de pares, lanzamientos pequeños frecuentes y el juego de programación. Si bien las metodologías flexibles tienen raíces comunes con los sistemas para organizar la producción física y fuera de línea, todavía se usan con frecuencia para el desarrollo de software. Aunque su potencial no se limita a la industria.

Probablemente hay algo en lo que nunca pensé. Cada uno de nosotros tiene su propia experiencia y visión. Por lo tanto, le insto a que comparta sus pensamientos sobre este tema en los comentarios.

Programación a las masas.