Problemas potenciales
Recomiendo encarecidamente evitar agregar bibliotecas externas a su proyecto. Sin embargo, esto no significa que el uso de bibliotecas sea malo, ¡y su archivo Gradle debe limpiarse por completo de cualquier dependencia externa! Quiero transmitir la idea de que se debe realizar un análisis muy serio antes de agregar una nueva biblioteca. Para comprender cómo analizar bibliotecas, echemos un vistazo a los posibles problemas que podría enfrentar al agregar una nueva biblioteca a su proyecto.
Tamaño de la aplicación
La mayoría de las bibliotecas no aumentan mucho el tamaño de su aplicación. ¡Pero existen tales bibliotecas, después de agregarlas, su aplicación aumentará significativamente! Por ejemplo, la biblioteca Realm puede aumentar el tamaño del APK de 4 MB a 12 MB. En promedio, la aplicación pesa entre 100 MB y 200 MB y es posible que los 8 MB adicionales no se noten. Pero tenga en cuenta que Realm no es la única biblioteca que afecta negativamente el tamaño del APK. ¿Es posible reducir el tamaño del APK usando esta dependencia? Sí, se puede dividir apk por arquitecturas de procesador. Pero esto lleva al siguiente problema (punto 2).
Mantenibilidad del código
Los proyectos crecen, se cubren con cada vez más lógica y en ocasiones se hace más difícil entenderlos. Para que después de varios años de desarrollo del proyecto, cualquier nuevo desarrollador pueda acostumbrarse fácilmente al proyecto, se necesita una arquitectura de proyecto clara. Sin embargo, algunas bibliotecas pueden anular la mantenibilidad del proyecto. Por ejemplo, el trabajo incorrecto con EventBus puede confundir mucho la lógica de su aplicación. Es importante distinguir claramente entre dónde y en qué casos usa esta biblioteca. Y también para estar seguro de que nadie se desviará nunca de estas reglas. Pero, ¿qué pasa en la práctica? Casi todos los desarrolladores que comienzan con EventBus lo usan en todas partes. Como resultado, el proyecto se vuelve completamente ilegible.
Hora de explorar la biblioteca
Al agregar una nueva biblioteca, debe aprender a interactuar con ella. Hay bibliotecas que pueden tener un impacto muy negativo en la velocidad de desarrollo en el futuro.
Por ejemplo, PagingLibrary de Google requiere mucho esfuerzo para descubrir cómo interactuar con él. A cada desarrollador nuevo le llevará de 12 a 20 horas descubrir esta biblioteca. ¡Estás perdiendo casi 3 días! En solo estos 3 días, puede anotar su paginación y ser independiente de las soluciones de terceros.
Velocidad de construcción
La velocidad de construcción de las aplicaciones modernas es pobre. Sin embargo, si quieres aumentar aún más tu tiempo de construcción, ¡usa Dagger ! No sé por qué la biblioteca todavía se usa activamente después de la llegada de Kotlin. En la mayoría de los casos, Dagger contiene los 4 problemas descritos anteriormente.
Errores, errores, errores ...
En mi experiencia, en un solo proyecto, eliminé 5 bibliotecas debido a la presencia de errores en ellas. Recuerde que casi siempre hay errores en las bibliotecas. Por ejemplo:
- AndroidPdfViewer deja pérdidas de memoria, maneja incorrectamente algunos casos con null, lo que hace que se lance una NullPointerException
- El componente de navegación de Android no funciona correctamente con animaciones de elementos compartidos en algunos casos
- Cicerone a veces bloquea la aplicación debido a
executePendingTransactions()
¿Significa esto que no vale la pena usar las bibliotecas? No, las bibliotecas pueden y deben usarse, pero es importante al menos asegurarse de que no haya errores críticos para su proyecto en la lista de problemas.
Vulnerabilidades en la biblioteca
¿Conoce la forma más fácil de piratear varias aplicaciones a la vez examinando un solo código fuente? Necesitamos encontrar un error en una biblioteca grande que utilizan muchos desarrolladores. Y a través de las vulnerabilidades de esta lib para acceder a los datos de su aplicación. Si no está desarrollando una aplicación que requiera una mayor atención a la seguridad del usuario, puede hacer la vista gorda en este punto. De lo contrario, busque un problema que aborde posibles vulnerabilidades.
Soporte de biblioteca
Si la biblioteca no se ha actualizado durante un año, pregunte si vale la pena usarla. El hecho es que hay errores en las bibliotecas de forma regular. Si estos errores no se corrigen, ¿vale la pena usar esta biblioteca? Es muy posible que en un futuro próximo te encuentres con un error de biblioteca y tengas que buscar formas alternativas de implementar la función. Hay algunas bibliotecas que deben adaptarse a las capacidades de la API de Android actual. Por ejemplo, si ha aparecido un nuevo elemento en Android, debe agregarle soporte. Estas bibliotecas incluyen Anko , que ya no es compatible. Ahora no tiene sentido usar esta biblioteca en proyectos grandes.
La biblioteca está presente en todas las capas del proyecto.
Las bibliotecas como RxJava o PagingLibrary obligan al desarrollador a usar su API en cada capa de la aplicación. Si está seguro de que la biblioteca siempre estará en el proyecto, entonces no hay problema. Pero si por alguna razón tiene que recortar la biblioteca, ¡hará un esfuerzo enorme! Tendrás que reescribir la mitad del proyecto.
Limitaciones de la biblioteca
Cada lib proporciona una API que está limitada tanto por la disponibilidad de métodos públicos como por la implementación interna. Asegúrese de que las capacidades de la biblioteca sean completamente suficientes para usted. Por ejemplo, la popular biblioteca de componentes de navegación de Android ata las manos del desarrollador con mucha fuerza. No proporciona métodos de mostrar, ocultar, agregar (que tiene FragmentTransaction). Además, la biblioteca complica el trabajo con BottomNavigationView cuando es necesario almacenar el historial de pestañas.
Enorme archivo Gradle con dependencias
Cuando llego a un nuevo proyecto, lo primero que hago es mirar las dependencias en el archivo Gradle. Deja claro lo que puede hacer la aplicación y cómo se resuelven determinadas tareas. Pero me sorprendió cuando vi que OkHttp, Retrofit y Volley (fork) se utilizan para trabajar con la red. Y eso es solo trabajo en red. El archivo Gradle en sí consiste en una gran cantidad de bibliotecas, cuyo soporte ha terminado hace mucho tiempo. Cuando un desarrollador está solo, puede mantener todo el proyecto en su cabeza, pero cuando llegan nuevos desarrolladores, se vuelve extremadamente difícil entender tal proyecto.
Lista de verificación de preguntas antes de implementar la biblioteca
- ¿Qué problema tiene esta biblioteca? ¿Son fundamentales para mi proyecto?
- ¿Qué tan probada está esta biblioteca / tecnología por la comunidad de desarrolladores? ¿Cuántas estrellas tiene ella en GitHub?
- ¿Con qué frecuencia responde un desarrollador a un problema?
- ¿Con qué frecuencia actualiza el desarrollador la biblioteca?
- ¿Cuánto tiempo dedicarán los nuevos desarrolladores a aprender la tecnología utilizada?
- ¿Cómo afectará la biblioteca al tamaño de la aplicación?
- ¿Cómo afectará la biblioteca a la velocidad de la aplicación?
- ¿Cómo afectará la biblioteca a la velocidad de construcción? ¿Le ayuda a ahorrar tiempo de desarrollo?
- ¿La biblioteca tiene vulnerabilidades?
- ¿Estará la biblioteca presente en cada capa del proyecto? ¿Qué tan crítico es esto?
- Cómo la biblioteca limita las opciones del desarrollador (casi siempre limita). ¿Es bueno o malo?
- ¿Podré escribir una solución yo mismo que se perfeccionará para mi proyecto en un plazo de tiempo razonable?
Es muy interesante saber qué más puede buscar al elegir una biblioteca. ¡Esperamos sus comentarios, sugerencias y preguntas!