Los profesionales del desarrollo de software son, en muchas ocasiones, autodidactas obligados a una constante evolución para no quedarse obsoletos en un mundo que cambia a velocidad de vértigo, produciendo nuevos lenguajes, componentes y herramientas cada día.
En medio de estos cambios, al menos podemos estar seguros de que algo no pasará de moda: las buenas prácticas, que cada vez se van definiendo y valorando más, a medida que la profesión madura y se consolida.
Ahora bien, si buscamos información sobre buenas prácticas, encontraremos múltiples recomendaciones, principios, acrónimos. Se hace difícil recordarlos todos o escoger cuáles son los más importantes para aplicarlos en el día a día.
Un día, navegando por internet, di con un breve pero interesante artículo de Martin Fowler (conocido por su libro Refactoring), donde explica cuatro reglas sobre el diseño de aplicaciones, definidas por Kent Beck (padre del TDD y del Extreme Programming) y quizás reinterpretadas por Fowler.
Estas cuatro reglas me encantaron porque son fáciles de recordar y son una excelente guía para crear buenas aplicaciones. Según ellas, una aplicación de diseño sencillo (o de buen diseño, diría yo) se caracteriza porque:
Pasa los tests
Revela intención
No hay código duplicado
Tiene los mínimos elementos necesarios
Las explicaré en orden inverso:
La cuarta regla me parece que es la que más encaja con el término de “diseño sencillo”. Si una aplicación tiene menos elementos, será más fácil de entender, de mantener y habrá menos puntos que puedan fallar.
La tercera regla está relacionada con la cuarta, porque cuando eliminamos duplicación estamos simplificando la aplicación. Además, cuando una aplicación tiene código repetido, es fácil caer en la trampa de realizar una modificación en una parte de la aplicación, y olvidar hacerla en la parte duplicada, dejando una inconsistencia peligrosa.
La segunda regla es mi favorita. Insisto en ella cada vez que imparto clases. Cuando leemos el código de un programa, debe estar claro qué está haciendo. Los nombres de los componentes, clases, funciones y variables deben ser claros, precisos, bien escogidos (¡esto es todo un arte!). La secuencia de instrucciones debe tener sentido y deberían ser evidentes incluso para alguien que no haya trabajado nunca con la aplicación.
La primera regla destaca la importancia de los tests. Aunque las demás reglas son igualmente importantes, al final, el objetivo de un programador es que una aplicación funcione como se espera, y no hay manera más evidente de asegurarlo que escribir tests.
Los principios de programación SOLID son una excelente guía para mejorar tus habilidades de programación.
Las buenas prácticas son cada vez más valoradas en el mundo del software, y la escritura de tests se está convirtiendo en un requisito indispensable para todo buen profesional. En el Curso de Testing con Java aprenderás los beneficios de los tests, cómo escribirlos y técnicas en auge como el TDD.
Continuous Integration, Continuous Delivery y Continuous Deployment; son una serie de pasos o buenas prácticas a seguir para conseguir una automatización completa.
No dejes de estudiar, mira este blog Java vs. Kotlin y descubre cuál es mejor.
Excelente artículo Ferran! Las buenas prácticas en programación son como la ortografía, se debe aprender para que luego surja naturalmente. Saludos.
Faltaría un curso de testing con .net 😦
Es una gran verdad, las buenas prácticas son fundamentales. Excelente exposición!
👨💻 Para llegar ser un buen programador, se necesita tener 2️⃣ grandes destrezas:
✅ organización
✅ análisis
Aunque no todos las poseemos, por experiencia propia les menciono que se pueden obtener con mucha disciplina.
Son estos los consejos que puedo dejar a esta fantástica comunidad. Por ultimo, les dejo una referencia a un libro que me brindó una guía de como lograr esto, para poder escribir código intuitivo y profesional 😊
const documento = { nombre: 'Clean Code', Autor: 'Robert C. Martin' }
Buen libro ese! recomendado!!
El buen código debe ser como un buen chiste, no necesita comentarios para explicarlo, si no, pues no es bueno, poner la mínima cantidad de comentarios para explicar una función demuestra que al ser código autodescriptivo es bueno
Pero los comentarios sirven demasiado para recordarte a ti mismo u otros programadores cómo funcionan ciertas partes de tu código (sobre todo cuando son proyectos grandes y muy específicos según el giro del negocio). Saludos.
Coincido con Darvin, todo código debe estar comentado para el buen entendimiento del equipo, incluso para uno mismo.
Saludos
Excelente artículo. Me anima a poner en mi lista de cursos deseados el curso recomendado, y sobre todo, a apuntar y no olvidar esas recomendaciones y aplicarlas en todo momento.
Gracias
Me parece un buen articulo, corto pero claro y asertivo.
Es algo necesario a tener en cuenta cada que trabajamos en un sistema. He sido insultado y tomado por inepto por personas con las que he colaborado, por recalcar en estos temas más que en la velocidad de desarrollar la app. Pero sigo firme en que esto es de lo más importante, si no es que es lo principal a la hora de desarrollar algo.
Interesante artículo.
Poca información mucha sabiduría. =D
Excelente!
Una buena documentación unas buenas pruebas y una buena arquitectura son razones para hacer y mantener un desarrollo
No se ha podido explicar mejor Ferran. ¡Muy buen post!
gran artículo enhorabuena 👍🏻
Muy buenas recomendaciones! Siempre es bueno tener en cuenta todos esos puntos!
Me encanta, yo como amateur en este mundo necesito aplicar esas reglas a mi vida para tener siempre buenas prácticas.
El sólo hecho de reconocer que debes (al igual que todos debemos) aplicar buenas prácticas de programación ya nos hace salir de ser amateur para llegar a ser profesionales. Saludos y éxitos.
Muy buen post, la verdad como dice @fredier. "Tener buenas prácticas de ejecución al momento de programar
as escrito tests?
Muy buen artículo, asegurar que la usabilidad para un usuario sea sencilla y predictiva, es muy importante para la continuidad en su utilización.
Saludos
gracias buen artículo, estoy justo haciendo mi ejercicio de los número romanos, ya me está tomando algún tiempo. Pero voy bien
A mí personalmente, lo que más me ha costado trabajo es simplificar y reutlizar código, pero claramente con la práctica se hace más sencillo ir reconociendo dónde y cómo hacer código útil para no repetirte. Lo primero que me :exploding_head: fueron las variables y los mixins y ahora estoy fascinada con los componentes de REACT…