Tan pronto como el desarrollador ingresa a la empresa y recibe la tarea, a menudo resulta que necesita unirse al proyecto común de algún equipo y no escribir su código desde cero.
Cualquier código tiene su propia lógica, basada en ciertos principios, en él hay patrones y tecnologías características del equipo al que se ha unido el programador. Pero, ¿cómo comenzar a comprender rápidamente el proyecto de otra persona, a pesar del hecho de que apenas es pequeño y, a menudo, no hay documentación, o es insuficiente e inexacto?
Le recordamos: para todos los lectores de "Habr": un descuento de 10.000 rublos al registrarse en cualquier curso de Skillbox con el código de promoción "Habr".
Skillbox recomienda: El curso en línea de Frontend Developer Profession .
De hecho, la mejor documentación es el código en sí y aquellos que crearon este código (siempre que todavía estén en algún lugar cercano y no hayan abandonado la compañía). ¿Cómo puedo reducir el tiempo al mínimo y llegar rápidamente al trabajo, haciendo mi contribución?
En repetidas ocasiones me he encontrado con esta situación en los últimos 15 años de mi trabajo como programador, y aquí están mis pensamientos sobre este tema.
Metas y objetivos del proyecto.
Lo primero que debe hacer es dedicar un poco de tiempo a comprender qué tareas realiza la aplicación para la que está creando el código. Este es un desafío global; habiéndolo resuelto, harás frente a todo lo demás.
No puede trabajar en un proyecto sin darse cuenta de por qué es necesario. La comprensión común le permitirá comprender rápidamente las pequeñas cosas. Además, su propio trabajo se llevará a cabo de manera más armoniosa con el resto del equipo. Ladrillo a ladrillo: así es como se construye la casa.
Arquitectura
Después de haber aprendido la tarea principal, dedíquese al análisis de la ejecución del código y su lógica.
La arquitectura de algunos proyectos es bastante complicada, especialmente si las tecnologías básicas de estos proyectos no le son muy familiares. Al principio, trate de encontrar documentación técnica (o pregunte a sus colegas al respecto) para ver la lógica básica.
Teniendo en cuenta la estructura del proyecto, podrá comenzar a trabajar más rápido y no interferir con el funcionamiento de todas las otras partes en las que participan otros miembros del equipo.
Puede haber fragmentos en el proyecto que violen la lógica general, pero, conociendo la idea y la arquitectura, puede solucionar el problema, reorganizar o cambiar los "ladrillos" para que encajen perfectamente en el edificio general.
Patrones
Hay una gran cantidad de patrones que los desarrolladores usan cuando escriben código. Estos son patrones estructurales, "conductuales", tecnológicos y otros. Todos ellos ayudan a tipificar formas de resolver problemas comunes al diseñar programas.
Comprender qué patrones se utilizan en su proyecto actual ayudará, a nivel de clase, a comprender cómo se deben incorporar las funciones en el código. Como resultado, podrá crear un código coherente que corresponderá a la lógica y los patrones generales, lo que en última instancia conducirá a un número mucho menor de comentarios sobre el código, una mejor comprensión del mismo y la eliminación rápida de errores si es necesario.
Después de haber trabajado un poco en el proyecto, podrá comprender de un vistazo qué secciones del código se ajustan a la estructura general y qué requiere una refactorización.
Pautas
La mayoría de los equipos tienen ciertas reglas, o más bien, un conjunto de reglas según las cuales todos actúan. No se trata solo de los principios generales del trabajo, sino también del uso de clases y niveles de aplicación. Si los representantes del equipo se guían por las mismas pautas, entonces el código desarrollado es más fácil de entender y leer.
Lo más probable es que el equipo al que te unas también tenga pautas que debes aprender. En primer lugar, se relacionan con el lenguaje de programación, que es el principal durante el desarrollo.
Puede preguntar dónde obtener toda la información sobre el proyecto, su arquitectura, plantillas y pautas. Existen varios métodos para obtener lo necesario, excepto los que ya se han expresado anteriormente:
- Busque cualquier información, incluso la que pueda considerarse irrelevante; Construya su propia base de conocimiento de términos, abreviaturas y conceptos comunes que utiliza su equipo.
- Una vez que esta base de datos esté lista, puede discutir todos los temas de interés para usted con el gerente del proyecto, ya que ya habla el mismo idioma.
- Además, vale la pena hablar con los arquitectos de aplicaciones y los líderes de equipo sobre la arquitectura general de su proyecto. Luego, intente obtener más información sobre esta arquitectura y las técnicas de optimización de código asociadas. Si ve algo que, en su opinión, viola la lógica general de la aplicación, asegúrese de discutirlo con el líder del equipo.
- Averigüe con sus compañeros de equipo qué patrones y reglas se utilizan en el curso del trabajo sobre el código, tanto durante la escritura como en el mantenimiento futuro. Una vez que conozca los puntos principales, compare lo que funciona mejor y actúe en consecuencia en el futuro.
- Intente limpiar una sección de código de problemas potenciales y reales; esto lo ayudará a obtener una comprensión más profunda del proyecto y su código. ¿Qué usa su equipo para limpiar el código?
En términos generales, la refactorización es la mejor oportunidad para involucrar a su equipo en una discusión sobre qué pautas deben revisarse y cuáles deben usarse en el futuro.
Comparta sus propios desarrollos con el equipo, participe activamente en reuniones de trabajo, discuta problemas actuales, la arquitectura de la aplicación y sus elementos, plantillas y otros puntos importantes. Las reuniones de trabajo pueden ser un canal confiable para obtener información adicional; Vale la pena hablar sobre sus observaciones / logros, sobre lo que puede ser útil para todos.
Como resultado, no solo puede comenzar a trabajar rápidamente, sino también unirse al equipo, convirtiéndose en su participante insustituible en poco tiempo.
Por supuesto, conocerá a personas con quienes es difícil comunicarse; Habrá problemas con el código. Pero esto sucede casi siempre: hay equipos donde todo es perfecto, pero son pocos.
Skillbox recomienda: