Completó un curso, vio una serie de videos en YouTube o leyó una serie de artículos sobre el desarrollo de iOS y ahora se siente listo para escribir su primer proyecto favorito.

En primer lugar, ¡bien hecho! Eso es genial. ¡Eres genial! 💪

En segundo lugar, un proyecto favorito es un impulso fantástico para tus habilidades. Cuando empiezas a hacer algo por tu cuenta, sin seguir instrucciones, tienes que dedicar mucho tiempo y esfuerzo, buscar mucho en Google, leer un montón de información nueva e intentar filtrarla y adaptarla con precisión a tu caso. En definitiva, ya es una tarea real que te potenciará cinco veces.

Sin embargo, la mayoría de los principiantes ignoran las cosas clave (no por iniciativa propia, sino sin comprender su importancia). Durante los últimos seis meses, he estado activamente tutoría y ayudar a los recién llegados con sus preguntas y problemas, incluidos sus proyectos favoritos.

He identificado los 3 puntos principales que usted, como principiante, debe incorporar a su lista de elementos imprescindibles, dominar, comprender y utilizar.

Nivel de acceso

Al principio, casi nadie presta atención al modificador private . Mientras tanto, todos pueden explicar instantáneamente SOLID si los despiertas en medio de la noche. Después de leer varios artículos inteligentes, la gente intenta crear un montón de clases de acuerdo con la idea de S (responsabilidad única).

Y luego, con la conciencia tranquila, cambian la propiedad de class A de class B y viceversa.

 class A { var someAValue: Int? } class B { let a = A() func foo() { a.someAValue = 1 } }

En general, si aún no está claro, este es el plan: escribir siempre private en todas partes y, cuando el compilador se queje, piense: ¿está bien acceder a esta propiedad o función desde el exterior? Y si es así, elimine el private .

Cuando pienses, guíate con comparaciones del mundo real. Por ejemplo, si su clase es una tienda, entonces la propiedad goods obviamente debería ser accesible para el cliente externo. Pero está claro que el moneyInCashRegister sólo puede ser modificado por un empleado interno de la tienda.

Después de todo, un cliente no debería tener acceso a la caja registradora, ni siquiera con put , y mucho menos fetch .

Se podría argumentar: "Entiendo perfectamente qué propiedad se puede tocar y cuál no, incluso sin un modificador private ". Sin embargo, escribir modificadores de nivel de acceso es parte del diseño. Estoy seguro de que no crearías un plano para una casa con una puerta en el tercer piso que dé al exterior.

Y luego, recuerda no abrirlo. Después de todo, es probable que otros también utilicen su código.

Por cierto, existe una situación similar con var y let . Nuevamente, use siempre let a menos que esté inmediatamente seguro de que cambiará el valor.

Simplicidad de la arquitectura

He notado una tendencia en la que los principiantes intentan planificar todo con antelación. Si bien esto es encomiable, los desarrolladores suelen cometer errores debido a su falta de experiencia. Preparan previamente a gerentes demasiado complejos (generalmente copiados de Desbordamiento de pila ) con muchos métodos complicados, que finalmente nunca utilizan. Como resultado, crece la cantidad y complejidad del código.

En lugar de lo que parecía un servicio conveniente y listo para usar, nuestro programador terminó solo con problemas y malentendidos. Lo mismo ocurre con la arquitectura.

Permítanme recorrer brevemente la historia de la programación para transmitirles mi punto. A finales de la década de 1960, a medida que la popularidad de la programación comenzó a crecer, el tamaño de los programas también aumentó. Como puede comprender, un tamaño de programa mayor significa más líneas de código, lo que genera una mayor complejidad y dificultad para comprender el programa.

Para abordar este problema, surgió la programación estructurada: funciones y procedimientos que permitían dividir los programas en partes más pequeñas y manejables. El código se volvió modular, reutilizable y más comprensible.

