Alguna vez te has encontrado a ti mismo revisando el código de alguna aplicación en la que hayas estado trabajando durante varios días, tratando de corregir algún bug escurridizo sin ningún éxito? Te has sentido decepcionado o frustrado contigo mismo por la cantidad de tiempo invertido en agregar una nueva funcionalidad o feature a tu código?
Si este escenario que describo anteriormente es algo común en tu día a día, quizás sea tiempo de que revises el diseño de tu app, su arquitectura. Pero… hey! No te abrumas, todavía estás a tiempo de rescatar a tu aplicación de ser desechada. Todavía hay algo que puedes hacer para mejorarla. Veamos juntos qué puedes hacer.
Como Ingeniero y especialmente en el desarrollo de aplicaciones Android, la calidad de software ha sido siempre una de mis grandes prioridades. Patrones de arquitectura, buenas prácticas y testing (entre otros temas) son muy relevantes a la hora de generar aplicaciones robustas. Hay muchísima documentación, videos, pappers y posts hablando sobre el tema que pueden encontrar fácilmente buscando por la web, algunos realmente muy buenos.
Sin embargo, a pesar de la cantidad de información que podemos encontrar sobre el tema en la web, lo que es difícil de encontrar son buenos ejemplos… si entienden de lo que les hablo.
¿Entonces, de qué trata todo esto?
Esta es una serie de post sobre los principios SOLID, no lo he mencionado aún?
“Los principios SOLID nos dicen como ordenar nuestras funciones y estructuras de datos en clases y cómo esas clases deberían estar interconectadas”
Robert Martin, aka Uncle Bob
Como mencioné anteriormente, siempre estoy en la búsqueda de la alta calidad de código, creando las mejores soluciones posibles. Es digamos, una manera de validar que estas prácticas realmente funcionan.
He visto diferentes tipos de aplicaciones durante toda mi carrera, algunas de ellas demasiado frágiles (discutiremos este concepto luego), rídidas, intolerantes a los cambios y les puedo asegurar que el buen diseño y la buena calidad de código son al final de todo la mejor opción frente a la excusa de «no hay tiempo de hacerlo bien».
Este es el primero de una serie de post que escribí y que quiero compartir con ustedes. Algunos de estos conceptos sobre SOLID ya los conozcan o incluso los apliquen en su día a día sin siquiera darse cuenta. En esta oportunidad, los vamos a nombrar e identificar utilizando como base el desarrollo de aplicaciones en Android, discutiendo cómo estos patrones y prácticas pueden mejorar no sólo el código de sus apps sino también a ustedes, como ingenieros.
¿Cuál es el significado de SOLID?
SOLID es básicamente el conjunto de mejores prácticas y principios que han sido presentados y practicados alrededor de los años que nos permiten entregar aplicaciones de calidad, unidas bajo este acrónimo.
Básicamente, SOLID representa los siguiente principios:
Single Responsibility Principle (SRP)
Este principio nos dice que no importa si estás lidiando con un simple bloque de código, una clase o incluso un módulo entero, éste debe tener una y sólo una razón para cambiar.
Open-Close Principle (OCP)
Este principio está más relacionado al diseño. Básicamente dice que dado un sistema, a fin de poder cambiar su comportamiento deberíamos poder hacer agregando código nuevo en vez de modificar el código existente. Debe estar abierto para ser extendido y cerrado para ser modificado.
Liskov Substitution Principle (LSP)
Quizás este es el principio más complicado de comprender. Sin embargo, los discutiremos en profundidad en próximos posts. Para resumir, el principio dice que si estamos construyendo un sistema con partes intercambiables, estas partes deben suscribir a un contrato que les permita ser efectivamente sustituidas por otras partes.
Interface Segregation Principle (ISP)
Creo, sin temor a equivocarme, que este es uno de los principios más violados por el framework de Android y por los desarrolladores también. Este principio previene a los desarrolladores de tener que depender de cosas que realmente no necesitan.
Dependency Inversion Principle (DIP)
Este principio es, a mi entender, de los más valiosos a la hora de desacoplar tu aplicación Android (y cualquier otra) de cualquier dependencia o posible cambio que puedas llegar a tomar estratégicamente. Este principio tendrá su propio post aunque para dar una primera idea, este principio nos dice que el código que implementa políticas de alto nivel no debe depender de código que implemente políticas de bajo nivel.
Ha sido mucha información, tómate un respiro hondo… toma otro… vuelve a leer los principios… Ok, ¿comienzan a tener sentido verdad? Ya estamos listos para trabajar sobre cada uno de ellos. Sin embargo, no será en este post, deberemos esperar al próximo donde comenzaremos por nuestra S, el principio de Single Responsibility.
Nota: Esta serie de post fue originalmente publicada en mi perfil de medium.com en Inglés.
Sigamos conectados 😄
Happy Coding! ✍️
Comentarios
Pingback: Haz de tus aplicaciones una roca sólida | Liskov Substitution | Jorge Nogueiras's Developer Blog
Pingback: Haz de tus aplicaciones una roca sólida | Interfaces | Developer Blog by Jorge Nogueiras