Llevo tiempo trabajando no con un equipo, con un equipazo, y parte de nuestro tiempo lo pasamos discutiendo y filosofando acerca de la mejor manera de afrontar un desarrollo.
En todas estas discusiones (casi siempre gracias a Manuel) aparecen referencias a «filosofías«, «principios» o «leyes» que ha formulado alguien, que ya se ha encontrado antes con un problema similar al tuyo.
Puede parecer trivial, pero escuchar a la voz de la experiencia, te dará una visión casi siempre acertada de cómo afrontar un problema, sabiendo que ese camino lo han recorrido antes otras personas, y de otro modo es probable que tengas más problemas.
Son aplicables a la mayoría de los proyectos y equipos de trabajo, y no sólo para proyectos tecnológicos… algunas pueden ser incluso una forma de pensar, un modo de vida, una soft skill… Me he decidido a compartir un listado en este post, que espero te aporte algo en tu día a día.
DRY
Don´t Repeat Yourself. Este principio es una filosofía para definir los procesos, que viene a decir que debemos evitar métodos o clases que hagan prácticamente lo mismo. Esas «pequeñas» diferencias las podríamos resolver utilizando algún parámetro, algún condicional, etc…
Si tenemos métodos o clases que hacen prácticamente lo mismo, cada cambio o evolución posterior puede perjudicar al proyecto: dificultades, poca escalabilidad, inconsistencias, etc…
Dicho de otro modo, con un DRY bien aplicado, si necesitamos realizar modificaciones en un proceso, estas deberíamos hacerlas en un único punto del proceso. Si tenemos que hacerlas en 2 o más sitios, es una evidencia clara de que el proceso se puede mejorar.
En proyectos grandes te encontrarás con métodos o clases que hacen las mismas comprobaciones. Lo más eficiente es extraer estas comprobaciones a un «Helper», y llamarlo desde cada clase o método que lo necesite. Así, si mañana necesitas realizar un cambio en estas comprobaciones, sólo «tocarás» ese Helper y no todas las clases que lo utilizan.
Más info sobre DRY.
KISS
Keep It Simple, Stupid. Se traduciría como manténlo sencillo, estúpido. Viene a decir que cuanto más complejo sea una clase, método, proceso o sistema, más probable es que aparezcan los problemas.
Este principio recomienda buscar enfocar los desarrollos desde la sencillez, la complejidad innecesaria debe ser eliminada. Está estrechamente relacionado con uno de los principios SOLID, concretamente el de responsabilidad única, que se basa en que cada clase o método sólo debe hacer una cosa, sencilla y concreta. Si un objeto tiene un sólo cometido, éste será más fácil de mantener y entender.
La simplicidad es la máxima sofisticación
Leonardo Da Vinci
Más info sobre KISS.
YAGNI
You Aren’t Gonna Need It. Se traduce como No vas a necesitarlo. Es una filosofía que te recomienda no desarrollar o agregar una funcionalidad nueva excepto cuando sea necesario.
Me pasa mucho, y a mucha gente, que te piden que desarrolles algo (a priori) sencillo y acabas haciendo un motor para generar no sé que cosas, por si el día de mañana… y de hecho, llegado este punto, solemos sentenciar: ¡Esto es un YAGNI en toda regla!
Está muy bien pensar en el mañana, pero a veces hacemos mucho más de lo que nos piden, sobre todo si no te lo han pedido o definido. Y cualquier nueva funcionalidad añadirá más tiempo de desarrollo, más complejidad y pondrá en riesgo los compromisos de entrega.
Al final se produce un efecto bola de nieve, y te comes el tiempo y los recursos que habías planificado para una tarea añadiendo funcionalidad que no te han pedido por si el día de mañana…
Más info sobre YAGNI.
La regla del Boy Scout
La regla del Boy Scout consiste en dejar el sitio donde se realiza el campamento un poco mejor de como te lo encuentras al llegar.
Aplicado al desarrollo, aconseja que cuando vayas a realizar una modificación sobre un método o clase existente, aproveches para dejarla un poco mejor de lo que estaba, por ejemplo añadiendo más documentación, añadiendo tests si no los tuviera, extraer parte de la funcionalidad a otros métodos para cumplir con SOLID, etc…
Todos los desarrollos, con el paso del tiempo generan deuda técnica. Y en muchas ocasiones (lamentablemente más de las que nos gustaría), negocio o tu cliente no entiende o no prioriza el mantenimiento y/o refactor que todo proyecto necesita. Con esta regla del Boy Scout al menos puedes ir reduciendo esta deuda en aquellos sitios sobre los que necesites hacer modificaciones.
Esta regla es un arma de doble filo. No conozco a nadie que no le guste realizar su trabajo de la mejor manera posible, pero hay que tener muy presente que es importante acotar el alcance de estas mejoras, ya que de lo contrario te puedes meter en refactorizar toda una funcionalidad completa y que te lleve semanas de trabajo.
Esta regla simplemente te dice que dejes la clase o el método sobre el que vas a realizar modificaciones un poco mejor de lo que te lo encontraste, no que refactorices toda la funcionalidad completa. ¡Keep calm!
La regla de los 3 strikes
Esta regla o norma, está íntimamente relacionada con el principio de responsabilidad única y sobre todo con DRY. Viene a decir, que es necesaria una refactorización de tu código cuando tengas tres procedimientos «similares».
Es decir, que dos casos de código similar no requieren refactorización (aunque es recomendable), pero cuando se da un tercer caso, ya es necesaria esta refactorización.
La duplicación es una mala práctica en programación, como vimos en DRY. Esta regla «te obliga» a actuar si se repite código 3 o más veces, ya que el coste del mantenimiento a la larga supera al coste de refactorizarlo.
Más info sobre la regla de los 3 strikes.
El efecto del segundo sistema
Es muy común en los proyectos grandes, que se realicen «motores» o «sistemas» para generar algo que satisfaga tus necesidades.
Poniendo un ejemplo, para que se entienda más claro, para un proyecto hemos tenido que generar un motor de metaboxes, para que desde un array poder crear metaboxes, definir sus custom fields, establecer validaciones, configurar donde deben mostrarse, quien puede verlos, diferentes comportamientos y un largo etcétera…
En un momento dado, ese monstruito puede ser tal y haber crecido tanto que se plantee la necesidad de comenzar de cero. Aplicar una refactorización completa puede llevar mucho tiempo, sobre todo si está muy extendido por el resto del proyecto.
Es entonces cuando alguien propone hacer un motor o sistema nuevo mejor, aprovechando la experiencia del anterior, y que los nuevos metaboxes se generen con este, y poco a poco ir migrando el resto… es aquí cuando se produce el efecto de los dos sistemas, con su coste de duplicar mantenimientos, inconsistencias, etc… y si no disponemos nunca del tiempo necesario para completar ese viaje de migración, pondremos en riesgo el sistema completo y dejaremos una deuda técnica importante.
Más info en el libro de Fred Brooks.
9 mujeres embarazadas no pueden dar a luz en un mes
Cuando das una estimación a tu cliente o a tu jefe, y le dices por ejemplo que para hacer tal cosa tardas 8 semanas, siempre siempre siempre van a intentar buscar la manera de reducir el tiempo estimado.
¿Y cuál es el primer pensamiento que les viene a la cabeza? Pues que si una persona tarda 8 semanas en realizar un nuevo desarrollo, pues entre 2 personas lo harán en 4 semanas…o mejor aún, entre 4 personas lo harán en 2 semanas.
Pues nada más lejos de la realidad. Al igual que un embarazo dura 9 meses, no se puede pretender dar a luz en un mes si lo hacen entre 9 mujeres. Es un símil que se utiliza mucho, y es porque en la práctica no todo puede dividirse, y aunque se divida, muchas tareas acaban dependiendo de otras y no se pueden paralelizar.
No es ciencia exacta, si esa tarea de 8 semanas se aborda entre dos personas, es probable que se reduzca, pero no a 4 semanas… lo mismo a 5 ó a 6. Es evidente que metiendo más manos se avanzará más rápido, pero aparecen otro tipo de variables en la ecuación: dependencias, comunicación, gestión, coordinación… que también consumen tiempo.
Más info en el libro de Fred Brooks.
Ley de Brooks
Siguiendo con Fred Brooks… en su libro El Mítico Hombre-Mes: Ensayos de ingeniería de Software, su tema central afirma que añadir más efectivos a un proyecto de software en desarrollo, lo retrasará más.
Incorporar a una persona nueva a un proyecto y a un equipo de desarrollo, lleva tiempo. Nosotros lo llamamos aterrizaje. Una nueva incorporación requiere de una formación por parte de los miembros del equipo, y de un tiempo de adaptación por parte de la nueva persona.
Por lo tanto, la nueva incorporación no es productiva desde el minuto cero como algunos pretenden creer, y al menos una de las personas del equipo dejará de ser productiva durante un tiempo. Las nuevas incorporaciones dan resultado a medio-largo plazo.
Este proceso dependerá de cada compañía, equipo de trabajo y proyectos, pero podría oscilar perfectamente entre uno y cinco meses para que alguien pueda empezar a dar resultados.
Más info sobre la Ley de Brooks.
RERO
Release Early, Release Often. Se traduce como publica temprano, publica a menudo. Esta filosofía recomienda que publiques tus desarrollos en cuanto los tengas, y de manera frecuente.
De este modo el producto estará en producción antes y obtendrás el mejor testing y feedback posible: el de los usuarios finales. Con el tiempo obtendrás un producto mejor gracias al feedback de los usuarios.
Y además de mayor calidad ya que detectarás y detectarán problemas, fallos, bugs… y podrás corregirlos rápidamente para la siguiente versión.
Está íntimamente relacionado con Fail Fast (falla rápido), ya que un error no detectado puede ser peligroso cuanto más tiempo pase antes de corregirlo.
Más info sobre RERO.
Mide dos veces, corta una
También conocida como la regla del carpintero. Te aconseja que compruebes dos veces lo que vas a hacer antes de hacerlo… una vez que cortas un listón de madera, ya no hay vuelta atrás.
En el desarrollo de software esta regla es muy recomendable por ejemplo cuando vayas a realizar una actuación en BBDD. Si lanzas un UPDATE o peor aún, un DELETE a registros en la BBDD, y posteriormente te das cuenta que has dejado algo sin contemplar, ya no hay vuelta atrás.
De hecho es bastante famoso el meme de hice un delete y olvidé poner el WHERE, y hasta tiene canción:
Principio del menor privilegio
Este principio es una estrategia de seguridad, que recomienda asignar únicamente permisos limitados a un usuario en función de su rol o status dentro de un equipo. Esta asignación de permisos de usuario sobre un desarrollo, proyecto, o mera información… es una práctica de seguridad que se aplica de forma continua en el mundo real.
También es un principio de responsabilidad, se trata de sólo dar acceso a diferentes roles a determinadas funcionalidades/características de un desarrollo.
Extrapolando este principio a WordPress por ejemplo, un usuario de rol administrador podrá hacer de todo, y dentro de lo que cabe es normal, para eso es administrador. Pero puedes querer crear un perfil «SEO», y a través de capabilities limitarle sus funciones, para que solo edite o cree aquello que tiene que ver con su puesto/función.
Por un lado acotas su responsabilidad a lo que debe hacer, por otro es más seguro no darle más permisos de los que necesita porque podría romper algo que no le atañe.
Esto se vuelve más crítico si en tu aplicación/desarrollo tratas información relevante, datos de terceros, etc… resumiendo… que cada rol/usuario sólo pueda acceder a aquello acorde con sus actividades, funciones y responsabilidades. Ni más ni menos. No tener esto bien definido, puede ocasionar una brecha de seguridad, fuga de información, etc…
Principio del menor conocimiento (Ley de Démeter)
El principio del menor conocimiento se suele aplicar a desarrollos con programación orientada a objetos. Se conoce también como Ley de Démeter o No hables con extraños.
Su directriz fundamental establece que una pieza de código sólo debe conocerse a sí misma, y como mucho otras piezas con las que tenga una estrecha relación. Intenta que el nivel de acoplamiento sea bajo y que no existan dependencias.
Cuanto más acoplado esté un código y más dependecias existan, mayor serán los problemas que tendrás a futuro, más difíciles los evolutivos o modificaciones, y con mayor riesgo de romper algo.
Más info sobre la Ley de Démeter.
Bonus
Actualizo este post con el enlace a una charla que impartir en el I Festival Agile Trends que se celebró en Septiembre de 2020: https://es.slideshare.net/PabloLopezMestre/festival-agile-trends-2020
Pues hasta aquí el listado de principios, filosofías y leyes, ¿conoces tú alguna más que apliques en el desarrollo de software? Anímate a compartirla en los comentarios
Puede que también te interese
