Los principios de desarrollo de software son un conjunto de reglas y recomendaciones específicas que los ingenieros deben seguir durante la implementación del programa si quieren escribir un código bonito, claro y mantenible. No hay una varita mágica que pueda convertir un batiburrillo de variables, clases y funciones en un código perfecto, pero hay algunos consejos y pistas que pueden ayudar a un ingeniero a determinar si está haciendo lo correcto.
Veamos estas recomendaciones básicas. Algunos de los principios que aparecen a continuación son específicos de Python, pero la mayoría no lo son.
Mide dos veces y corta una
Creo que este es el principio más importante de todos. Si sólo aprendes un principio de este post, debería ser éste. Nosotros, los desarrolladores /arquitectos/ gerentes, luchamos contra la falta de atención, los errores estúpidos y las erratas, los problemas personales, el mal humor y el café frío. Nada de esto es relevante: hay que resolver el problema. Para mí, como ingeniero, este principio significa elegir la solución correcta para el problema, elegir el enfoque correcto para el problema, elegir las herramientas adecuadas para resolver el problema, la confianza en la solución construida. Elegir aquí significa reflexionar, encontrar los recursos necesarios, reunir el equipo adecuado, pensar en el diseño, pensar en el enfoque, fijar las tareas, controlar el resultado y responsabilizarse de ello. Esto es «Ingeniería tal cual». Creo que yo mismo no estoy preparado para describirlo con palabras correctas.
No te repitas (DRY)
Es un principio bastante simple pero muy útil que dice que repetir lo mismo en diferentes lugares es una mala idea. En primer lugar, está relacionado con la necesidad de apoyo y modificación posterior del código. Si algún fragmento de código se duplica en varios lugares dentro de un programa, hay una alta probabilidad de que se produzcan dos situaciones catastróficas:
- Al hacer incluso pequeños cambios en el código fuente, es necesario cambiar el mismo código en varios lugares. Esto requerirá tiempo, esfuerzo y atención adicionales (a menudo no es fácil).
El primer punto sigue al segundo. Usted u otro desarrollador de su equipo puede pasar por alto accidentalmente uno de los cambios(puede ocurrir simplemente al fusionar ramas en vcs) y enfrentarse a los subsiguientes bugs en la aplicación. Estos errores pueden ser frustrantes para usted porque ha escuchado que tal error ya ha sido corregido.
En este sentido, hay una recomendación – si cualquier código se encuentra en el listado más de dos veces, debe ser colocado en una forma separada. Esta es una recomendación general. De hecho, deberías pensar en crear un método separado incluso si encuentras una repetición por segunda vez.
Es una idea muy común, que llegó a la programación desde la filosofía. El principio obtuvo su nombre del monje inglés Guillermo de Oakham. Este principio dice: «Las entidades no deben multiplicarse sin necesidad». En ingeniería, este principio se interpreta así: no hay que crear entidades innecesarias sin necesidad. Por tanto, siempre es buena idea pensar primero en los beneficios de añadir otro método/clase/herramienta/proceso, etc. Al fin y al cabo, si se añade otro método/clase/herramienta/proceso, etc. y no se obtiene ninguna ventaja más que el aumento de la complejidad, ¿qué sentido tiene?
Manténgalo simple y estúpido (KISS)
Este es un principio muy similar al anterior, pero tiene un significado ligeramente diferente. Este principio dice que el código debe ser lo más simple posible sin estructuras complejas, de lo contrario complicará la depuración y el mantenimiento del código. Además, será más difícil para otro programador entender la lógica del código, lo que a su vez también requerirá tiempo y esfuerzo adicionales. Por eso debes intentar siempre utilizar construcciones sencillas que resuelvan el problema en la medida de lo posible, sin numerosas ramas, anidación profunda y estructuras de clases excesivamente sobrecargadas. Haciendo esto, te facilitarás la vida a ti mismo y a tus compañeros, porque la complejidad genera bugs. Recuerda lo que dijo Peter Hintiens: «La simplicidad es siempre mejor que la funcionalidad».
No lo vas a necesitar (YAGNI)
Un problema que sufren muchos programadores. El deseo de implementar de una vez toda la funcionalidad necesaria (y a veces incluso innecesaria) desde el principio del proyecto. Es decir, cuando un desarrollador añade todos los métodos posibles a la clase desde el principio y los implementa, e incluso puede no utilizarlos nunca en el futuro. Por lo tanto, según esta recomendación, primero implementa sólo lo que necesites, y más tarde, si es necesario, extiende la funcionalidad. De esta manera, ahorrará esfuerzo, tiempo y nervios en depurar el código que no es realmente necesario.
Diseño grande por adelantado
Antes de empezar a desarrollar la funcionalidad, debería pensar primero en la arquitectura de la aplicación y diseñar todo el sistema hasta detalles suficientemente pequeños, y sólo entonces proceder a la implementación según un plan predefinido. El principio tiene derecho a existir, pero últimamente se le critica bastante. En primer lugar, está relacionado con la obsolescencia del plan durante el diseño y la elaboración. En este sentido, es necesario hacer los cambios posteriores todavía. Pero también tiene ventajas innegables, en el diseño correcto, es posible reducir considerablemente el costo de la depuración posterior y la corrección de errores. Además, tales sistemas de información, por regla general, son más lacónicos y arquitectónicamente correctos.
Evitar la optimización prematura
«La optimización prematura es la raíz de todos los males (o al menos de la mayoría) en la programación» – Donald Knuth
La optimización es un proceso muy correcto y necesario para acelerar el programa, así como para reducir el consumo de recursos del sistema. Pero todo tiene su tiempo. Si la optimización se lleva a cabo en las primeras etapas de desarrollo, puede hacer más daño que bien. En primer lugar, está relacionado con el hecho de que el desarrollo de un código optimizado requiere más tiempo y esfuerzo para el desarrollo y el soporte. En este caso, a menudo hay que comprobar la corrección del enfoque de desarrollo elegido al principio. Por eso, al principio es más rentable utilizar un enfoque sencillo pero no el más óptimo. Y más adelante, al estimar cuánto ralentiza este enfoque el trabajo de una aplicación, pasar a un algoritmo más rápido o que consuma menos recursos. Además, mientras implementes inicialmente el algoritmo más óptimo, los requisitos pueden cambiar y el código irá a la basura. Así que no hay necesidad de perder el tiempo en una optimización prematura.
Principio del menor asombro
Este principio significa que su código debe ser intuitivo y obvio, y no sorprender a otro desarrollador cuando revise el código. Por ejemplo, si el método se llama «hacer galletas» pero obtiene patatas como resultado, ese código es malo (obviamente). Además, debes intentar evitar los efectos secundarios y documentarlos si no puedes evitarlos.
S.O.L.I.D.
«SOLID» es en realidad un grupo de principios de diseño orientado a objetos. Cada letra de «SOLID» representa uno de los principios, que son:
- La responsabilidad única establece que cada módulo o clase debe tener la responsabilidad de una sola parte de la funcionalidad proporcionada por el software y que la responsabilidad debe estar totalmente encapsulada por la clase;
- La apertura-cerrado establece que las entidades de software (clases, módulos, funciones, etc.) deben estar abiertas a la extensión, pero cerradas a la modificación;
- La sustitución de Liskov establece que la clase heredada debe complementar, no reemplazar, el comportamiento de la clase base;
- La inversión de la dependencia dice que el programador debe trabajar a nivel de la interfaz y no a nivel de la implementación.
La segregación de la interfaz establece que ningún cliente debe ser forzado a depender de métodos que no utiliza;
Cuando se aplican juntos, estos principios ayudan a un desarrollador a crear un código que es fácil de mantener y extender en el tiempo.
Ley de Demeter
La idea básica de este principio es dividir las áreas de responsabilidad entre las clases y encapsular la lógica dentro de una clase, método o estructura. De este principio se pueden distinguir varias recomendaciones:
- Las clases o entidades deben ser independientes
- Se debe intentar reducir el número de conexiones entre las diferentes clases (el llamado acoplamiento).
- Las clases asociadas deben estar en un solo módulo/paquete/directorio (también conocido como cohesión.
Siguiendo esos principios, la aplicación se vuelve más flexible, comprensible y fácil de mantener.
Conclusión
¡Compañeros desarrolladores seamos ingenieros! Pensemos en el diseño y construyamos sistemas robustos y bien implementados, en lugar de cultivar monstruos orgánicos. Los principios enumerados están muy correlacionados y conectados en su esencia. Por supuesto, yo no los he creado, pero un pequeño recordatorio no hace daño, al menos mi memoria definitivamente no es perfecta.
Libros recomendados
- Código limpio por Robert C. Martin
- Arquitectura limpia por Robert C. Martin