Quería dedicarme al desarrollo durante mucho tiempo, pero, como suele suceder, realmente no creía en mí mismo. Creía que mi tren se había ido hace mucho y que los cerebros ya no eran los que dominaban esta difícil profesión. Afortunadamente, me persuadieron, además, me dieron la oportunidad de demostrar mi valía y tomaron una pasantía en el departamento de desarrollo. Sucedió de manera tan casual y sencilla que al principio no podía creerlo. Todo el tiempo me pareció que ahora todos finalmente entenderían que yo era un ignorante y se despedirían de su pluma. Pero esto no sucedió, continuaron apoyándome y hice todo lo posible para no decepcionar a nadie.
Soy becaria en nuestro departamento de backend, que se ocupa del seguimiento de productos, y al mismo tiempo trabajo en mi propio departamento de integración técnica (desde hace 6 meses). El idioma principal del equipo es Python . Le enseñé por mi cuenta para conseguir una pasantía. Básicamente, por supuesto, en manuales y videos en Internet.
Tenía una base pequeña: escribí varios proyectos de capacitación en C, pero en general no puedo decir que fuera al menos un programador con cierta experiencia cuando me aceptaron para una pasantía. Desde lo alto de esta humilde experiencia, me gustaría contarles un par de cosas que no sabía o casi no sabía al principio.
Trabajo en equipo con Git
Cuando una persona llega a su primera pasantía, se imagina qué es Git (de lo contrario, es poco probable que lo contraten), pero tiene poca idea de cómo trabajan con él en equipo. Todos creamos una cuenta en GitHub al mismo tiempo y comprometimos felizmente la primera línea de código a la rama maestra, sintiéndonos como verdaderos profesionales. Entonces: este no es el mejor enfoque para proyectos grandes.
En el desarrollo de equipos, el trabajo con Git se lleva a cabo de acuerdo con el git-flow aprobado . Por ejemplo, tenemos dos ramas: desarrollar y dominar. Nadie, excepto el líder del equipo, puede cargar código en la rama maestra, porque el equipo debe asegurarse de que haya un código que funcione y que no destruya la producción cuando se implemente. La responsabilidad de esto recaerá sobre los hombros del líder del equipo, y nadie quiere enojar al líder del equipo.
Para prevenir tales situaciones, hay una revisión en equipo. Cada desarrollador trabaja en una tarea en su propia rama y al final del trabajo coloca una solicitud de fusión en la rama de desarrollo. Y el líder del equipo ya coloca la solicitud de fusión en la rama maestra y es responsable de la calidad del código para su propietario. Así, se garantiza la pureza del código que acaba en la producción, y se minimizan los riesgos de verter algo que arruine el trabajo del proyecto.
Conclusión: si desea prepararse mejor para el trabajo en equipo, lea sobre git-flow y comience a agregar nuevas confirmaciones a su proyecto favorito a través de sucursales.
La arquitectura de código es importante
Cuando llegué a la pasantía, esperaba que me dijeran qué hacer, me dieran algunas pequeñas pruebas de función o unidad, y trabajaría en ellas bajo la supervisión del equipo.
Sin embargo, todo resultó diferente. No, nadie me indicó que hiciera algo ultracomplicado, pero me asignaron un mini-proyecto (hito) de seguimiento (Python + Prometheus + Grafana ), que tuve que hacer durante mi pasantía. Además, yo mismo tuve que pensar en la arquitectura, descomponer el proyecto en tareas y pasarlo por las etapas Kanban. Fue emocionante, pero muy correcto. Este enfoque nos permitió a mi curador y a mí comprender claramente cuáles son mis problemas y comenzar a solucionarlos.
Para ser honesto, mi primera decisión no tuvo éxito. Y el segundo también. Hice tareas que eran demasiado grandes, las devolví a la lista de trabajos pendientes varias veces, construí una arquitectura fallida y no pude tener en cuenta los matices.
Sin embargo, por el momento, la mayor parte del proyecto ya se ha implementado y cada vez soy más consciente de cómo mi código afecta al resto del proyecto. Es emocionante. Leí varios artículos sobre arquitectura limpia, estudié clases abstractas, aprendí a planificar una interfaz primero y solo luego comencé a implementar. No puedo decir que lo haya resuelto todo, pero definitivamente entendí la frase "Cualquier problema se puede resolver introduciendo un nivel adicional de abstracción, excepto el problema de un número excesivo de niveles de abstracción". Y también aprendí a evaluar correctamente mi fuerza (pero esto no es exacto).
: . , , . , Netflix, . , .
En nuestra empresa, todos los servicios se lanzan en contenedores. En consecuencia, cada desarrollador debe comprender cómo funciona el mismo Docker , cómo escribir un Dockerfile simple o aumentar sus servicios a través de Docker Compose .
Para una persona que escribe solo para sí misma y en su computadora, es difícil entender por qué se necesita la contenedorización. Sin embargo, en proyectos grandes, es necesario asegurarse de que el código funcione independientemente del entorno. Un poco más tarde, cuando descubra los conceptos básicos, será obvio lo conveniente que es. No necesita instalar dependencias en su entorno, no es necesario un lanzamiento de proyecto largo y difícil. Puede ejecutar pruebas o separar pro y dev simplemente escribiendo un par de configuraciones una vez.
El mismo consejo puede incluir trabajar con el IDE. Antes de comenzar la pasantía, escribí todos mis programas exclusivamente en Emacs, pero cuando comencé a trabajar, decidí cambiarme a una herramienta más avanzada, y al final no me arrepiento. En algunos lugares todavía prefiero usar la consola (por ejemplo, es más conveniente omitir todos los contenedores
docker stop $(docker ps -qa)), pero por lo demás estoy agradecido con la GUI de Git y los consejos en PyCharm.
Conclusión: lea sobre Docker. Intente ejecutar su código en un contenedor. Pruebe un IDE para su idioma y vea lo que puede hacer por usted.
La documentación y las pruebas son tan importantes como el código
Mi curador dijo una vez que las pruebas son la documentación del segundo desarrollador. Y esto es muy cierto, porque si falta la documentación real, siempre puedes ir a las pruebas y ver qué comportamiento se espera.
Antes de mi pasantía, usé UnitTest y PyTest, pero solo como parte de mi capacitación. Y Mock , por ejemplo, no usó para nada, porque mis proyectos no eran tan complejos que fuera necesario reemplazar datos (bueno, o mis pruebas eran tan malas).
Recomendaría a todos los desarrolladores novatos que escriban pruebas para toda la lógica que ocurre en el proyecto. Incluso si cree que el comportamiento es obvio, es mejor ir a lo seguro. Después de todo, cuando otra persona escribe una función que usa su código, existe la posibilidad de que no entre en detalles y es su prueba fallida la que salvará el proyecto de problemas.
Y para minimizar aún más los riesgos, escriba documentación clara. En Admitad, un método o función sin documentación generará preguntas para su revisión. Dos semanas después, nadie quiere perder el tiempo tratando de descifrar el código de otra persona nuevamente. Es solo una cuestión de respeto por los colegas.
Además, diré que también anotamos tipos en Python en detalle, pero si escribe en un lenguaje fuertemente tipado, este comentario no es para usted. (Usar un linter como Flake8 ayuda mucho en este sentido ).
Conclusión: preste atención a las pruebas y la documentación. Comience con un archivo Léame de Git normal: describa cómo ejecutar el proyecto, qué hace y qué espera. Intente escribir pruebas para métodos y funciones clave, o mejor aún, haga que Docker Compose ejecute todas las pruebas.
¿Qué experiencia tuviste?
Para los desarrolladores establecidos, mi consejo puede parecer trivial y obvio. Te comprendo perfectamente, pero al principio me faltaba mucho conocimiento del sistema. Estoy seguro de que muchos de los que dominaron la profesión por sí solos enfrentaron este problema.
Por lo tanto, los animo a compartir las experiencias y observaciones que han aprendido después de los primeros meses (o años) en la industria. ¿Qué consejo te darías al inicio de tu carrera? ¿Qué habilidades recomendarías desarrollar? Tanto yo como otras personas autodidactas podemos necesitar tus consejos, así que no dudes en dejar comentarios.