Tareas típicas de un desarrollador Java en un proyecto

¿Cuáles son las responsabilidades típicas de un desarrollador de Java? Después de todo, necesitas entender lo que estás buscando y qué harás al final, ¿verdad? Hoy me gustaría hablaros de las diez tareas principales que realiza un desarrollador Java. Pero primero, familiaricémonos con una herramienta como Jira. O refresquemos la memoria si ya te resulta familiar. Jira es una herramienta de interacción con el usuario, aunque en algunos casos también se utiliza para la gestión de proyectos. En otras palabras, el desarrollo del proyecto se divide en pequeñas tareas que se describen en esta herramienta. Estas tareas son asignadas (asignadas) a los desarrolladores, quienes serán los responsables de su implementación. Por tareas nos referimos, por ejemplo, a añadir alguna funcionalidad. A medida que avanza el progreso, los desarrolladores y otros especialistas añaden comentarios sobre quién hizo qué y cuánto tiempo dedicaron: realizan un seguimiento del tiempo. Esto se hace para realizar un seguimiento del tiempo invertido: cuánto se gastó y en qué. Idealmente, esto se hace una vez al día: por la noche, antes de partir, realiza un seguimiento de sus 8 horas para las tareas en las que las dedicó. La funcionalidad de Jira es mucho más amplia que la descrita anteriormente, pero esto será suficiente para una comprensión inicial. Entonces, ¿cuáles son las responsabilidades de un desarrollador de Java?

1. Desarrollo de nuevas soluciones

Antes de crear e implementar algo, debes idearlo, ¿verdad? Como dije, podría ser simplemente una tarea de Jira que se te asignará y trabajarás para desarrollar una nueva solución, anotando en Jira cuánto tiempo dedicaste y en qué. Esto también podría ser una discusión en una llamada de equipo: todos podrán expresar su opinión y proponer el enfoque que consideren mejor. Y aquí me gustaría señalar algunos puntos. En primer lugar, la profesión de desarrollador es un campo muy creativo, ya que es necesario encontrar formas únicas de resolver problemas utilizando herramientas estándar. A menudo, un problema puede tener muchas soluciones diferentes: en consecuencia, todo depende del "espíritu creativo" del desarrollador, de la base de conocimientos y la experiencia acumuladas. Aquí puedes mostrar toda tu creatividad y genio, pero lo principal es no exagerar: en este caso, el código se volverá demasiado complejo e ilegible y, como resultado, después de que te vayas, nadie entenderá completamente qué es y cómo funciona. Y necesitarás reescribir todo desde cero. Y es posible que te recuerden. Y más de una vez. Y es poco probable que sean palabras cálidas y amables. ¿Lo necesitas? En segundo lugar, el desarrollador debe ser flexible en el sentido de que no debe quedarse estancado en una solución y cerrarse a otras. Es decir, solo debes hacerlo de esta manera y nada más. Esto puede suceder por varias razones: por ejemplo, quiere demostrar su punto de vista, o ya ha desarrollado e implementado su solución, a la que está bastante apegado y, por supuesto, no quiere admitir que no es la adecuada. mejor. Esto prácticamente puede cegarte. De hecho, debes poder admitir tus errores y estar siempre abierto a cosas nuevas (“de mente abierta”), incluso si tienes que eliminar funcionalidades que has estado escribiendo durante muchas semanas y de las que estás muy orgulloso. Recuerdo que una vez el estado de ánimo de todo el día fue creado por el seguimiento del tiempo de alguien en Jira con el comentario: “Eliminé mi funcionalidad muerta. Lloré"

2. Escribir nueva funcionalidad

Este es un paso lógico después del anterior: la implementación de una nueva funcionalidad. Todo el trabajo del proyecto se divide en tareas en una jira, que los desarrolladores reciben mientras trabajan. Existen diferentes enfoques para este tema: "metodologías", sobre las cuales puede leer más en este artículo sobre JavaRush . Como regla general, las tareas tienen una "estimación" : el tiempo previsto para su finalización. Lo establece usted mismo cuando asume la tarea, o el líder del equipo, o durante la planificación, los desarrolladores lo estiman juntos. Este tiempo rara vez se calcula con precisión, ya que muchos factores diferentes influyen en el desarrollo. Por ejemplo, si el programador está familiarizado o no con esta tecnología, cuál es su experiencia general, varios errores que pueden aparecer ya durante el desarrollo, etc. Por lo tanto, si no cumples con este plazo al desarrollar la funcionalidad, no pasará nada malo. Éstas son sólo estimaciones generales. Pero repito, no todos los proyectos tienen estimaciones de tareas y, en lo que a mí respecta, es mucho más fácil vivir sin ellas, especialmente cuando el primer ministro no te molesta un par de veces al día con la pregunta “¿Dónde están las estimaciones? " En consecuencia, toma una tarea, desarrolla la funcionalidad necesaria, la carga en una rama común en GIT y en Jira cambia el estado de la tarea a "Listo para revisión" , es decir, listo para ver (verificar) y rezar para que no se le devuelve con comentarios sobre la revisión.

3. Redacción de pruebas de funcionalidad.

A la persona que revisa su código (el revisor) le gustó la funcionalidad que desarrolló, pero tiene una pregunta: ¿dónde están las pruebas? Y te devuelve la tarea para que la revises. Las pruebas son una parte importante de cualquier aplicación Java. Al ejecutarlos, puede detectar inmediatamente dónde la aplicación funciona incorrectamente. Por ejemplo, un desarrollador realizó algunos cambios en una parte del sistema, lo que provocó cambios en el comportamiento en otra, y no lo notó durante el desarrollo. Al ejecutar las pruebas, podrá ver las pruebas fallidas (aquellas que no funcionaron correctamente). Esto le indicará que algo está roto en otra parte del sistema. Por lo tanto, no cargará cambios importantes en el servidor, pero continuará perfeccionando su solución. Sí, por supuesto, a pocos desarrolladores les encantan las pruebas, pero no se pueden negar los beneficios que aportan a la aplicación. A menudo, los propios clientes especifican qué nivel de cobertura de prueba deben cumplir (por ejemplo, 80%). Por lo tanto, es necesario conocer diferentes tipos de pruebas y poder escribirlas. Los desarrolladores de Java escriben principalmente pruebas unitarias y pruebas de integración, mientras que AQA (probadores de automatización) se ocupan de pruebas más extensas (de un extremo a otro). Puede leer más sobre ellos y otros representantes de las profesiones de TI en mi reseña .

4. Encontrar y corregir el error

Esta también es una tarea muy común y frecuente para un desarrollador de Java. La tarea principal de QA y AQA es detectar errores. Es decir, buscan lugares donde el programa se comporta incorrectamente, crean problemas en Jira y culpan a alguien. Por ejemplo, un líder de equipo, quien a su vez decide a qué desarrollador asignarle esto, dependiendo de su carga y familiaridad con esta parte del sistema. Después de esto, el desarrollador busca el error, pasa horas en el depurador , utilizando la descripción del problema por parte de los especialistas de control de calidad para repetir la situación en la que ocurrió el error. A continuación, el desarrollador encuentra un error, lo corrige y lo envía para su revisión. Bueno, es posible que el desarrollador no haya podido reproducir el error y devuelva la tarea al especialista en control de calidad con un comentario al respecto. Parece que no llevará mucho tiempo encontrar y corregir el error, pero hay algunos matices. Todo depende principalmente de la familiaridad del desarrollador con esta sección del código, la experiencia y el conocimiento de cuestiones teóricas. A veces se puede encontrar y corregir un error en 20 minutos y, a veces, puede llevar tres días. En consecuencia, este tipo de tarea es especialmente difícil de evaluar de antemano, a menos que el desarrollador, después de leer la descripción, comprenda inmediatamente qué, dónde y con qué salió mal. En este caso, podrá adivinar la hora con mayor o menor precisión.

