Buenos habitos en el desarrollo de software

Me cruce con este articulo (en ingles) que tiene algunas buenas practicas para tener en cuenta. Es totalmente agnostico de la tecnologia que usen, asi que aplica a todo 🙂

1. Hacer commits chiquitos como para que te preguntes si estás llevando esto de "mantener los commits chiquitos" demasiado lejos. Nunca sabes cuándo tendrás que revertir un cambio en particular, y es una bendición saber exactamente dónde metiste un bug hace seis días y poder revertir solo ese commit sin enfrentarte al infierno de los conflictos de un merge. Mi regla general: si compila, debería ser commitable.
2. Vive las sabias palabras de Kent Beck: "para cada cambio deseado, primero haz que el cambio sea fácil (advertencia: esto puede ser difícil), y despues haz el cambio fácil". Apunta a que al menos la mitad de tus commits sean refactorizaciones. El refactorizado continuo es pensar en cambios que puedo hacer en menos de 10 minutos que mejoren algo. Hacer esto da frutos cuando aparece un requerimiento mas grande y lo resolves con un pequeño ajuste, gracias a esas pequeñas mejoras. Las grandes refactorizaciones son una mala idea.
3. Todo código es una responsabilidad. El código que no deployamos es la peor de ellas. Necesito saber si funciona o al menos que no rompe nada. Los tests te dan confianza, pero el entorno de produccion te da aprobación. Los costos de hosting pueden aumentar con tantos deploys, pero es un pequeño precio a pagar por saber que el último cambio fue realmente un paso adelante. El software funcionando es la principal medida de progreso, dice uno de los principios ágiles. "Funcionando" y "progreso" cargan mucho peso en esa frase, así que busquemos una definicion que se entienda: Funcionando es algo que se puede deployar; y progreso es cualquier código que haga algo.
4. Saber cuándo estás probando la capacidad del framework que estas usando es clave. Si lo estás haciendo, no lo hagas. El framework lo probaron personas que saben mas que vos, y tenes que confiar en que el hook useState() hace lo que debe. Si mantenes los componentes pequeños, reducis la necesidad de muchos tests, ya que el framework hará gran parte del trabajo pesado en el componente. Si el componente es grande, se vuelve mas complejo, y ahora tenes que escribir muchos tests.
5. Si una función no encaja en ningún sitio, crea un nuevo módulo (o clase o componente) para ella, y ya le encontrarás un lugar después. Es mejor crear un nuevo archivo independiente que meterla a la fuerza en un módulo existente donde sabes, en el fondo, que no tiene sentido. En el peor de los casos, vivirá como un módulo independiente, lo cual tampoco esta tan mal.
6. Si no sabes cómo debería verse una API, escribe primero los tests, ya que te obligará a pensar en el "cliente", que en este caso sos vos. Inevitablemente descubrirás casos que no habrías pensado si hubieras escrito el código primero y los tests después. No tenes que ser religioso con el TDD, y está bien trabajar en pedazos más grandes (por ejemplo, escribir un par de líneas de código antes de hacer que pase el test). No siempre tenes que escribir una cantidad pequeña de código en un estado rojo/fallido. Vos sabes lo que estás haciendo, no dejes que el dogma interfiera con la productividad.
7. Hacer copy-paste está bien una vez. La segunda vez ya es duplicado (o sea, ya tenes tres copias del codigo), y deberias evitarlo. Para ese punto, deberías tener suficientes datos como para crear una abstracción adecuada. El riesgo de implementar cosas de manera divergente es muy alto, y es necesario consolidar. Es mejor una funcion con argumentos raros que tener varias implementaciones de casi lo mismo. Mejorar los argumentos va a ser más fácil que consolidar cuatro implementaciones diferentes si vuelve a suceder.
8. Los diseños se quedan obsoletos. Puedes reducir la velocidad a la que se vuelven obsoletos refactorizando, pero al final necesitarás cambiar cómo funcionan las cosas. No te sientas mal por alejarte de algo que te gustaba mucho y de lo que te sentías orgulloso en su momento. En ese momento estaba bien, y no deberías castigarte por no haberlo hecho tan bien que no necesitaras cambiar nada. La mayoría del tiempo escribir software es cambiar software. Acéptalo y sigue adelante. No existe el diseño perfecto, y el cambio es el core del desarrollo de software. Qué tan bueno eres cambiando las cosas define qué tan bueno eres desarrollando software.
9. La deuda técnica se puede clasificar en tres tipos principales: 1) cosas que te impiden hacer algo ahora, 2) cosas que te impedirán hacer algo más adelante, y 3) cosas que podrían impedirte hacer algo más adelante. Todas las demás clasificaciones son subgrupos de estos tres. Minimiza el número de cosas en el grupo 1 y concéntrate en el grupo 2. Ignora el grupo 3.
10. La capacidad de testear está correlacionada con un buen diseño. Si algo no se puede testear fácilmente, es una señal de que el diseño necesita cambiar. A veces, ese diseño es tu propio diseño de tests. Por ejemplo, si te resulta difícil mockear em.getRepository(User).findOneOrFail({id}), lo más probable es que necesites poner esa llamada en una función que se pueda mockear o escribir una utilidad de tests que facilite el mockeo de los métodos del entity manager. Los tests no se escriben cuando es difícil testear, no porque no quieras hacerlo.

Fuente original: Good software development habits