Buenos hábitos de desarrollo de software

• Este texto no es un conjunto de consejos, sino una descripción de los hábitos de desarrollo que el autor aplica actualmente
• Es un artículo que organiza la experiencia de intentar evitar malos hábitos y formar buenos hábitos, y aborda 10 prácticas que ayudaron a mejorar la productividad y mantener la calidad

1. Mantener commits pequeños

• Los commits deben mantenerse lo más pequeños posible. Los commits pequeños permiten revertir solo un commit específico cuando aparece un bug, evitando conflictos de merge complejos
• Se adopta como regla que “deberías poder hacer commit cuando el software compila”

2. Refactorización continua

• Consejo de Kent Beck: “Cuando quieras hacer un cambio, primero haz que el cambio sea fácil, y luego haz el cambio fácil.”
• Al menos la mitad de los commits deberían incluir refactorización. Las refactorizaciones pequeñas ayudan mucho cuando llegan requerimientos grandes
• Hay que evitar las grandes refactorizaciones. En su lugar, realizar continuamente pequeñas mejoras de menos de 10 minutos

3. La importancia de desplegar código

• El código en sí es deuda potencial, y el código no desplegado es la deuda más grande
• Las pruebas dan confianza, pero el despliegue real significa la verdadera aprobación
• A medida que aumenta la frecuencia de despliegue, los costos de hosting pueden subir, pero comprobar que el trabajo más reciente realmente funciona es una ventaja importante

4. No probar funcionalidades del framework

• No se prueban funcionalidades del framework. El framework ya ha sido suficientemente validado
• Si los componentes se mantienen pequeños, el framework se encarga de la mayor parte del trabajo y se reducen las pruebas
• Los componentes grandes agregan complejidad y, en consecuencia, requieren muchas pruebas

5. Crear un nuevo módulo

• Si una funcionalidad específica no encaja en un módulo existente, es mejor crear un módulo nuevo
• Es preferible dejarla como un módulo independiente en lugar de forzar la incorporación de la funcionalidad a un módulo existente

6. Aplicación flexible del desarrollo guiado por pruebas (TDD)

• Cuando el diseño de la API no está claro, se escriben primero las pruebas para pensar desde la perspectiva del “cliente”
• TDD no se sigue como un principio religioso. Si hace falta, se puede trabajar en unidades más grandes y luego probar
• No es necesario dejar pequeñas unidades de código en estado de fallo, ni quedar atado a un dogmatismo que perjudique la productividad

7. Copiar y pegar solo se permite una vez

• Una copia está bien, pero a partir de la segunda ya hay duplicación
• En ese punto hay que eliminar la duplicación mediante una abstracción adecuada. Aunque la parametrización se vea un poco extraña, sigue siendo mejor que fusionar varias implementaciones

8. Aceptar los cambios en el diseño

• El diseño envejece con el tiempo. La refactorización puede retrasar ese envejecimiento, pero al final inevitablemente cambia
• No hay que aferrarse demasiado al diseño anterior; hay que aceptar el cambio
• No existe un diseño perfecto, y la capacidad de adaptarse bien al cambio es la esencia del desarrollo de software

9. Tres tipos de deuda técnica

• La deuda técnica puede clasificarse en tres tipos:
  1. Lo que interfiere con el trabajo actual
  2. Lo que podría interferir con trabajo futuro
  3. Lo que tal vez podría llegar a interferir
• Hay que minimizar el primer tipo de deuda, enfocarse en el segundo e ignorar el tercero

10. La relación entre la capacidad de prueba y un buen diseño

• Si es difícil de probar, es muy probable que haya un problema en el diseño
• El diseño de las pruebas también puede mejorarse. Por ejemplo, si resulta difícil crear un mock de em.getRepository(User).findOneOrFail({id}), conviene separarlo en una función aparte o usar utilidades de prueba
• La razón por la que no se escriben pruebas es que son difíciles de hacer, y eso puede ser un problema de diseño

[yangeok]

Parece que antes que DRY, hay que lograr SRP; incluso si se lo dejas a la IA, así no termina diciendo tonterías.

[progdesigner]

Creo que lo más importante es qué tan bien has construido un código y un entorno que puedan adaptarse rápidamente a los cambios.

Y, mediante una abstracción adecuada, puedes aumentar la reutilización y la escalabilidad del código, y aprovechar herramientas de IA para maximizar la velocidad de desarrollo.

[pcj9024]

Es un artículo realmente muy bueno. Dan ganas de recomendarlo por todos lados.

[tsboard]

Aceptar el cambio, copiar y pegar solo una vez, hacer que las pruebas funcionen mejor, hacer commits más pequeños...!

[aer0700]

Es un buen artículo.

[puersum]

Creo que vale mucho la pena ver el original.
Cuando es una noticia que me interesa, suelo revisar la fuente, pero en este caso especialmente conviene hacerlo. Si miran el punto 1, el texto original dice
Keep commits small enough that you wonder if you're taking this "keep commits small" thing a little too far. y aquí quedó resumido como "hay que mantener los commits lo más pequeños posible"..

[ilbanin00]

Qué buen artículo, de verdad.

[joon14]

El punto 7 es realmente muy bueno.

[GN⁺]

Comentario de Hacker News

• Es mejor usar parámetros para evitar múltiples implementaciones. Mejorar los parámetros es más fácil que unificar varias implementaciones.

  • Si no se pueden evitar los "parámetros extraños", es mejor separar el código. Hay que evitar las banderas booleanas y los múltiples parámetros de tipo enumeración.
  • Las firmas de función complejas dificultan el mantenimiento.

• Copiar código una vez está bien, pero a partir de la segunda vez hay que evitar la duplicación. Hay que crear una buena abstracción cuando ya se tienen suficientes puntos de datos.

  • Aunque al principio el código sea igual, cuando haga falta cambiarlo hay que enfocarse en si debe cambiar junto.
  • El objetivo no es evitar la duplicación de código, sino mantener juntas las partes del código que deben evolucionar juntas.

• DRY (no te repitas) o WET (escribe todo dos veces) no son reglas absolutas. Lo difícil es entender el problema del momento adecuado para duplicar código o integrarlo.

• Como alternativa a los commits pequeños, se puede agregar un nuevo commit que corrija bugs sin revertir un commit grande.

  • No está claro por qué un refactor grande sería necesariamente malo.
  • Crear una estructura independiente es mejor que forzarla dentro de un módulo existente.
  • Al diseñar una API, se pueden hacer sesiones de diseño en lugar de apoyarse solo en pruebas unitarias.

• La facilidad de prueba está relacionada con un buen diseño. Si algo no se puede probar fácilmente, puede ser una señal de que hace falta cambiar el diseño.

  • El código de prueba también debería revisarse de otras maneras.

• Hay que tener cuidado al probar funciones del framework. Los frameworks pueden cambiar con el tiempo.

  • Una función importante de las pruebas es verificar que sea seguro actualizar dependencias.

• Sobre el tamaño de los commits, hay que apuntar a commits que se puedan revertir con facilidad cuando sea necesario deshacer un cambio específico.

• Las empresas quieren una base de código estable, pero hace falta refactorización continua. Eso puede entrar en conflicto con la estabilidad.