Mejores prácticas y herramientas para desarrollar aplicaciones iOS

Al desarrollar aplicaciones móviles, tuve que crear proyectos desde cero más de una vez. Al mismo tiempo, mi equipo y yo siempre dedicamos mucho tiempo a la configuración básica del proyecto, como integrar herramientas de terceros, configurar la estructura del proyecto, escribir clases base, integrar bibliotecas externas, etc.

Decidí que el tiempo necesario para lanzar el proyecto puede reducirse y que la parte principal del proceso puede automatizarse. Al mismo tiempo, recopilé las mejores prácticas y herramientas que usamos, y preparé una plantilla de proyecto que usamos al comenzar nuevos proyectos. Dicha plantilla debería ahorrarle tiempo al desarrollador para configurar un nuevo proyecto, así como proporcionar una estructura de proyecto común, a la que cada miembro del equipo se acostumbrará, para que ya no tenga que pensar y estudiar la estructura de un nuevo proyecto para él. Ahora es siempre lo mismo.

Cada herramienta o enfoque agregado a la plantilla merece un artículo separado, pero me gustaría tratar de resumir cada párrafo y dar una breve explicación de por qué los incluí en este artículo.

Cacao

No creo que Cocoapods requiera una presentación. Esta es una biblioteca para administrar dependencias externas para proyectos de iOS. Ha existido durante mucho tiempo y es confiable y probado en campo en miles (si no millones) de proyectos. También hay administradores de dependencias alternativos, por ejemplo: Cartago , pero decidí continuar con Cocoapods, porque tiene la más amplia gama de proyectos de código abierto admitidos. Usar Cocoapods es muy simple y viene con un índice de búsqueda que facilita la búsqueda de paquetes que pueden ser útiles en cualquier momento.

Se proporciona un proyecto de plantilla con un Podfile simple que contiene Swiftlint y R.swift. La plantilla también incluye un archivo de gemas para administrar la versión de Cocoapods utilizada para la administración de dependencias. Los desarrolladores a menudo ignoran esta solución, pero evita los problemas que ocurren cuando los desarrolladores de su equipo instalan dependencias utilizando diferentes versiones de Cocoapods. Gemfile usa a la fuerza la misma versión de Cocoapods para todo el equipo.

Swiftlint

Swiftlint es una herramienta muy útil para hacer cumplir ciertas reglas y estilos de escritura para cada desarrollador del mismo equipo. Este sistema podría considerarse como un sistema de verificación de código automatizado que advierte al desarrollador sobre momentos peligrosos, como, por ejemplo, lanzamientos de fuerza, intentos de fuerza, etc., pero además de lo anterior, este sistema aplica un estilo general de escritura de código, monitoreo para que todos los desarrolladores sigan las mismas reglas asociadas con el "estilo de código", por ejemplo: sangrías o intervalos. Este enfoque tiene enormes ventajas, no solo ahorra tiempo en la verificación del código, sino que también hace que los archivos del proyecto sean reconocibles, lo que aumenta su legibilidad y, como resultado, su comprensión por parte de todos los miembros del equipo de desarrollo. Este enlace proporciona una lista de todas las reglas. En la plantilla Swiftlint, se instala utilizando Cocoapods y se incluye en el paso "Fases de compilación", por lo que mostrará una advertencia al desarrollador cada vez que se compila el proyecto.

R.swift

R.swift es una herramienta para obtener recursos fuertemente tipados y rellenados automáticamente, como imágenes, segmentos de fuente y localizaciones. Realiza todas las acciones anteriores escaneando el proyecto y creando las clases necesarias para obtener recursos. La mayor ventaja de esta biblioteca es que al usar recursos, hace que el código del programa:

• Totalmente escrito : menos conversiones y suposiciones sobre qué método se devolverá
• Tiempo de compilación verificado : ya no hay líneas no válidas que impiden que la aplicación se ejecute durante la ejecución del código
• Autocompletado : no es necesario adivinar el nombre image / nib / storyboard nuevamente

Considere el siguiente código utilizando la API de cadena oficial:

let icon = UIImage(named: “custom-icon”) 

Si cometió un error en el nombre de la imagen, obtendrá cero. Si algún miembro de su equipo cambia el nombre del recurso de imagen, este código devolverá cero o su ejecución se detendrá si fuerza la expansión de la imagen. Cuando se usa R.swift, se ve así:

 let icon = R.image.customIcon() 

Ahora puede estar seguro de que el ícono realmente existe (el compilador le avisará si no es así, gracias a las comprobaciones de tiempo de compilación), y estará seguro de que no hará un error tipográfico en el nombre del ícono, porque usará autocompletar.

R.swift se instala utilizando Cocoapods y se integra en la plantilla en la Fase de compilación y generará clases de shell Swift para cada compilación. Esto significa que si agrega un archivo / imagen / localización / fuente / color / lápiz, etc., todo esto estará disponible a través de R.swift después de compilar el proyecto.

Archivo de AppDelegate separado para pruebas

Muy a menudo se olvidan de la buena práctica de usar una clase separada TestAppDelegate al ejecutar pruebas. ¿Por qué es una buena idea? Normalmente, la clase AppDelegate hace mucho trabajo cuando se inicia la aplicación. Puede tener una lógica de configuración de ventana, configurar la pantalla básica de la interfaz de usuario de la aplicación, ejecutar la lógica de registro para recibir notificaciones, tener un código de configuración de conexión de base de datos e incluso a veces hacer llamadas a la API del servidor. Las pruebas unitarias no deberían tener efectos secundarios. ¿Realmente no desea hacer llamadas API aleatorias y personalizar toda la estructura de la interfaz de usuario de su aplicación solo para ejecutar pruebas unitarias?

