Para los experimentados, nuestro consejo puede parecer obvio. Pero para los principiantes, recomendamos encarecidamente leer. Tómese el tiempo para traducir estas ideas en sus proyectos para que no gaste aún más en refactorizaciones sin fin más adelante.
Se pueden expresar ideas similares en casi cualquier área de desarrollo, pero hablaremos de ellas usando el ejemplo de proyectos en React.
Al comenzar los proyectos desde cero, piensa en la mejor manera de organizar todo para que luego no sea insoportablemente doloroso debido a la repetición interminable. En proyectos personales de mascotas, puede cercar lo que quiera y luego vivir con eso usted mismo. Pero en el trabajo en equipo, debe actuar de tal manera que sea más fácil para los colegas comprender la esencia y profundizar en los detalles. Aquellos. No reinvente los enfoques de desarrollo; es mejor ceñirse a prácticas bien establecidas y reconocidas por la industria.
Piense en escribir
Independientemente de las libertades en los lenguajes de desarrollo, la escritura estática es muy útil en grandes proyectos a largo plazo. Si por alguna razón es imposible usar escritura estática en tal proyecto, entonces incluso JSDoc ayudará significativamente a mantener la calidad del código.
Pero no le vamos a recomendar encarecidamente que utilice siempre la escritura. No en vano se hizo una reserva arriba sobre grandes proyectos, ya que mecanografiar es, ante todo, ayudar al equipo. Pero organizarlo y mantenerlo (el mismo tipo de cambio de acuerdo con los cambios en el backend) requiere ciertos recursos. En un pequeño proyecto a corto plazo donde trabajan 1-2 personas, esta inversión no tiene sentido. Pero son necesarios cuando el equipo es grande y se expandirá.
Si el uso de la mecanografía está justificado, le recomendamos que cree tipos desde el principio, de lo contrario tendrá que dedicar mucho más tiempo a este trabajo. Incluso si no tiene ninguna API lista y no conoce el modelo de datos, al menos cree stubs para que el tipo genérico no aparezca en ninguna parte.
A medida que se desarrolla el proyecto, se debe respetar la tipificación, incluso si todos los plazos se han agotado durante mucho tiempo. Entonces te agradecerás este perfeccionismo.
Divide el código en bloques, resalta la lógica
El código no debe agruparse. Vale la pena considerar la jerarquía en la estructura del proyecto: dividir el código en módulos y bloques, dividir los componentes en inteligentes y estúpidos. Es más conveniente mantener y desarrollar tal estructura que buscar partículas de esta lógica en un gran montón, especialmente si estas partículas están interconectadas. Quizás este consejo se aplique no solo a la interfaz.
La utilidad de este principio fue claramente visible en el proyecto con formularios grandes, sobre el que escribimos recientemente ( https://habr.com/ru/company/maxilect/blog/511322/ ). En ese proyecto, las comprobaciones de bloques y la visibilidad de esos bloques se vincularon inicialmente. Pero cuando reunimos toda la comunicación de los campos en un solo lugar, se hizo mucho más fácil rastrear los cambios en la lógica. Y lo más importante, pudimos reutilizar el código en un nuevo proyecto similar.
No existe un estándar único para la estructura de un proyecto; aquí debe confiar en sus conocimientos. Hay dos enfoques que pueden funcionar para muchos proyectos: Tipo de archivo primero y Característica primero.
Para encontrar un punto de partida para encontrar una estructura que sea conveniente para usted, le recomendamos que consulte la documentación. Las mejores prácticas generalmente se describen allí. Por ejemplo, React y Redux en su documentación ofrecen estándares para organizar la lógica y la estructura de archivos de un proyecto. Con algo de experiencia, puede experimentar y desviarse de los estándares si esto le permite evitar algunas restricciones para un proyecto en particular, pero en la mayoría de los casos esto no es necesario. Y, por supuesto, no se olvide de principios tan “básicos” como SOLID. Buen artículo sobre cómo aplicar estos principios en React:https://habr.com/ru/company/ruvds/blog/428079/ . Buen artículo sobre arquitectura limpia: https://habr.com/ru/post/499078/ .
Sobre la organización del código base en React y problemas relacionados, hay una buena colección de materiales, aunque no se ha actualizado durante mucho tiempo: https://github.com/markerikson/react-redux-links/blob/master/project-structure.md .
Formular una convención de codificación
El arquitecto que inicialmente planifica el proyecto en función del camino por el que se desarrollará la aplicación tiene en mente ciertas plantillas. Vale la pena expresarlos explícitamente en forma de pasaporte de proyecto, completándolo con las reglas para escribir código, por ejemplo, qué se puede y qué no se puede incluir en un módulo separado (en general, esta es una pregunta bastante filosófica). Dicho "pasaporte" ayudará a los desarrolladores a determinar de antemano cómo escribir, para que luego no lo reescriban. Esto puede reducir el tiempo de revisión y ayudar a estandarizar los enfoques de codificación, lo cual es especialmente útil cuando trabajadores remotos o equipos distribuidos están trabajando en un proyecto.
Cíñete al paradigma elegido
Si al principio decidió adherirse a algún enfoque, por ejemplo, el diseño web atómico, no debe abandonarlo tan pronto como los plazos comiencen a agotarse. El apoyo iniciado y abandonado a un paradigma es a veces casi peor que su ausencia total. Si "da rienda suelta al caos" un poco, será extremadamente difícil restablecer el orden; tendrá que dedicar tiempo a regresar al paradigma. Y no podrá "saltar" rápidamente a otro, ya que ya se ha formado un desorden informe en el proyecto.
El rechazo del paradigma por motivos de tiempo u otros factores es como cambiar de caballo en un cruce. Es doloroso y no se recomienda. Pero si no hay salida, debe cubrir la mayor parte de su aplicación con pruebas. Y aquí pasamos al siguiente consejo ...
Recuerda las pruebas
Las pruebas en un proyecto no solo tienen que serlo. Tienen que trabajar. Y es necesario incluirlos en el proyecto en la primera etapa, tan pronto como comience el desarrollo. De lo contrario, en un momento determinado, puede cambiar algo en la aplicación y luego salirse de los plazos de lanzamiento, restaurando el rendimiento de diferentes partes del proyecto, que están cubiertas solo por pruebas manuales.
Deje que las pruebas sean pequeñas al principio y no verifique nada en absoluto. Pero es mucho mejor desarrollarlos a medida que crece la funcionalidad, que dedicar una semana después a saldar esta “deuda técnica”. En términos de la cantidad de tiempo invertido, el primer enfoque es más efectivo. Por cierto, muchos son muy conscientes de esto, pero aún dejan las pruebas para más adelante.
También me gustaría mencionar la integración y las pruebas de extremo a extremo.
Las pruebas de integración deben ejecutarse cada vez que corrija errores o agregue nuevas funciones para asegurarse de que los ajustes no hayan afectado nada. En nuestros proyectos, intentamos lanzarlos automáticamente cuando subimos los resultados de nuestro trabajo (lo implementamos a través de un gancho). Las pruebas no funcionaron; no debe cargar cambios en el proyecto. Primero necesitas arreglar todo.
Pero las pruebas de integración solo se refieren a la interfaz. Las pruebas de un extremo a otro son más lentas y prueban la interacción de la aplicación con todos los elementos dependientes. Estas pruebas simulan las acciones del usuario. Aquí no nos burlamos de nada, sino que realmente esperamos las respuestas del backend y verificamos las interacciones dentro de todo el ecosistema del proyecto usando Cypress (también podemos recomendar Puppeteer como análogo).
Piense antes de actualizar, pero no se rinda
En el mundo del frontend, todo cambia muy rápidamente: las versiones del marco se reemplazan entre sí, aparecen bibliotecas más exitosas. Vale la pena mantenerlos actualizados, pero no fanáticos.
Al igual que escribir, de lo que hablamos anteriormente, cualquier actualización cuesta recursos (es decir, indirectamente, dinero). Pero hay algunas cosas que hacen que sea imposible optar por no recibir actualizaciones por completo.
Primero, el soporte incluso para las bibliotecas más exitosas a veces termina. En esta situación, tendrá que optar por análogos más prometedores.
En segundo lugar, trabajar con la antigua pila de tecnología rara vez inspira a los desarrolladores. Si se da cuenta de que el equipo no se puede mantener en una columna vertebral polvorienta, o si nota que una pila obsoleta está afectando críticamente la afluencia de nuevos desarrolladores, tendrá que actualizar.
Los refrescos deben tomarse como parte del orden natural de las cosas. Pero antes de cambiar una biblioteca o actualizar un marco, siempre debe investigar un poco.
¿Es la nueva versión adecuada para ti? ¿Cómo organizar la transición en general? Y, por supuesto, debes planificar todo con anticipación.
Las actualizaciones son extremadamente difíciles si no hay pruebas en el proyecto. Incluso una pequeña biblioteca de fechas puede cubrir muchas partes diferentes de un proyecto y actualizarla conduce a una prueba de regresión completa. Con el crecimiento del proyecto, no será posible hacerlo de manera eficiente, teniendo solo pruebas manuales en el arsenal.
¿Estás bien ahora?
La medida de la eficiencia con la que desarrolla su proyecto puede ser la relación entre el tiempo dedicado a desarrollar nuevas funciones y el tiempo dedicado a los errores. Dependiendo del enfoque, este indicador puede ser más o menos, por lo que no nos comprometemos a establecer niveles “objetivo”. Usted mismo puede comparar la situación antes y después de cualquier transformación.
Además de las características no numéricas, como la "satisfacción del desarrollador con el proyecto", existe un indicador como el momento en que una nueva persona se une al proyecto. Esta es una característica de lo bien que se describe claramente un proyecto a través de la documentación, las pruebas y la convención de codificación.
Y recuerde, es mejor dejar un código mejor que el que tenía antes. No genere deuda técnica, de lo contrario dificultará el desarrollo del proyecto posteriormente.
¿Quizás tienes tus propios consejos? ¡Déjalo en los comentarios!
PD: Publicamos nuestros artículos en varios sitios de Runet. Suscríbete a nuestras páginas en el canal VK , FB , Instagram o Telegram para conocer todas nuestras publicaciones y otras novedades de Maxilect.
PPS La imagen del título de la competencia Playhouse recientemente celebrada.