5. Revisión del código

Como se mencionó anteriormente, tan pronto como complete una tarea, debe enviarla para su revisión y, si la aprueba, ingresa al hilo general; de lo contrario, se devolverá al desarrollador con comentarios sobre lo que se debe hacer. corregido. Está claro que todo esto no lo controlan algunos poderes superiores, sino otros desarrolladores. Pero no todos los desarrolladores pueden convertirse en revisores, sino sólo los más experimentados, que tienen práctica y pueden distinguir el código malo del bueno. La revisión del código generalmente se realiza utilizando una herramienta auxiliar, por ejemplo, Crucible . Los revisores revisan el código y, si es necesario, dejan comentarios debajo de algunas líneas. Los comentarios también pueden ser de varios tipos. Por ejemplo, los críticos, sin cuya corrección el revisor no aprobará el código, y otros son más bien comentarios sobre el enfoque elegido, que el desarrollador puede escuchar, tomar nota o ignorar. El equipo puede crear su propio procedimiento y reglas para realizar revisiones, acordar a qué vale la pena prestar atención y a qué no, dentro de qué plazo se debe realizar la revisión del código, etc. Para realizar una revisión, la experiencia por sí sola no es suficiente: aún necesita desarrollarse mucho en la dirección técnica, leer varios libros (por ejemplo, "Código limpio" ). Si está interesado en los matices de realizar una revisión de código según Google, le aconsejo que lea este artículo .

6. Análisis de código

Dado que el proyecto lo escriben simultáneamente varias personas que piensan de manera diferente, su código y sus enfoques serán diferentes. Y con el tiempo, poco a poco todo se irá convirtiendo en papilla. Para mejorar el código, a veces se crean tareas para analizar, tal vez un módulo en particular o la aplicación completa, para encontrar fallas y marcarlas, y luego crear una tarea de refactorización basada en estos comentarios. El análisis también ayuda en situaciones en las que algunos atajos más simples no eran visibles desde el comienzo del desarrollo, pero se pueden ver ahora. Por ejemplo, la misma lógica se repite a menudo en algunos métodos y, en consecuencia, se puede trasladar a un método independiente y reutilizar muchas veces. Bueno, o alguna clase se ha vuelto dolorosamente inflada, o algún código se ha vuelto difícil de mantener o está desactualizado, o... Las tareas de análisis ayudan a mejorar la calidad del código y la aplicación. Aunque, en mi opinión, analizar una gran cantidad de código puede resultar una tarea aburrida.

7. Refactorización de código

La siguiente parte del análisis es la refactorización del código. Puede que esté desactualizado, que ya no sea necesario, que esté mal escrito, que sea difícil de leer, etc. Siempre debes esforzarte por alcanzar la perfección (aunque no existe) y por un código actualizado, eliminando todo lo innecesario, porque esto sólo confunde e impide ver la esencia de la funcionalidad. No hace falta decir que es poco probable que veas estas tareas al comienzo del proyecto: ocurren sólo en etapas posteriores del desarrollo, cuando la aplicación está pulida y llevada a la perfección. En este caso, puede ser apropiado consultar con colegas sobre cómo lo harían y qué dificultades ven. La esencia de tales tareas es similar al desarrollo de nuevas funciones. Por ejemplo, recibe una tarea para editar alguna funcionalidad sin cambiar su comportamiento. Para ello, borra el anterior, escribe el tuyo propio y comprueba las pruebas. Si hiciste todo correctamente, sin hacer cambios en las pruebas, deberían funcionar como antes. Después de que todo esté configurado en el código, lo enviamos a revisar y nos vamos a tomar un café))

8. Redacción de documentación