TestAppDelegate también es una opción adecuada para obtener el código que desea ejecutar solo una vez durante la ejecución del conjunto de pruebas. Puede contener código que genera objetos simulados, resguardos de solicitud de red, etc.

La plantilla contiene el archivo main.swift, que es el punto de entrada principal para la aplicación. Hay métodos en este archivo que prueban el entorno de la aplicación, y si es un entorno de prueba, llaman TestAppDelegate.

Indicadores de perfil de rendimiento del compilador

Swift es un gran lenguaje, más fácil de usar y más seguro que Objective-C (IMO). Pero cuando se introdujo por primera vez, tuvo un gran defecto: el tiempo de compilación. En los días en que estaba trabajando en un proyecto en Swift, que tenía alrededor de 40 mil líneas de código Swift (un proyecto de tamaño mediano). El código era muy pesado, con configuraciones e inferencia de tipos, y compilar un ensamblaje limpio tomó casi 5 minutos. Si realiza incluso pequeños cambios, el proyecto se vuelve a compilar y se tarda unos 2 minutos en ver los cambios. Esta fue una de las peores experiencias que he experimentado, y debido a esto, casi dejé de usar Swift.

Entonces, la única solución era intentar perfilar el tiempo de compilación del proyecto y cambiar su código para que el compilador funcione más rápido. Para ayudar a resolver estos problemas, Apple presenta algunos indicadores de compilación no oficiales que advierten al desarrollador que lleva demasiado tiempo compilar el cuerpo del método o determinar el tipo de expresión. Agregué estas banderas al proyecto de plantilla para advertir sobre el largo tiempo de compilación de su aplicación.

Hoy en día, el tiempo de compilación ha disminuido significativamente, y los desarrolladores rara vez tienen que optimizar su código solo para reducir el tiempo de compilación. Pero aún así, es mejor saber todo de antemano que tratar de resolver este problema cuando el proyecto se vuelve demasiado grande.

Dev / Staging / Configuraciones de producción

Otro buen enfoque (o, podría decirse, una necesidad) es tener una configuración separada y variables de entorno para entornos de desarrollo, pruebas finales y publicación de la aplicación. Actualmente, casi todas las aplicaciones deberían funcionar con un servidor y, por lo general, estos servidores se implementan en varios entornos. Los desarrolladores utilizan el entorno de desarrollo para la implementación diaria para probar su código. El entorno de prueba final se utiliza para crear versiones estables o para pruebas por parte de probadores y clientes.

Una forma de admitir múltiples entornos en un proyecto de iOS es agregar configuraciones a nivel de proyecto.


Configuraciones de nivel de proyecto

Una vez definidas las configuraciones, puede crear un archivo Configuration.plist que contenga variables para cada entorno.


Configuration.plist

Al iniciar un proyecto, es posible indicar qué configuración se debe utilizar. Puede hacer esto en un diagrama de ensamblaje.



Luego debe agregar otra propiedad al archivo de proyecto Info.plist. El valor de esta propiedad se sustituirá dinámicamente en tiempo de ejecución en nombre de la configuración actual.


Todo esto está preconfigurado en la plantilla.

Solo queda escribir una clase que pueda extraer estas variables en tiempo de ejecución, dependiendo de la configuración seleccionada en el esquema de ensamblaje. La plantilla contiene la clase ConfigurationManager , que puede recuperar variables para el entorno actual. También puede verificar la implementación de esta clase en Github para ver cómo funciona.

Léame

Cada proyecto debe contener un archivo Léame, que al menos contiene instrucciones para instalar dependencias e iniciar el proyecto. También debe contener descripciones de la arquitectura y los módulos del proyecto. Desafortunadamente, a los desarrolladores no les gusta escribir documentación (el archivo Léame es parte de este trabajo), y vi un proyecto que se ha desarrollado durante meses, e incluso tenía un archivo Léame. Para eliminar la carga de escribir un archivo Léame, la plantilla contiene un archivo Léame estándar que cubre la instalación y la estructura del proyecto. Al configurar un nuevo proyecto utilizando plantillas, incluye automáticamente el archivo Léame.

Gitignore

Actualmente, la mayoría de los proyectos utilizan GIT como sistema de control de versiones. Al usar GIT, los desarrolladores no quieren ignorar algunos archivos o carpetas en el proyecto, como la carpeta de compilación o la carpeta de datos derivados. Para evitar que el desarrollador tenga que encontrar un archivo gitignore adecuado para su proyecto de iOS, la plantilla contiene el gitignore estándar proporcionado por los miembros de Github.

Clases base para manejar enlaces externos y notificaciones

Hoy en día, casi todas las aplicaciones deben manejar enlaces externos y notificaciones. Para hacer esto, el desarrollador debe escribir un código estándar en la clase AppDelegate. Esta plantilla contiene una descripción de cómo hacer esto, también contiene clases base que facilitan el trabajo con enlaces externos y notificaciones.

Conclusión

Para resumir, la plantilla descrita contiene los mejores enfoques e integra herramientas útiles de terceros. Todo esto debería ahorrarle a su equipo el tiempo de desarrollo dedicado a configurar un nuevo proyecto, así como proporcionar una base común y sólida para el resto del proyecto. ¡Deje que esta plantilla le sirva a usted y a su equipo para el beneficio!