Hola a todos! Como parte de nuestro curso
Python Developer, llevamos a cabo otra lección abierta sobre el tema "Cómo no escribir en Python". La lección fue impartida por el maestro y creador del curso,
Stanislav Stupnikov , quien tiene una amplia experiencia en desarrollo industrial y científico. Se consideraron los antipatrones de la programación, las malas prácticas y otros males, que debe conocer y evitar en el proceso de escribir código.
Vea el video y el resumen para más detalles. Advertencia: ¡no se recomienda ejecutar algunos ejemplos de código en su computadora!
Durante la lección abierta, la maestra mostró diapositivas generadas con el Cuaderno Jupyter.
¡Entonces comencemos!
Entonces, ¿por qué no escribir en Python?
Para la conveniencia de enviar material, se preparó una lista de técnicas que no deberían usarse en el proceso de programación. Cada ejemplo fue acompañado por una muestra de código claro (disponible para visualización gratuita en video). Describimos brevemente los principales antipatrones:
- Patrón de pañal Se trataba del llamado patrón de "pañal", que generalmente significa un intento de prueba demasiado amplio. Por ejemplo, llama a una función que es un contenedor para algo, por ejemplo, envuelve una biblioteca de cliente para alguna base de datos. En un buen caso (el sistema es pequeño) todo estará bien en el 99% de los casos, pero si el sistema es grande, entonces las probabilidades de un problema no se multiplican de la mejor manera. Como resultado, algo cae o se rompe constantemente.
- Antiglobalismo. Todos saben que las variables globales son ineficientes, excepto en algunos casos excepcionales. Es mucho mejor pasar todo en forma de atributos a funciones, etc., etc., logrando los resultados deseados. Sin embargo, a algunos se les ocurre una "gran idea": utilizar objetos mutables. Consiste en pasar variables no globales, sino objetos mutables en funciones, luego cambiarlos dentro y luego no devolver nada. ¡Esto es genial!) De hecho, una pieza de una plantilla de programación del lenguaje C, transferida al mundo Python.
- Escalera al cielo. Como habrás adivinado, esta es una "escalera al cielo". Este problema se caracteriza mejor por una imagen simple:
- Javatar Los errores de este plan a menudo son cometidos por aquellos programadores que por una razón u otra cambiaron de Java a Python. Naturalmente, vienen con su propia carta, por lo que violan las reglas de desarrollo de Python en masa. Esta es la apariencia de una sangría insana, y CamelCase, y el deseo de crear más clases ... Como resultado, la estructura del código se vuelve más complicada. Cuando se puede prescindir de un script con un tamaño de 300 líneas, vemos 10-20 archivos.
- Sobreingeniería. Muy a menudo, la segunda iteración de un proyecto nunca se completa o se implementa de una manera demasiado complicada. Esto sucede si desea reescribir un código existente pero defectuoso, lo que lo hace ideal. Al mismo tiempo, olvidas que lo mejor es enemigo de lo bueno. Como resultado, el programador cae en la trampa estándar de la reingeniería, cuando la implementación se vuelve más costosa, pesada y engorrosa de lo necesario para resolver las tareas. Y de hecho: ¿deberían los sedanes familiares alcanzar velocidades de hasta 350 km / h, y los teléfonos inteligentes, cuya moda cambia cada año, funcionan durante 100 años?
- Oneliner Otro problema urgente es la "línea única". Se trata de programadores que intentan con un celo envidiable empujar todo en una línea, cinco pisos de comerciales). Debido a la excesiva complejidad del código y las peculiaridades de la implementación de expresiones regulares de máquina en Python, estos scripts a veces se "pegan" al análisis, por lo que debe usar un módulo especial para solucionar el problema.
- Copia en lectura. Esto no es tanto un error como una característica de la programación de Python. Muchos están familiarizados con el enfoque de Copia en escritura. Su idea es que cuando se lee un área de datos se usa una copia compartida, y cuando se realiza un cambio, se crea una nueva copia, es decir, estamos hablando de optimizar los procesos de rendimiento. Si hablamos de Python, en algunos casos no solo leemos una matriz de elementos, sino que nos referimos a todas las estructuras subyacentes que están en la memoria, es decir, "reescribimos" la memoria, cambiándola. Por lo tanto, en lugar de Copiar en escritura, obtenemos Copiar en lectura cuando parece que leemos la memoria, pero de hecho tenemos que copiar esta información del espacio principal a nosotros mismos como un proceso secundario, lo que lo pone triste, ya que el enfoque la optimización no funciona y el consumo está creciendo.
- No hay tenedor Fork: clonación de la aparición de un nuevo proceso. El problema está relacionado con los detalles de trabajar con sistemas Unix y la falta de evidencia de algunas estructuras de datos que están ocultas en la implementación. Un proceso "bifurcado" es un proceso que comienza en el momento en que el hilo ha capturado el registro en la cola para poner algo en él. Es decir, el nuevo proceso que ha surgido también quiere escribir algo, pero para esto necesita tomar el registro de esta cola, pero no puede hacerlo, ya que el registro ya está capturado. Como resultado, obtenemos un candado. Todo esto solo una vez más confirma que no vale la pena programar, sin conocer las características de la implementación del entorno en el que trabaja y las herramientas que utiliza.
Todavía había muchas cosas interesantes, así que mejor mira el video, porque el recuento aún es corto.
Como siempre, esperamos preguntas, comentarios y sugerencias aquí o en
la puerta abierta .