Empecé a programar en 2016, hace ya 5 años. Desde entonces, aprendí mucho, y a un ritmo acelerado desde que estoy en Etermax. De alguna forma, este articulo apunta al Lautaro de 19 años qué desconocía el basto mundo de la programación y sobre qué podía estudiar.
Si no reconoces alguno de estos términos, me parece que está bueno que al menos los conozcas. Incluso si se puede dar el paso de investigar más y aprenderlo mejor. Personalmente, siempre trabajo respetando estos conceptos.
Clean Code
Por su traducción "código limpio", es la práctica de producir nuestro código de una manera que sea comprensible a la vista e intuitivo. Esto se puede lograr de múltiples maneras: manteniendo una lógica y estructura simple, refactoreando métodos, variables y clases, siguiendo principios como KISS, YAGNI o DRY
Creo que Clean Code es el concepto que más rápido uno puede ir desarrollando porque es algo con lo que se topa todos los días y es bastante sencillo de percibir. Al menos, revisar qué se podría refactorear, qué podría modificar para que el código se entienda mejor. Ya mencionado esto, les dejo una página con técnicas de refactors y otros conceptos interesantes (lamentablemente, por ahora sólo está en inglés)
Obviamente, esto tiene mucha más profundidad y quizás en otro momento haga una entrada específica de esta práctica. Por lo pronto, si quieren pueden leer el libro "Clean Code" de Robert C. Martin, quien yo considero que más me aportó en prácticas y conceptos de programación.
Patrones de diseño
Los patrones de diseño se suelen definir como soluciones a problemas comunes.
- ¿Hay problemas de performance a la hora de crear/instanciar muchos objetos? Usar un Pool Object.
- ¿Tenemos que implementar distintos tipos de comportamientos, que incluso podrían agregarse en el futuro? Usar Strategy.
- ¿Quiero tener muchos elementos que tengan los mismos datos pero sin que me explote la RAM? Usar un Flyweight
Estos son solo algunos de los patrones que existen. Les dejo una página que me sirvió en mi época de estudiante para estudiar patrones llamada refactoring.guru, de los mismos creadores de las técnicas de refactor.
Siempre que tengan un problema o una dificultad está bueno plantearse si algún patrón de diseño ya ataca su problema. Además, de la forma que están estructurados es muy fácil agregarlo en su proyecto. Lo que me lleva al siguiente punto.
SOLID
No es tan difícil encontrarse con este concepto. De base es de los más conocidos. SOLID es un acrónimo de 5 principios de programación que, si se respetan, logran que nuestro código sea más fácil de mantener y extender.
Explicaré sencillamente cada uno de los principios, pero piensen que hay artículos, videos y libros sobre esto, a los cuáles sólo puedo referenciar.
- S. Single Responsability Principle. Un objeto debería tener solo una responsabilidad. Yo solo tendría que tocar o buscar una clase por una sola razón.
- O. Open/Closed Principle. Las clases deberían estar abiertas para su extensión pero cerradas para su modificación.
- L. Liskov Substitution Principle. Cada subclase o derivada de una clase debería poder ser sustituida por la clase padre sin problemas.
- I. Interface Segregation Principle. Un cliente nunca debería ser forzado a implementar una interface que no va a usar, o depender de métodos que no usan. En otras palabras, segregar interfaces. Muchas interfaces cliente específicas son mejores que una interfaz de propósito general
- D. Dependency Inversion Principle. Depender de abstracciones, no depender de implementaciones. Aplicar la inyección de dependencias.
Ya haré otra entrada profundizando en los principios de SOLID, pero por lo pronto sirve para investigarlo.
Test Driven Design (TDD)
TDD es una práctica de programación donde se va construyendo el código a partir de tests, que serían como un caso de prueba o "examen" que se le hace al proyecto para saber si una funcionalidad se cumple correctamente; y refactors, que serían mejoras en el código para mejor entendimiento o performance.
Algunas de las ventajas de TDD son:
- Código por tests. Al programar solo en base a lo que el test requiera, uno podría decir que cada función, variable y línea sirve un propósito y pasó por una visión de refactor.
- Gran cobertura. Imaginemos cada funcionalidad de nuestro proyecto como si tuviese un caso de prueba y un checklist para ver si se cumplió correctamente. Imaginemos hacer un cambio a gran escala y tener una manera de corroborar rápidamente que no hay problemas. La cobertura con test de TDD nos ayuda muchísimo en esto.
- Documentación. No es algo extraño encontrarme necesitando entender una porción de código o necesitando copiar una funcionalidad como base y que un test ya hecho me salve el día. Si un test está bien escrito y redactado es simple de entender: "Si pasa X teniendo en cuenta Y obtengo el resultado Z".
Como también mencioné, voy a explicar estos puntos, otros que me quedaron y mi experiencia con TDD en otra entrada.
Domain Driven Design (DDD)
DDD es el concepto más nuevo que aprendí entre los anteriores nombrados. Básicamente, me ayudó mucho a la hora de armar la arquitectura de un proyecto más grande, y llevarme sus ventajas a proyectos más chicos.
Con este concepto nos referimos a la creación y desarrollo teniendo en cuenta el dominio. En otras palabras, teniendo en cuenta las necesidades y conceptos del negocio que se atienda.
Sin meternos tanto en teoría, me ayudaron mucho conceptos que maneja a la hora de hablar con stakeholders y el área de producto, y además para organizar el código en base a estas necesidades. Algunos de estos conceptos que me llevo para mis proyectos son:
- Entidades. Representan un objeto único en el proyecto. Ejemplo, la clase "User".
- Value Objects. Representan un valor complejo. Ejemplo, un struct "Money", que sería la moneda del negocio por ejemplo.
- Bounded Context. Tener bien definido y delimitados los contextos. No debería ser lo mismo ni estar entremezclados código entre la selección de ropa de una página web con su sistema de compras.
- Servicios. Representan clases que se encargan de comportamiento más complejo que las entidades sería raro que manejasen.
- Repositorios. Un lugar en donde guardar y obtener entidades.
Estoy explicando conceptos muy extensos en pocas líneas, pero la idea general es que me ayudaron en mi día a día manteniendo un orden en la arquitectura de un proyecto. No espero que lo entiendan con sólo este artículo pero, como mencioné antes, si que al menos ya conozcan el término y levemente de qué trata.
Explicar DDD en un artículo será un desafío interesante que voy a aceptar, pero mientras tanto, hay varios libros que pueden leer. Personalmente recomiendo:
- Patterns, Principles, And Practices Of Domain-driven Design de Scott Millett y Nick Tune. En cuanto a conceptos y contenido está perfecto, pero es muy denso y está muy mal redactado a veces.
- Domain Driven Design Quickly de Eric Evans con otros autores. Este libro lo recomiendo fuertemente antes que el otro, porque lo explica más sencillo y sin ser tan complicado. Incluso como libro auxiliar ayuda mucho.
Conclusión
Todos estos conceptos y términos está bueno al menos haberlos escuchado alguna vez. A veces en el mundo de la programación es difícil ver los horizontes con tantos conceptos. Estos no son ni cerca el límite, hay muchos más que me guardo para otras entradas, pero al menos en mi caso si son parte importante del camino que me va marcando.
