He trabajado como desarrollador de iOS durante más de seis años. Me pasó a trabajar en varias compañías y equipos diferentes. Trabajé tanto en outsourcing como en personal, incluso tuve la oportunidad de participar en el inicio. Y ahora, después de varios años de desarrollo comercial, así como un par de años de programación en la universidad, comencé a destacar algunos principios o reglas para un enfoque cualitativo para el desarrollo de aplicaciones. Al principio fue un consejo para mi amigo. Al darle consejos, pensé que me faltaban esos consejos cuando recién comenzaba mi camino de desarrollo. Qué puedo decir, algunos momentos me di cuenta por mí mismo hace relativamente poco, y algunos ya están en un nuevo lugar de trabajo. Y entonces surgió la idea de hacer una lista de consejos que me gustaría compartir conmigo hace cinco o seis años. Estoy seguro de que dentro de otros cinco años tendré algo que decirme hoy. Pero probablemente dejaremos esto para el futuro.
Tu código es malo
Y lo primero que me gustaría decirme como antes es: "¡Tu código es malo!". En la gente común, "govnokod". Y mis colegas extranjeros en el taller de desarrollo tienen "código mono".
No, esto no es lo que pensabas. No quiero enfatizar que solía ser un mal programador, y ahora mi código es perfecto. Quiero reformular este mensaje y transmitir tres puntos clave en el sentido de este consejo.
"¡Tu código fue y será malo!"El primer momento: no existe un código perfecto, nadie establece la arquitectura ideal y no existe dicho código en el que no haya errores. Creo que muchos se sorprendieron pensando que no podían descubrir la nueva biblioteca o la nueva tecnología. O algunos de nosotros hemos llegado al extremo al tratar de escribir la característica perfectamente, siguiendo todos los principios de OOP, SOLID. Lo que a su vez llevó mucho tiempo y, a veces, condujo a un callejón sin salida. A veces, en un intento de escribir el código perfecto, nacían monstruos que llevaban una lista completa de patrones que el desarrollador conoce, o tal vez incluso más.
Con mi frase, me gustaría transmitir la idea de que, en primer lugar, no debe preocuparse, estar nervioso por la calidad de su código. Es imposible predecir todo. Y es mejor simplemente relajarse, escribir más fácilmente y, como saben, sufrir y preocuparse en vano. Con experiencia, las decisiones vendrán por sí mismas. A veces es necesario "nagovodnodit", se encontrarán con problemas que este código de mierda causará y comprenderá de una vez por todas que es mejor no hacerlo.
El segundo momento, que mencioné anteriormente, es que es casi imposible predecir todo. Sí, con la experiencia viene la comprensión de lo que está haciendo y puede predecir la ruta de desarrollo del proyecto. Pero viene con experiencia. Y si la experiencia no es suficiente, entonces no debe intentar que el código sea universal. Hay casos frecuentes en los que su función, que pensó durante mucho tiempo y con tanto cuidado al principio, y luego escribió, simplemente se descarta de la aplicación. Además, hay casos en que las aplicaciones cambian solo porque, según la opinión del cliente, todo parecía diferente. Y después de largas horas de minuciosa transferencia de la interfaz del diseño al código, aparecen de repente 100,500 cambios. Esto es solo el comienzo, porque después de la primera rehacer, vendrán más y más ediciones nuevas. Y en el caso de que el desarrollador no tenga suficiente experiencia, este proceso puede tomar no solo mucho tiempo, sino también no traer las sensaciones más agradables que se desaniman por pensamientos desagradables en algún lugar de los rincones secretos de la mente, convirtiendo el proceso de desarrollo de una lección divertida en un dolor infernal. Por lo tanto, cuida tus nervios y no conviene al ideal. A veces puedes hablar un poco.
Tercer punto: este es nuevamente un momento puramente psicológico, es decir, las críticas de otros desarrolladores. Como todos saben, todos los desarrolladores nacionales consideran cualquier otro código: código de mierda. Incluso si se le muestra su propio código, que no reconoce, es probable que lo llame una mierda. A menudo, tales críticas van acompañadas de la satisfacción moral del propio crítico. Como señalaron los desarrolladores experimentados, son las personas las que con mayor frecuencia llaman al código de alguien más govnodkod, precisamente aquellos que alguna vez codificaron astutamente. Y cuanto más fuerte grita alguien "govnokod", más de sus "pasteles" dejó en su camino.
Además, cualquier virgen que se recuerde joven debe admitir necesariamente que ha sido un novocode de la fama.
Por lo tanto, le aconsejo que use la expresión "Su código fue y será una mierda", como un escudo de las críticas no siempre constructivas. También quiero señalar que su código siempre será una mierda porque el desarrollo no se detiene. Cada año, la calidad de su código solo mejora. Entonces el código actual eventualmente se convertirá en govnokod.
Divide y vencerás
No quiero que parezca que solo aconsejo a govnokod, por lo tanto, comenzaré a dar consejos sobre cómo evitar ese código incorrecto. Y me gustaría comenzar con el principio que me he reservado. No, esto no es herencia o polimorfismo, y no es uno de los principios de SOLID. Yo llamo a este principio Divide y vencerás.
Sí, existe la descomposición.
Descomposición: la división del todo en partes. Además, la descomposición es un método científico que utiliza la estructura del problema y le permite reemplazar la solución de un gran problema con una serie de tareas más pequeñas, aunque interconectadas, pero más simples.
Como dice Wikipedia. Pero esto es solo una parte de lo que pongo en el sentido de mi principio. Definitivamente sí, necesita dividir el proyecto y las tareas en partes más pequeñas. Pero me refiero al enfoque conceptual de la separación de grupos lógicos en el proyecto.
Y lo primero que me refiero a este principio es la separación de la interfaz de usuario Y la lógica empresarial de la aplicación. Parece que ahora soy capitán directo de evidencia. Pero! En la práctica, estos límites a menudo son borrosos y resulta que ViewController o Activity contiene una pieza de lógica empresarial.
Creo que un ejemplo de la pantalla "Iniciar sesión" será simple y comprensible. Aquí el desarrollador comienza a implementar la arquitectura MVC. Parece que hay una Vista separada, como también agrega Controlador con modelo, como debería. Pero en algún momento piensan: "¿Por qué necesito agregar varias clases para la pantalla con un solo botón?" y en este momento recomiendo abandonar tales pensamientos viciosos y adherirse estrictamente al principio de "Divide y vencerás" para separar la interfaz de usuario y la lógica empresarial. E incluso si la arquitectura requiere la adición de una clase ViewModel, en la que habrá dos líneas de código, debe hacerlo. Porque a menudo hay casos en que una pantalla en la que originalmente había un botón, con el tiempo, se convierte en dificultades impensables. Si sigue la separación de componentes lógicos de antemano, esto facilitará enormemente la vida en el futuro.
Puede sentir especialmente la esencia de la estricta separación de la interfaz de usuario y la lógica, en los casos en que tiene que transferir pantallas de un proyecto a otro. O en una situación en la que, bajo diferentes condiciones, se utilizan diferentes algoritmos en la lógica empresarial. Por ejemplo, al dividir la pantalla de autorización en componentes, podemos reemplazar uno de los componentes en el futuro sin afectar al otro. Podemos reemplazar Ver o Modelo con nuevos métodos de autorización para los mismos datos.
No limite el principio de "dividir y conquistar" solo estas dos capas. A la separación estricta, agregaría la separación de pantallas y la lógica de navegación para aplicaciones móviles. ¿Qué quiero decir con eso?
Mi práctica me ha llevado a facilitar la codificación de una pantalla en particular sacando la lógica de navegación por separado. Una pantalla, específicamente View, para iOS es un UIViewController, y, a veces, un UIView, y para Android Activity, o Fragment, no deben participar en una función para mostrarse, así como cambiar a otras pantallas. Cada una de estas clases solo debe preocuparse por lo que sucede en una pantalla en particular, o más bien, solo para representar una pantalla específica e interactuar con una clase de lógica de negocios (Presentador, ViewModel y otros).
Estos son solo dos de los muchos ejemplos en los que debe seguir fundamentalmente la separación. Seguir este principio facilitará enormemente el trabajo adicional con el proyecto. Incluso si govnokod se incluye en cualquiera de los componentes separados.
Estilo único
Continuando con el consejo anterior, quiero pasar al siguiente, a saber, la estricta adhesión a un estilo único en el proyecto.
¿Qué quiero decir con eso?
Para empezar, la palabra clave aquí es estricta, de la palabra en absoluto. Inicialmente, seleccionamos un enfoque único para organizar un proyecto, para la gestión de archivos, para el estilo de código, etc. Esto mejorará significativamente la apariencia general del proyecto y facilitará en gran medida la navegación del proyecto, la búsqueda por código y acelerará el proceso de presentar un nuevo desarrollador al proyecto. Creo que no vale la pena recordar que después de un tiempo nosotros mismos podemos convertirnos en esta nueva persona con nuestro antiguo código.
La elección de la arquitectura y su seguimiento.
Nuevamente, siguiendo el consejo anterior, procedemos sin problemas al siguiente, la elección de la arquitectura. Y la idea principal que quiero transmitir es no hablar sobre las mejores arquitecturas o decir que debe elegir esto y no otro. No! Para empezar, no existe una arquitectura ideal que cubra completamente todos los casos posibles en el proyecto. Una vez escuché estas palabras: "si hubiera una arquitectura ideal, entonces los desarrolladores serían despedidos como innecesarios y reemplazados por scripts que generen la arquitectura ideal".
El punto principal, creo, no es la elección de la mejor arquitectura, sino una estricta adherencia a la arquitectura que ya ha sido elegida y comenzó a aplicarse. Ya sea VIPER, REDUX, MVP o MVC. Por supuesto, hay ventajas y desventajas para cada una de las arquitecturas anteriores. Con el tiempo, cada vez más enfoques nuevos para el diseño de la arquitectura del proyecto.
Diré más específicamente sobre mi idea. Si ya ha comenzado a usar VIPER, siga estrictamente sus principios. Incluso si parece que para una pantalla de un botón hay demasiados archivos para crear unidades de líneas de código, no omita estas reglas bajo ninguna circunstancia. Porque, en momentos como este, nace el govnokod, que luego, como una bola de nieve, todo crece y crece.
Le aconsejo que se familiarice con las arquitecturas más populares y elija la que más le guste o la más popular antes de comenzar un nuevo proyecto. Recomiendo encarecidamente elegir la segunda opción, es decir, comenzar con la arquitectura más popular, como Será fácil encontrar respuestas a muchas preguntas. Al elegir una arquitectura, se debe prestar especial atención a los inconvenientes de esta arquitectura y en qué casos se recomienda usarla.
Por ejemplo, si se trata de un proyecto pequeño, en el que hay uno o dos desarrolladores, no debe tomar VIPER debido al hecho de que se trata de una arquitectura bastante engorrosa, que es muy buena para proyectos grandes y equipos grandes. Para que no haya casos en que el código para crear VIPER sea muchas veces más que el código de la lógica de negocios en sí.
Personalmente, ahora prefiero la arquitectura MVVM + Router. Funciona bien en un pequeño proyecto donde soy un desarrollador único.
En pocas palabras: lo principal no es qué arquitectura ha elegido, sino cómo exactamente la sigue.
También quiero agregar, si el proyecto no se está desarrollando desde cero, primero que nada debe familiarizarse con la arquitectura actual y el estilo general del proyecto, y comenzar a seguirlo. No debes romper con gritos de que hay govnokod (volviendo al primer consejo) y comenzar a rehacer todo. Una excepción puede ser una anarquía completa en el proyecto o la falta de un estilo común.
Pausas de refactorización
En conclusión, quiero decir que hacer una pausa para refactorizar es un buen enfoque. La refactorización es una parte muy importante del desarrollo de aplicaciones de calidad. Sí, no escribimos el código perfecto de inmediato, pero dejarlo como está tampoco es bueno. A menudo sucede que la implementación original no tiene la capacidad de escalar cuando necesita introducir nuevas características. Después de todo, es casi imposible predecir todos los cambios posibles en futuras versiones del proyecto. Además, ninguna arquitectura garantiza una cobertura del 100% de todos los casos. Por lo tanto, es importante realizar cambios en el código existente para adaptarlo a las nuevas funciones.