Cómo vivir y desarrollar proyectos con historia. Qué le da al desarrollador la experiencia de trabajar con una gran base de código, y por qué no es necesario esforzarse por reescribir todo desde cero, incluso si realmente lo desea.
Contenido
- ¿Para quién es este texto?
- Qué puedes aprender de un proyecto de historia
- Qué preguntas hacer en una entrevista
- Consejos para quienes acaban de empezar a trabajar con un proyecto heredado
- Brevemente
Soy Pavel Novikov, estoy involucrado en el desarrollo de las aplicaciones móviles "MyOffice Documents" y "MyOffice Mail". Se trata de una aplicación de colaboración con documentos y un cliente de correo electrónico, que se empezó a crear en 2013, por lo que se pueden denominar proyectos con un código base grande, donde hay un lugar incluido el legado.
La experiencia descrita aquí se aplica no solo al trabajo en aplicaciones móviles y se adapta al desarrollo de aplicaciones en general.
Descargo de responsabilidad para los más pequeños
En este artículo he recopilado reflexiones sobre mi trabajo basadas en la experiencia que tengo hasta la fecha. Cualquier artículo de este tipo es siempre muy subjetivo. Estoy seguro de que hay personas con experiencias que contradicen mis observaciones. Me complacería discutir estas discrepancias en los comentarios.
¿Para quién es este texto?
El texto está dirigido tanto a aquellos que se consideran a sí mismos en el nivel Junior como a los que pertenecen a la categoría Media / Senior.
Hay mucho que aprender al trabajar con proyectos de larga duración en cualquier nivel de desarrollo. Para estar en la misma onda en la comprensión de los niveles, lea las publicaciones de Vastrika: Login y K - Team . Me gusta su categorización de los niveles de desarrollador y me ceñiré a ella en el futuro.
En el siguiente bloque analizaremos brevemente cuál es el uso de cada uno de los niveles en proyectos largos.
Júnior
La tarea de los desarrolladores junior es maximizar el desarrollo de habilidades técnicas. Se utiliza todo: lenguajes, frameworks, bibliotecas, enfoques de desarrollo, etc. En cualquier proyecto con un equipo sólido, puede aprender a resolver diferentes problemas.
Pero en proyectos maduros, en primer lugar, tendrá la oportunidad de profundizar en cualquier área y, en segundo lugar, podrá estudiar ejemplos de decisiones exitosas y no exitosas. Aprender de los errores de otras personas es caro. Especialmente si hay colegas más experimentados cerca que puedan explicarle en detalle el significado de estos errores y cómo pueden evitarse.
Medio
La tarea del desarrollador intermedio es aumentar su autonomía. Debe convertirse en un miembro del equipo al que se le pueda confiar casi cualquier tarea del proyecto. Esto significa que cuantas más tareas tenga un proyecto, más áreas de crecimiento potencial tendrá.
Mayor
El trabajo del desarrollador sénior es comprender completamente que no se le paga por el código, sino por resolver problemas. A veces (aún más a menudo hasta ahora) a través de la escritura de código, a veces a través de la gestión de otros desarrolladores, a veces a través de la comunicación con no desarrolladores. Los proyectos maduros son solo un almacén de tareas que pueden y deben resolverse.
A continuación, entraré en más detalles sobre algunas de las cosas que puede aprender de los proyectos existentes.
¿Y aquí Legacy?
Primero necesitas comprender la terminología. El concepto de "legado" ha adquirido una connotación negativa hace mucho tiempo, pero ¿para qué es exactamente malo el código heredado?
Michael Feathers, fundador de R7K Research & Conveyance, sostiene que el código heredado es un código no cubierto por las pruebas. La ventaja de este enfoque es que, a primera vista, pretende ser objetivo. Pero en realidad, puede haber dos escenarios:
- Hay pruebas, pero están mal redactadas: confusas, frágiles, no claramente estructuradas.
- No hay evaluaciones comparativas, pero el código está muy bien diseñado. Esto hace posible cambiarlo de forma relativamente segura y, en cuyo caso, le permitirá escribir rápidamente pruebas para él en el futuro.
Otra mirada a lo que es el legado del desarrollador Dro Helper (Dror Helper): ya no está diseñado, continuamente parcheado y pirateado ...
El desarrollador web Nicolas Carlo cree que el código heredado es un código incómodo para trabajar.
De todo esto, podemos concluir que el legado es más bien una característica subjetiva del código. El código en sí puede funcionar o no, pero se convertirá en heredado cuando aparezca un desarrollador que no pueda modificarlo de manera efectiva.
Otra característica relativamente objetiva para evaluar Legacy es la respuesta a la pregunta "¿existen dependencias no admitidas en el proyecto?" El código solo puede ser compilado por algunas versiones obsoletas específicas del compilador. O los propios autores parchearon alguna biblioteca externa, y ahora se ha convertido en parte del proyecto principal. En este caso, de hecho, el proyecto se vuelve específico y se necesitan esfuerzos adicionales para apoyarlo.
En general, si el proyecto tiene más de seis meses, lo más probable es que haya un legado en él.
¿Qué puedes aprender de un proyecto de historia?
Entonces, tomó una decisión y consiguió un trabajo en una empresa donde el código ya estaba escrito antes que usted y estaban sucediendo muchas otras cosas. Agregaré que no necesita ir a un nuevo lugar para actualizar sus perfiles. Lo más probable es que el legado esté en todos los proyectos, solo necesita saber cómo evaluarlo. Y lo que estoy hablando ciertamente se puede aplicar a las cosas en las que está trabajando ahora.
¿En qué áreas el bombeo será igualmente útil para usted y el proyecto? Aquí debe comprender que la situación en la que se desarrolla donde duele el proyecto es un entorno ideal para el crecimiento mutuo. Porque si te desarrollas trabajando en algunas cosas de izquierda, entonces esto puede ser una ventaja para ti personalmente, pero será difícil explicar por qué la empresa debería ayudarte con esto.
Analizar el proyecto
Lo primero que puedes aprender de un proyecto patrimonial es analizarlo. Digamos que llegó a un proyecto donde hay lagunas con la documentación, o no hay ninguna. En este caso, solo tendrás el código fuente del proyecto, por lo que es fundamental poder analizarlo y comprender rápidamente su estructura y esencia. Esto es importante porque cuanto antes aprenda a navegar, antes comenzará a beneficiar el proyecto.
Lo más importante que puedo recomendar para una comprensión más profunda del análisis del proyecto es leer el libro "Trabajo efectivo con código heredado" de Michael Feathers. Ella es vieja y famosa. Describe una gran cantidad de prácticas para trabajar con código heredado.
Otro consejo es visitar el sitio web Understand Legacy Code .... Este es un blog dedicado a un tema: trabajar con el legado. Es importante que puedas suscribirte a la newsletter allí. Estoy seguro de que muchos desarrolladores de Android conocen los correos de Android Weekly y Kotlin Weekly. El boletín de ULC también es muy útil. No es intrusivo, con artículos prácticos sobre refactorización y codificación.
Refactor
Los proyectos heredados son un gran lugar para practicar sus habilidades de refactorización. Llegas a un proyecto que probablemente tiene problemas y necesitas no solo cambiarlo, sino también mejorarlo, expandirlo y ver nuevas características. Qué tan bien y eficientemente pueda refactorizar (rápidamente y con pocas regresiones) determinará qué tan útil y buen desarrollador es.
En un proyecto maduro con una cultura de ingeniería saludable, la refactorización debe ser una parte continua del desarrollo.
Debe gustarle el producto en el que está trabajando. Perfecto si puedes usarlo tú mismo. En este caso, tendrás una motivación interna para trabajar en la mejora de su calidad durante mucho tiempo.
Diseñar y construir arquitectura
Este punto se deriva del anterior: inevitablemente, necesitará aumentar el diseño y la arquitectura del software. Con la cultura de desarrollo adecuada, no tendrá que tomar decisiones arquitectónicas importantes en plazos ajustados. Tendrás tiempo para diseñar la arquitectura y será tu responsabilidad hacerlo bien. ¿Qué recomiendo siempre aquí? Leer libros.
Encuentro que los libros son tan importantes como otras fuentes de información. Cuanta más experiencia obtenga con los libros, más rápido comprenderá cómo resolver problemas comunes. Siempre hay soluciones típicas para problemas típicos / típicos que se pueden encontrar en los libros. Trabajar con cualquier tipo de legado también implica resolver problemas típicos.
(Robert C Martin). « », « »
(Martin Fowler). «. »
UML — .
PlantUML (PUML) — , UML-. git, , .
Cuando trabaje con un producto que no comprende completamente, de alguna manera necesitará aprender a evaluar el trabajo a realizar. Y siempre tendrás algo que no conoces, algunos escollos.
La capacidad de dividir una tarea grande y compleja en un conjunto de piezas pequeñas interconectadas es una habilidad muy valiosa. Una forma de desarrollarlo es trabajar de forma retrospectiva y continua en los errores de descomposición y estimación. En el proceso de análisis, puede crear una lista de verificación a partir de errores frecuentes. En el futuro, podrá ayudarlo a evitar estos errores nuevamente.
Automatizar y poder aplicar CI / CD
Debe comprender qué le sucede a su código desde el momento en que lo escribe hasta el momento en que llega al dispositivo del usuario. Y tendrá la capacidad de automatizar y CI / CD para personalizar, mantener y mejorar. En las empresas donde no hay un equipo de infraestructura dedicado, estas operaciones pueden y deben (estoy convencido de esto) ser decididas por miembros del equipo de desarrollo central. Las herramientas modernas (Cloud CI, Docker) no son increíblemente complejas, pero simplifican enormemente la vida de un equipo. Podrás hacer mucho con ella si dominas estas habilidades.
Comunicar
Cuanta más responsabilidad tenga, más personas tendrá que comunicarse. El desarrollo de software ha dejado de ser una suerte para las personas: casi todos los grandes proyectos los realizan equipos. Nuevamente, cuanto más efectivamente aprenda a interactuar con quienes lo rodean, más beneficios podrá aportar.
Tendrá que comunicarse con personas más inteligentes y con más experiencia que usted. En los proyectos grandes, siempre hay "veteranos" de los que se puede aprender mucho. Además, conocerás personas que son más tontas que tú. La buena noticia es que es muy probable que esté equivocado acerca de su capacidad mental; es muy útil poder corregir tales errores de percepción.
Creo que el desarrollo de las habilidades comunicativas se puede reducir a desarrollar un sentido de empatía. Cuanto mejor aprenda a comprender las motivaciones y los objetivos de las personas que lo rodean, más rápido podrá resultarles útil. Por ejemplo, al explicarle a una empresa los beneficios de refactorizar y trabajar en la deuda técnica, debe utilizar términos comerciales, no términos de programador. Una idea aparentemente obvia, pero he visto repetidamente cómo algunas personas inteligentes se comunican con otras personas inteligentes y no pueden entenderse entre sí.
Qué preguntas hacer en una entrevista
Aquí empezaré con las preguntas que haría antes de empezar a trabajar en un proyecto del que sé poco.
Cómo funciona el flujo de trabajo y por qué exactamente
Por lo general, ahora trabajan en sistemas Scrum o Kanban. Pero al mismo tiempo, a menudo los adaptan por sí mismos: "tomaron lo mejor, desecharon lo innecesario". La pregunta es: ¿qué arrojaron exactamente y qué dejaron? Porque la guía Scrum, sobre la base de la cual se construye el proceso de desarrollo, tiene algunas prácticas bastante interesantes y útiles.
Tienen sentido cuando se aplican, en primer lugar, conscientemente, y en segundo lugar, todos se aplican. Porque conforman un sistema que se autocontrola y te permite mejorar iterativamente no solo el proyecto, sino también tus propios procesos.
Por ejemplo, si el equipo está trabajando en Scrum, preguntaría qué se discutió en la última retrospectiva. ¿Qué tan activo es el equipo en esta reunión? ¿Se están abordando las cuestiones planteadas?
Otra pregunta interesante para mí sobre los procesos internos: ¿cómo se realiza la revisión de código en el equipo? ¿Existe alguna regla interna para realizar una revisión que pueda ayudar a reducir su tiempo? ¿Existe una base de conocimiento común en la que se ingresan los resultados de los holivares, para no adecuarlos siempre?
Cómo funciona la planificación, quién está involucrado y qué tan activo es el equipo
Haría esta pregunta para ver qué tan fuerte es la cultura de ingeniería dentro del equipo. Existe una opción cuando solo el líder del equipo está planificando y el equipo está de su lado.
Otra opción es cuando todo el equipo participa en la planificación. Y cuando llega una tarea, la encarga de pintarla alguien que tenga la suficiente experiencia en esta materia. Y luego todos discuten y toman una decisión. Esto hace que el equipo sea más autoorganizado y que el flujo de trabajo sea más agradable.
¿Cuántas personas en el equipo tienen la imagen completa?
Aquí son posibles dos extremos. El primer extremo es cuando se llega a un equipo que ha estado trabajando en un producto durante los últimos 2 a 4 años. Si al mismo tiempo el equipo no cambió mucho, sino que solo se expandió, entonces esto es muy bueno, porque siempre tendrás personas a las que puedes acudir en busca de ayuda. Podrán sugerir algo, explicar el motivo, contarle la historia del proyecto. Es muy importante conocer el contexto y por qué todo está organizado de esta manera y no de otra manera.
El segundo extremo es cuando se llega a un equipo que no tiene ninguno de los que estaban en la salida. Por ejemplo, el proyecto se congeló, se descongeló y quedó una gran base de código. No se puede reescribir desde cero. En consecuencia, es necesario restaurar el desarrollo. Es decir, obtienes un proyecto en el que tendrás que desenterrar todo nuevamente.
Con base en esta información, podrá tomar una decisión más informada sobre si desea ir allí o no, y tal vez sobreestimar algunos de sus requisitos para las propuestas que necesita responder.
¿Cómo se mantiene la cartera de deuda técnica?
Hay problemas en cualquier proyecto y es importante comprender cómo trabaja el equipo con ellos. Escribí muy bien sobre trabajar con deuda técnica.alexanderlebedeven el artículo “¡Lannisters siempre pagan sus deudas! (y técnico también) " .
Si el equipo conoce los problemas, pero no sabe cómo trabajar con ellos de manera sistemática, entonces es una mala señal. Pero puede ver esto como una oportunidad para convertirse en la persona que ayudará a resolver estos problemas.
Consejos para quienes acaban de empezar a trabajar con un proyecto heredado
Resista la tentación de apresurarse a reescribir todo desde cero
Una situación común: comienzas a trabajar en una aplicación existente y ves que todo está hecho "mal". Y con este "no es así" es necesario seguir trabajando. En este caso, es un deseo bastante natural: tomarlo y reescribirlo todo de nuevo. Ésta es una reacción normal.
Creo que se basa en la falta de voluntad para responder por los errores de otras personas. Después de todo, si después de sus modificaciones aparecen nuevos defectos, tendrá que resolverlo. Entonces es mejor reescribirlo por completo, y todo estará bien.
Si nota que está teniendo esos pensamientos, hágase algunas preguntas:
¿Definitivamente hay suficientes problemas en el código o simplemente no lo entiende todavía?
¿Está seguro de que comprende exactamente todos los puntos de integración del código reescrito?
¿Conoce el proyecto lo suficientemente bien como para predecir correctamente el próximo horario de trabajo?
Si bien estoy convencido de que la intención de apresurarse inmediatamente a reescribir todo desde cero es una mala idea. Las mejoras deben ser iterativas y manejables.
Una vez fui testigo cuando el equipo dijo que "todo es una mierda, vamos a reescribirlo", lo reescribieron durante seis meses y no lo reescribieron. Como resultado, se desarrolló una situación bastante interesante cuando el proyecto tuvo que ser liderado nuevamente desde cero, para reclutar un nuevo equipo, porque el antiguo equipo se cayó. Intente extinguir este impulso completamente natural de rehacer todo desde cero.
Predecir cambios en el proyecto
Tienes que aprender a ser un pequeño oráculo. Al trabajar con un proyecto durante mucho tiempo, aprenderá a comprender su componente de producto, aprenderá a comprender el negocio, cómo gana este proyecto, cómo se vive. Esto le brindará la oportunidad de evaluar la perspectiva a largo plazo de las decisiones que tome.
Esta es una habilidad muy útil, porque es una mala situación cuando el propietario del producto se acerca a ti y te pide que hagas algo simple desde su punto de vista. Por ejemplo, agregue un nuevo criterio para ordenar la lista. Y por su parte, esto significará que debe reescribir todo este componente. Esto no habría sucedido si hubiera pensado de antemano que diferentes formas de ordenar esa lista es una función perfectamente lógica. Aunque no se le pidió que lo hiciera en primer lugar.
Simplemente no vayas a los extremos y trata de tomar siempre las decisiones más universales. Este es un camino directo hacia la ampliación del tiempo y los problemas con más apoyo para tales soluciones. El objetivo de esta habilidad es precisamente encontrar el equilibrio.
Hacer investigación
Cuando trabajas en un proyecto largo, es importante cuánto confía la empresa en el equipo. Antes de desarrollar cualquier característica importante, definitivamente llevamos a cabo una investigación completa del área temática. Puede sonar como la capitanía de un capitán, pero conozco casos en los que la gente se precipitó de inmediato a la vorágine con la cabeza y las tareas aparentemente simples se convirtieron en largas refactorizaciones que podrían haberse evitado simplemente investigando antes del desarrollo.
Tómese el tiempo para documentar
Documente lo que negocia, documente procesos, documente arquitectura. Aquí trato de adherirme al enfoque de que si no lo escribió, entonces no estuvo de acuerdo. Porque en proyectos que tardan más de medio año, se vuelve fundamental aprender a no perder información.
Cuando tomas una decisión arquitectónica, te parece obvia. ¿Por qué explicarlo de alguna manera? Seis meses o un año después, surgen problemas en esta solución arquitectónica. Y piensas: “¿Por qué lo acepté? ¿Cuál fue el contexto? " Aprender a redactar estas decisiones arquitectónicas es una gran inversión y le beneficiará en el futuro.
Una de las formas de mantener dichos registros es Architecture Decision Records... Su idea principal es que para cada solución arquitectónica no trivial, debe crear un archivo con varios elementos: título, fecha, contexto, descripción de la solución, consecuencias previstas. Este archivo se almacena con el código y no cambia después de su creación. Su principal valor es que cuando llegue el momento de cambiar esta solución arquitectónica, será mucho más fácil entender la motivación que la llevó.
Brevemente
- Un proyecto con historia es un buen lugar para que un desarrollador crezca si se interesa no solo en escribir código, sino también en tareas que ayudarán a desarrollarse no solo como programador.
- En proyectos con antecedentes, el problema no lo crea el código, sino las personas, es decir, esa gestión cuando te exigen algo muy rápido y constantemente, como en el desarrollo de juegos, por ejemplo.
- . , , , .
GDG.