Defensor aférrimo, como soy, de la Ley del mínimio esfuerzo, intento aplicarla en todas las facetas de mi vida, y por supuesto en el desarrollo de software. Al fin y al cabo ¿Para qué se desarrollan la mayoría de aplicaciones software? ¿no son para facilitar, acelerar y mejorar tareas?
Muchas veces, cuando sale este tema, no soy capaz de comunicar el verdadero valor de tener presente esta ley a la hora de acometer un trabajo (trivial o complejo).
Aplicar la ley del mínimo esfuerzo no es sinónimo de procastinar o de no querer realizar determinada tarea. Es lo contrario. Persigue realizar las tareas, pero con el menor esfuerzo posible. Un mayor esfuerzo no implica un mejor resultado.
La ley del mínimo esfuerzo no trata de dejar de realizar tareas, al revés, el objetivo fundamental es cumplir con los objetivos marcados, pero utilizando para ello el mínimo gasto de energía posible.
Aplicar esta ley en el ámbito de desarrollo de software nos ayudará a optimizar nuestros esfuerzos, llevándonos a actuar de una manera mas eficiente.
A continuación expongo algunos momentos en los que aplicar esta ley me ayuda.
Piensa mas, escribe menos código
Muchas veces la inercia nos lleva a empezar a escribir código como pollo sin cabeza. Los motivos pueden se variopintos, como por ejemplo: hay prisa, esto es fácil lo hago en un momento, ya lo hice en otra ocasión y lo voy a implementar igual, etc, etc.
Cuidado con esto, o el esfuerzo será doble (incluso triple), cuando te des cuenta de que has empezado la casa por el tejado, y mucho del código que ya has escrito no sirve, es duplicado, o está para tirarlo.
Creo que siempre es bueno tomarse un tiempo de reflexión, análisis del problema y por supuesto análisis y diseño de la solución.
El pensar también consume energía, pero es posible que menos esfuerzo que hacer para deshacer.
Simpre me ha gustado, y nos hemos reido con la expresión: "Usar la cabeza para llenar la panza, sin doblar la espalda"
Reutiliza (tu) código
¡No! copiar y pegar no es reutilizar. Estoy ya harto de tener que recordarlo. Si copias un código de otro sitio (incluso otro proyecto), ¿Qué pasa si hay que realizar una modificación en ese código? ¿y si lo tienes en 20 sitios? puf! esto va totalmente en contra de la ley de mínimo esfuerzo.
Por tanto, reutiliza el código existente, mejóralo y compártelo. Crea librerías, servicios o aquello que te libere de esfuerzos futuros. Evita copiar y pegar, y si lo haces anótalo para mejorarlo.
No reinventes la rueda
Una frase tan usada y repetida que me cansa. Pero es que ¡es verdad!
Solo en ocasiones excepcionales tendremos que reimplementar algo que ya está hecho. ¿No es mejor revisar los tipos de ruedas que ya existen y elegir la que necesitas?. El 99% de las ocasiones tendrás una rueda que te sirva, quizá tendrás que customizarla de alguna manera, pero no es lo mismo que hacerla de nuevo entera.
En el caso de que en verdad necesites una rueda que no existe ya sabes piensa antes de escribir código.
Y aquí voto por el software libre. Cuanta cantidad de horas me ha ahorrado ese maravilloso pensamiento y aplicación de libertar. ¡Gracias!
Divide y vencerás
Efectivamente,
otro clásico. Divide un gran esfuerzo en pequeños esfuerzos. Para subir
una escalera, se deben subir primero todos sus escalones.
¿No ves la manera de dividir el esfuerzo? Puedes aplicar filosofía
KAIZEN, aplicando pequeños cambios o mejoras (en pequeños esfuerzos), hasta conseguir el objetivo final.
Refactorizar
Acción y efecto de mejorar el código. Si mejoras el código será mas mantenible, si es mas mantenible te dará menos trabajo en un futuro. et voilà! menos esfuerzo.
Y eso que parece que refactorizar lo que nos da es mas trabajo e incumpliría la ley. Demostrado en mis carnes que eso no es así. Y si consigues aplicarlo como un proceso habitual lo agradecerás. Esto si que es filosofía
KAIZEN;
mejora continua.
Lo que si recomendaría es realizar estas tareas a primera hora, cuando el cerebro aún está fresco. Dedicar un tiempo prudente a diario, sin pasarse o entraremos en el bucle de la refactorización infinita, y eso ya si que incumpliría la ley.
Herencia y polimorfismo
Un guiño aquí a los lenguajes de programación orientados a objetos. Que bonito estos dos conceptos tan antiguos y como los debió inventar alguien que no tenía ganas de esforzarse tanto. La herencia y el polimorfismos son dos grandes ejemplos de aplicación de la ley del mínimo esfuerzo en el desarrollo de software.
Programación funcional
Aplicar el paradigma funcional te puede ahorrar esfuerzo. Ya sabes, se implementa lo que quiero hacer, no como lo estoy haciendo.
Haz lo mínimo y ve mejorándolo
Aborda un desarrollo teniendo en mente lo mínimo que hay que hacer para que funcione. No te saques funcionalidades de la manga, que nadie ha pedido. De otra manera estarás dedicando mucho esfuerzo a conseguir el objetivo.
Cuando lo tengas, dedica pequeños esfuerzos a mejorarlo, y en ese momento añade la funcionalidad fantástica que querías al principio.
Cuidado ¡Sobrediseño!
Solo oír sobre diseño ya suena a sobre esfuerzo. Cuidado con esto, que al final se dedica mucho mas esfuerzo a crear y mantener una arquitectura, que a desarrollar la solución necesaria.
Y puedo poner ejemplos (por los que algunos me van a criticar):
Usa interfaces cuando sea necesario. ¿Cuantas veces os encontráis una interfaz que solo tiene una implementación? sinceramente, para mi gusto, incumple la ley del mínimo esfuerzo. Por muy bonito que se quede eso. ¿Qué pasa si tienes que modificar la API de la interfaz?, tienes que modificar la interfaz y la implementación (doble trabajo).
CQRS (podría poner otro ejemplo pero se me ha venido este), en proyectos pequeños no tiene sentido usar este tipo de patrones. Me obliga a tener modelos de consulta, modelos de comando, sincronizar, etc, etc. Mucho esfuerzo, por ejemplo para un simple microservicio que puedo hacer con 2 ó 3 clases.
Pregunta
Una pregunta a tiempo vale mas que horas de programación en solitario. Si tienes alguna duda o te atascas en algo, lo mejor es pararte y preguntar a alguien con mas experiencia, conocimiento de negocio o compañero de fatigas.
Es bastante probable que te ayude a encontrar la opción menos costosa para conseguir tu objetivo. En el caso de que falle esta opción, el esfuerzo y tiempo que le has dedicado no habrá sido muy elevado.
Principio de Pareto
Ya sabéis la regla del 80/20 aplicada al desarrollo de software. Existe un desequilibrio entre el trabajo y el rendimiento. Con el 20% del tiempo puedes realizar el 80% del trabajo. O como más me gusta a mi verlo: el 80 % de los resultados provienen del 20 % de las acciones.
No rompas el Principio de Pareto dedicando mucho mas tiempo del estrictamente necesario a conseguir el objetivo. Si lo consigues tendrás mucho adelantado, pudiendo centrar esfuerzos en el resto de tareas.
Test automatizados
Cada vez que tocas algo, debes asegurarte de que no se ha roto otra cosa. Si tienes que realizar pruebas manuales, al final dejarás de hacerlas (cansa mucho) probando exclusivamente lo que has tocado.
Tener y mantener una buena cobertura de pruebas ahorra mucho esfuerzo, además de dolores de cabeza.
En este apartado voy a decir que lo mejor es que los test los implemente un compañero (incluso jugando a ping-pong). Consigues varias metas con esto: el esfuerzo lo hace otro, consigues involucrar en la implementación de la solución a otra persona y seguro que hace los test a "mala leche". Porque mola sacar errores del código de otros ¿verdad?
Lo voy a dejar por aquí, que ya me estoy esforzando demasiado ;o)
¿Qué técnicas usas tu para conseguir tus objetivos con el mínimo esfuerzo?
Cualquier comentario que me ayude a aplicar mejor la ley del mínimo esfuerzo se agradece.
Comentarios