La llegada de la estructuración condujo a un mayor crecimiento de los programas hasta que nuevamente alcanzaron sus límites de tamaño y complejidad. Por lo tanto, a finales de los años 1970 y principios de los 1980, se formó el enfoque de programación orientada a objetos. Esta solución permitió la creación de sistemas flexibles y escalables, abordando tareas cada vez más complejas.

En la década siguiente, fuimos testigos del auge de los juegos de ordenador. La reacción a las acciones del usuario (clics, pulsaciones) resultó crítica, lo que llevó al surgimiento de la programación basada en eventos.

Y para organizar el código en aplicaciones web y de escritorio, cuando era necesario reorganizar los mismos datos desde diferentes perspectivas, surgió el patrón MVC (es decir, separar el modelo de su representación visual).

Has captado la idea principal: surge un problema, -> surge una solución. Problema -> Solución.

Entonces, ¿por qué los programadores principiantes empiezan ahora a aplicar soluciones (arquitecturas) en un momento en que los problemas aún no han surgido? Los tutoriales sugieren inmediatamente elegir al menos un MVP. Las tareas de prueba para una o dos pantallas siempre especifican NO usar MVC.

Durante las entrevistas, a una persona que ha escrito un par de proyectos favoritos con las mismas una o dos pantallas se le pregunta sobre los problemas de VIPER. ¿Cómo podría saber acerca de los problemas si aún no los ha encontrado?

La gente suele hablar de la conveniencia de la capacidad de prueba en el contexto de la arquitectura, pero nunca han escrito pruebas. Y si lo hicieron, se basó únicamente en algún tutorial, centrándose únicamente en pruebas unitarias sin vincularlas a una aplicación real.

Pueden explicar el esquema MVP en términos simples, pero a menudo se confunden cuando se trata de protocolos con nombres similares, como ViewInput y ViewOutput . En el fondo ya ven todo esto como una sobrecarga 🙄🤯

Conclusión: no te crees problemas. No te avergüences de MVC. Cuando su controlador crezca demasiado o encuentre inconvenientes, comprenderá que es hora de buscar nuevos enfoques.

Simplicidad de la interfaz de usuario

El desarrollo front-end es un paraíso de dopamina para principiantes. Escribes el código e inmediatamente ves el resultado en la pantalla: recibes tu recompensa 🍭. Es innegablemente motivador. Sin embargo, hay una otra cara de esta moneda. Los principiantes a menudo se esfuerzan por crear una interfaz de usuario demasiado compleja de inmediato.

Además, las funciones complejas tienden a seguir una interfaz de usuario compleja. Aunque SwiftUI simplifica la tarea hoy en día, todavía se puede pasar mucho tiempo agregando detalles sin lograr un progreso real.

Aprendí desarrollo de iOS en un curso donde formamos equipos y trabajamos en un solo proyecto. En mi equipo, un chico sugirió comenzar el desarrollo de nuestra aplicación eligiendo fuentes y colores para el modo oscuro.

En general, dedicó todo el curso a ello y vale la pena señalar que las fuentes y los colores resultaron fabulosos. Sin embargo, el tipo escribió aproximadamente cero líneas de código real durante todo ese tiempo.

Sin duda, la belleza y funcionalidad de tu aplicación son cruciales. Al final tendrás que dedicar tiempo a este aspecto. Es mejor empezar con algo más sencillo. Desarrolle un MVP (producto mínimo viable), céntrese en las características más críticas y lance desde allí.

El regla 80-20 se aplica aquí: cree la base de la aplicación y luego agregue los extras. El enfoque opuesto conducirá a lidiar con matices complejos y lidiar constantemente con una funcionalidad principal que sigue fallando.

Para los recién llegados al desarrollo móvil, existe el riesgo de adoptar soluciones complejas prematuramente. Si bien las recompensas visuales del desarrollo front-end pueden ser atractivas, comenzar con un simple MVP suele ser más inteligente.

Las tendencias históricas sugieren que las soluciones deberían evolucionar en respuesta a desafíos genuinos.

Comprender los principios fundamentales y abordar los problemas del mundo real a medida que surgen es fundamental para un desarrollo eficaz.

También publicado aquí