Imagine que es un desarrollador nuevo en algún proyecto que ha estado en desarrollo durante mucho tiempo. Debe familiarizarse con él o realizar alguna tarea específica, por ejemplo, detectar un error. ¿Cómo navegarás por el proyecto? ¿Sacar a los miembros de su equipo cada cinco minutos? Y si están ocupados o son fin de semana, ¿entonces qué? Por eso existe la documentación, para que una persona que no esté familiarizada con la funcionalidad pueda entrar, encontrar la página correcta y comprender rápidamente qué hace la parte de la aplicación que le interesa. Pero alguien también debe llenar la documentación ^^ Si el proyecto tiene documentación que los desarrolladores deben soportar, al implementar nueva funcionalidad la describen, y con varios cambios y refactorizaciones actualizan la documentación. También son posibles situaciones en las que se contrata a un especialista independiente, un redactor técnico, para redactar, respaldar y controlar la documentación. Si existe un especialista de este tipo, la vida de los desarrolladores habituales será un poco más fácil.

9. Participación en diversos mítines.

Los desarrolladores dedican mucho tiempo a diversas reuniones, negociaciones y planificación. El ejemplo más simple son las “reuniones diarias” (reuniones diarias), donde debes contar lo que hiciste ayer y lo que vas a hacer hoy. Además, es necesario tener una llamada individual, por ejemplo, con un especialista en control de calidad, para que pueda mostrar/explicar los matices de la reproducción del error, o discutir los matices y requisitos con un analista de negocios u organización. Problemas con un PM. Por lo tanto, aunque un desarrollador sea introvertido y prefiera la soledad, aún así debe poder encontrar un lenguaje común con otras personas (bueno, al menos un poco). Cuanto más alto sea el rango de un desarrollador, más tiempo necesitará para comunicarse y menos tiempo para escribir código. Un líder de equipo de desarrolladores puede incluso dedicar la mitad, o incluso más, de su tiempo de trabajo a conversaciones y reuniones y a escribir código con menos frecuencia (esto puede llevar a perder un poco el control). Pero si también eres alguien a quien le gusta hablar, puedes pasar fácilmente del puesto de líder de equipo al lado gerencial y olvidarte por completo del código, comunicándote todo el día con varios equipos, clientes y otros gerentes.

10. Realizar/aprobar una entrevista

Si trabaja para una empresa de subcontratación o subcontratación de personal, deberá someterse a frecuentes entrevistas externas, cuando necesite que lo "vendan" al cliente (luego puede ser entrevistado por una persona del lado del cliente), y entrevistas internas, para aumentar su rango dentro de la empresa. Yo llamaría a esto un buen factor de desarrollo, ya que gracias a las frecuentes entrevistas, tus conocimientos siempre deben estar en forma: no te oxidarás y te relajarás, porque si te relajas en TI, puedes salir volando por completo del campo. Cuando se convierta en un desarrollador con más experiencia, podrá visitar el otro lado: no pasar, sino realizar entrevistas. Créame, se sorprenderá mucho si lo mira desde esta perspectiva, porque realizar entrevistas puede dar más miedo que pasar. Debe tener su propia estrategia de entrevista, una lista de preguntas y tener tiempo para hacer preguntas sobre todos los temas necesarios en una hora. Y después de eso, usted es responsable de la retroalimentación, porque dependiendo de ella, una persona puede recibir o no una oferta o promoción tan esperada. Bueno, y viceversa: se puede extrañar a un candidato francamente débil para un puesto al que no corresponde, y luego te preguntarán: ¿cómo es posible que lo extrañaras con tal nivel de conocimiento? Por lo tanto, cuando realice una entrevista, tenga en cuenta que la persona que está frente a usted también está pasando por momentos difíciles y es posible que también esté estresada. Cualquier entrevista resulta estresante tanto para el candidato como para el entrevistador. Quizás terminemos aquí. Gracias a todos los que terminaron de leer: dale me gusta y aprende Java ^^