Buenas Prácticas

a) “Once and Only once”

El principio Once and Only Once puede considerarse como un subconjunto del principio No te repitas, y es uno de los principios más fundamentales del desarrollo de software. Once and Only Once básicamente establece que cualquier comportamiento dado dentro de una aplicación se define una sola vez. La duplicación del comportamiento es una de las fuentes más comunes de errores en los sistemas de software, ya que cada vez es más probable que los cambios en el comportamiento definidos en una ubicación no se propaguen a todas las ubicaciones donde se define este comportamiento. La eliminación de la duplicación causada por no seguir el principio Once and Only Once es una de las razones principales para la refactorización y también está en el centro de muchos patrones de diseño.

El principio No te repitas (DRY- Don’t Repeat Yourself) establece que la duplicación en la lógica debe eliminarse mediante abstracción y la duplicación en el proceso debe eliminarse mediante la automatización.

La duplicación es desperdicio

Agregar código adicional e innecesario a una base de código aumenta la cantidad de trabajo requerido para extender y mantener el software en el futuro. Ya sea que la duplicación provenga de la programación de copiar y pegar o de una comprensión deficiente de cómo aplicar la abstracción, disminuye la calidad del código. La duplicación en el proceso también es un desperdicio si se puede automatizar. Las pruebas manuales, los procesos de construcción e integración manuales, etc., deben eliminarse siempre que sea posible mediante el uso de la automatización.

b) “Tell, don’t ask”

Hay un gran principio en la programación orientada a objetos que dice: " Tell, Don't Ask".

Este principio dice que no debemos preguntar a los objetos sobre su estado, tomar decisiones y solo entonces decirles qué hacer. Más bien dice que deberíamos enviar comandos directamente y evitar así las preguntas.

Este código está mal implementado, en él se le pregunta a current_user si es administrador y, según la respuesta, decidimos a qué método llamar.

Otra sección mala es que la lógica que decide qué mensaje enviar esta fuera del objeto current_user. Entonces, si queremos mostrar ese mensaje en dos partes distintas, tendremos que repetir la declaración if..else en cada lugar. O si necesitamos cambiar esa lógica en algún momento, también tendremos que hacerlo en todos los demás lugares. Eso rompe la regla No te repitas (DRY – Don’t Repeat Yourself).

Si aplicamos el principio "Tell, Don't Ask", ese código se vería así:

La lógica que verifica si el usuario es administrador debe estar en el método welcome_message.

c) “Program to an interface not to an implementation”

La codificación orientado a interfaces es una técnica para escribir clases basadas en una interfaz; interfaz que define cuál debería ser el comportamiento del objeto. Esto Implica primero la creación una interfaz, definir sus métodos y luego crear la clase real con la implementación. Al principio, parece que puede ser una codificación excesiva, pero hay dos razones principales por las cuales se debe aplicar: Test Driven Development y la flexibilidad que genera.

En el lado de las pruebas, es absolutamente necesario. TDD se basa en crear las pruebas que permitan lograr la funcionalidad, para luego desarrollar el código requerido que pase estas pruebas. Como todavía no hay una implementación del código, es necesario usar Interfaces para simular objetos que cumplan con los casos de prueba; cuando la implementación real está lista, solo es cuestión de sustituir los simulacros e inyectar el objeto real. Si el objeto cumple con la interfaz, sus pruebas se comportarán de la misma manera que los simulacros. También funciona al crear pruebas que dependen del código realizado por otra persona o equipo y aún no tiene el objeto real.

Para la parte de la flexibilidad y el mantenimiento, se puede ver de una forma más sencilla de la siguiente manera:

Piense en las ruedas de su vehículo; tienes las ruedas de aspecto regular que vienen con él cuando lo compraste. Pero después de ir al concesionario, te enamoras de un nuevo juego de ruedas de edición limitada que ofrecen a un precio increíble. Ahora imagine por un segundo que su automóvil y sus ruedas fueron diseñados para trabajar juntos de manera única. Lo único que se podría hacer es; modificar las ruedas para que funcionen con tu auto o ajustar tu auto para que funcione con las ruedas… Afortunadamente, en la realidad las cosas no son así, los fabricantes de automóviles han fabricado vehículos de una manera en la que simplemente usted compra sus ruedas nuevas, las instala y comienza a conducir. 

En este escenario, sus ruedas son una interfaz y las ruedas predeterminadas y las ruedas de edición limitada son solo diferentes tipos de ruedas, pero ambas simplemente "ruedan". No importa las propiedades reales, si su automóvil sabe cómo usar una rueda, su auto viajará.

En este siguiente ejemplo se tienen una interfaz "Hablante" y clases que obtienen el método para hablar pero cada uno en su idioma respectivo.

d) “Favor object composition over class inheritance”

La herencia es cuando diseñas tus Tipos por lo que son, mientras que la composición es cuando diseñas tus Tipos por lo que pueden hacer.

La composición sobre la herencia (o principio de reutilización compuesta) en la programación orientada a objetos (OOP) es el principio donde las clases deben lograr un comportamiento polimórfico y la reutilización del código basándose en su composición (al contener instancias de otras clases que implementan la funcionalidad deseada) en lugar de aplicar una jerarquía de propiedades y métodos usando la herencia de un clase base o principal.

Una implementación de la composición sobre la herencia generalmente comienza con la creación de varias interfaces que representan los comportamientos que el sistema debe exhibir, las clases implementan las interfaces identificadas según sea necesario y por lo tanto, los comportamientos del sistema se realizan sin herencia.

Favorecer la composición sobre la herencia es un principio de diseño que le da al diseño de código una mayor flexibilidad. Es más natural construir clases a partir de varios componentes que tratar de encontrar puntos en común entre ellas y crear un árbol genealógico. Por ejemplo, un pedal acelerador y un volante comparten muy pocos rasgos comunes, sin embargo, ambos son componentes vitales en un automóvil. Lo que pueden hacer y cómo se pueden utilizar para beneficiar al automóvil se define fácilmente, y esto lo utiliza la composición para desarrollar las relaciones entre las clases.

El diseño inicial se simplifica identificando los comportamientos de los objetos del sistema en interfaces separadas en lugar de crear una relación jerárquica para distribuir los comportamientos entre las clases a través de la herencia. Este enfoque acomoda más fácilmente los cambios que se puedan requerir en el futuro que de otro modo necesitarían una reestructuración completa de las clases en el modelo de herencia. Además, evita problemas a menudo asociados con cambios relativamente menores realizados en alguna parte de una clase que afecten a todas las demás, un error común en un modelo basado en la herencia que incluye varias generaciones de clases.

e) “Make it work, make it right, make it fast”.

EL PRIMER PASO: HAZLO FUNCIONAR

El primer paso es hacerlo funcionar. Para este paso debe hacer que el código cumpla lo que se supone que debe lograr de la forma en la que usted lo desee sin importar si la solución es fea y desordenada, siempre que funcione. No pierda el tiempo preocupándose si su enfoque es ideal, si su código elegante o sus patrones de diseño son perfectos. Si puede ver múltiples formas de hacer algo, y no está seguro de cuál es el mejor, elija uno y continúe. 

Puedes dejar comentarios sobre ideas de implementación o mejores formas de desarrollar el proceso en alguna libreta o hacer una nota en tu computadora si crees que son lo suficientemente importantes como para volver a visitarlas. De lo contrario, cuando hayas terminado, asegúrate de que funcione y que funcione de forma repetible. Debe tener algún tipo de pruebas automatizadas que demuestren que funciona.

EL SEGUNDO PASO: HAZLO CORRECTO

Una vez que tenga una solución que funcione y una forma económica de garantizar que siga funcionando mientras la modifica, siga los fundamentos de refactorización para mejorar el diseño de su código. Busque las deficiencias de código que pueda mejorar. Siga los principios del software y asegúrate de que sea lo suficientemente bueno para que cuando vuelvas a revisarlo.

Queremos eliminar cualquier dato incrustado directamente, queremos comenzar a pensar en los casos límite y definitivamente necesitamos tener pruebas alrededor del código. Para las pruebas, asegúrese de comentar el código durante el desarrollo y de eliminar código erróneo al ver una prueba fallida. Nunca confíe en una prueba durante esta etapa a menos que vea que falla primero por la razón correcta.

Nuestro código debe ser a prueba de balas al final de la etapa "hazlo correcto". No debemos dudar acerca de presentar este código a un usuario desde el punto de vista que su comportamiento pueda generar un error. Una solución ya en este segundo paso debe estar lista para la producción.

EL TERCER PASO: HAZLO RÁPIDO

Si ya no es lo suficientemente rápido (en términos de rendimiento), ahora es el momento de medir y ajustar el rendimiento de la aplicación. Las características de rendimiento del sistema deben describirse al igual que otros requisitos del sistema, y se debe hacer un esfuerzo para mejorar el rendimiento solo hasta que se cumplan estos requisitos medibles.

En el siguiente video se explica un resumen del contenido de esta sección.