Las tareas típicas de un desarrollador de Java en un proyecto

¿Cuáles son las responsabilidades típicas de un desarrollador de Java? Después de todo, necesitas entender en lo que te estás metiendo y lo que terminarás haciendo, ¿verdad? Hoy me gustaría hablar sobre diez tareas vitales que realiza un desarrollador de Java. Pero primero, familiaricémonos con una herramienta llamada Jira. O refréscate en la memoria, si ya lo conoces. jiraes una herramienta para organizar las interacciones humanas, aunque en algunos casos también se utiliza para la gestión de proyectos. En otras palabras, un proyecto se divide en pequeñas tareas que se describen en esta herramienta. Estas tareas se asignan a los desarrolladores, quienes son los responsables de su implementación. Una tarea podría ser, por ejemplo, agregar alguna funcionalidad. A medida que se realiza una tarea, los desarrolladores y otros especialistas agregan comentarios sobre quién hizo qué y cuánto tiempo dedicaron. Esto se hace con fines de seguimiento del tiempo: para saber cuánto tiempo se dedicó a qué tareas. Idealmente, esto se hace una vez al día: antes de dejar su escritorio por la noche, indique cuánto de sus 8 horas de trabajo pasó en varias tareas. Hay mucho más en la funcionalidad de Jira que lo descrito anteriormente, pero esto será suficiente para una comprensión inicial.

1. Diseñar nuevas soluciones

Antes de crear e implementar algo, necesitas conceptualizarlo, ¿verdad? Como dije antes, esto podría ser simplemente una tarea en Jira que se le asigna, por lo que trabaja para diseñar una nueva solución, registrando en Jira cuánto tiempo pasó y en qué. Este trabajo también podría ocurrir durante una discusión en una conferencia telefónica de equipo: todos pueden expresar su opinión y proponer el enfoque que consideren mejor. Y aquí me gustaría señalar algunos puntos. En primer lugar, el desarrollo de software es una profesión muy creativa, ya que necesita utilizar herramientas estándar para encontrar formas novedosas de resolver problemas. Una tarea a menudo puede tener muchas soluciones diferentes. En consecuencia, todo depende de la creatividad del desarrollador, que está fuertemente influenciada por su conocimiento y experiencia acumulados. Puedes mostrar toda tu creatividad y genialidad aquí, pero lo importante es no exagerar. Si lo hace, el código se volverá demasiado complejo e ilegible. Como resultado, después de que te vayas, nadie entenderá completamente lo que codificaste y cómo funciona. Y tendrán que reescribir todo desde cero. Y pueden recordarte. Mas de una vez. Y es poco probable que se pronuncien palabras cálidas y amables. ¿Necesitas eso? En segundo lugar, un desarrollador debe conservar la flexibilidad psicológica en el sentido de que no debe aferrarse a una única solución y volverse de mente cerrada a los demás. Como si tuvieras que hacer algo de una sola manera y no hubiera otras opciones. Puede caer en esta trampa por varias razones. Por ejemplo, suponga que desea probar que su punto de vista es correcto. O tal vez ya haya diseñado e implementado su propia solución familiar, por supuesto, no querrías admitir que no es el mejor. Estas situaciones pueden dejarlo bastante ciego. De hecho, debe poder admitir sus errores y tener siempre la mente abierta, incluso si tiene que eliminar la funcionalidad de la que está orgulloso y ha estado codificando durante más de una semana. Recuerdo cómo un compañero de trabajo iluminó el día de todos una vez al dejar este comentario de seguimiento del tiempo en Jira: "Me quité mi característica mortinata. Y lloré".

2. Escribiendo nueva funcionalidad

Este paso, implementar una nueva funcionalidad, sigue lógicamente al anterior. Todo el trabajo involucrado en un proyecto se divide en tareas en Jira, que luego se distribuyen a los desarrolladores en función de su carga de trabajo. Existen diferentes enfoques para este proceso, conocidos como "metodologías", que puede leer con más detalle en este artículo en CodeGym . Por regla general, las tareas tienen una estimación, que es el tiempo previsto necesario para completarlos. Lo establece usted, el desarrollador cuando recibe la tarea, o el líder del equipo, o durante la planificación, colectivamente por el equipo de desarrollo. Esta conjetura de tiempo rara vez es precisa, ya que muchos factores diferentes afectan el desarrollo de software. Por ejemplo, si un programador está familiarizado o no con la tecnología relevante, su experiencia general, varias trampas imprevisibles, etc. Entonces, si no alcanza todas sus estimaciones de tiempo al codificar, no es el fin del mundo. Estas son solo estimaciones generales. Dicho esto, no todos los proyectos requieren estimación de tiempo. Personalmente, me resulta mucho más fácil vivir sin él, especialmente cuando el PM no me molesta un par de veces al día con la pregunta "¿dónde están tus estimaciones de tiempo?" Entonces, tienes una tarea,Listo para revisión " en Jira y reza para que los cambios en tu código no se devuelvan para su revisión junto con los comentarios.

3. Pruebas de escritura

Al revisor, es decir, la persona que revisa tu código, le gusta la funcionalidad que implementaste, pero tiene una pregunta para ti: ¿dónde están las pruebas asociadas? Entonces ella te envía la tarea para que la revises. Las pruebas son una parte esencial de cualquier aplicación Java. Al ejecutar pruebas, puede identificar de inmediato los lugares donde la aplicación no funciona correctamente. Por ejemplo, un desarrollador realiza algunos cambios en una parte del sistema, lo que da como resultado cambios en el comportamiento de otra parte, pero no lo notó mientras codificaba. Al ejecutar las pruebas, podrá ver que ciertas pruebas fallaron, lo que significa que no produjeron los resultados esperados. Esto le dice que algo está roto en alguna otra parte del sistema. Sabiendo esto, no realizará los cambios importantes en el servidor y, en cambio, continuará trabajando en la depuración de su código. Sí, a muy pocos desarrolladores les encanta escribir pruebas, pero no se pueden negar los beneficios que aportan al desarrollo de software. Los propios clientes suelen indicar el nivel de cobertura de las pruebas que quieren mantener (por ejemplo, el 80 %). Eso significa que usted necesita saberlos distintos tipos de pruebas y ser capaz de escribirlas. Los desarrolladores de Java escriben principalmente pruebas unitarias y pruebas de integración, mientras que las pruebas más extensas (extremo a extremo) son manejadas por expertos en control de calidad y automatización de pruebas.

4. Encontrar y corregir errores

Esta es también una tarea muy común y frecuente para los desarrolladores de Java. El trabajo principal de los expertos en control de calidad y automatización de pruebas es detectar errores. En otras palabras, buscan lugares donde el programa se comporta incorrectamente, luego crean tareas en Jira y se las asignan a alguien. Por ejemplo, a un líder de equipo, quien, a su vez, decide a qué desarrolladores asignarlos, según su carga de trabajo y su familiaridad con las partes relevantes del sistema. Después de eso, el desarrollador asignado busca la causa raíz del error y pasa horas en un depurador., utilizando la descripción del error proporcionada por los expertos en control de calidad para reproducir las condiciones en las que se produce el error. Una vez que el desarrollador encuentra el error y lo corrige, envía la corrección para su revisión. A veces, el desarrollador no puede reproducir el error, por lo que envía la tarea al experto en control de calidad junto con un comentario explicativo. Parece que no debería llevar mucho tiempo encontrar y corregir un error, pero hay algunos matices. Todo depende principalmente de qué tan familiarizado esté el desarrollador con esta sección del código y de su experiencia y conocimiento teórico. A veces, un error se puede encontrar y corregir en 20 minutos y, a veces, puede llevar tres días. Esto significa que este tipo de tarea es especialmente difícil de estimar de antemano, a menos que el desarrollador, al leer la descripción, comprenda de inmediato el qué, dónde y cómo del error. En este caso,

5. Revisión de código

Como se mencionó anteriormente, tan pronto como complete una tarea, debe enviarse para su revisión. Si pasa la revisión, pasa a la rama principal. De lo contrario, se devuelve al desarrollador con comentarios que deben abordarse. Por supuesto, usted entiende que su código es revisado por otros desarrolladores, no por un alto poder. Dicho esto, no todos pueden realizar revisiones de código, solo los desarrolladores más experimentados endurecidos por la práctica del mundo real, quienes pueden diferenciar entre un código bueno y un código malo. Las revisiones de código generalmente se realizan utilizando una herramienta auxiliar como Crucible. Los revisores revisan el código y, si es necesario, dejan comentarios sobre ciertas líneas. Puede haber varios tipos de comentarios. Por ejemplo, algunos son críticos. Si no se abordan, el revisor no permitirá que se confirme el código. Otros comentarios son, digamos, simplemente comentarios sobre el enfoque elegido. El desarrollador puede escucharlos, tomar nota de ellos o ignorarlos. Un equipo puede crear sus propias reglas y procedimientos para las revisiones de código, acordando a qué vale la pena prestar atención y a qué no, qué plazo debe asignarse para completar una revisión de código, etc. La experiencia por sí sola no es suficiente para realizar una revisión: todavía necesita crecer mucho en sus habilidades técnicas y leer varios libros (por ejemplo, "Clean Code").

6. Análisis de código

Dado que varias personas que piensan de manera diferente escriben código para el proyecto simultáneamente, su código y enfoques serán diferentes. Y con el tiempo, todo se convierte gradualmente en un desastre. Para mejorar el código, a veces se crean tareas para, por ejemplo, analizar un determinado módulo o toda la aplicación, encontrar y tomar nota de las deficiencias, y luego crear una tarea de refactorización basada en este análisis. Dicho análisis también ayuda en situaciones en las que, cuando comenzó el desarrollo, el equipo no pudo ver algunas soluciones más simples y concisas, pero las ven ahora. Por ejemplo, la lógica a menudo se duplica en algunos métodos. En consecuencia, se puede extraer en un método separado, que luego se puede reutilizar muchas veces. O tal vez una clase se ha vuelto demasiado 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 de la aplicación. Dicho esto, para mí, analizar una gran cantidad de código puede resultar aburrido.

7. Código de refactorización

La siguiente parte del análisis de código es la refactorización. El código puede estar desactualizado, obsoleto, mal escrito, difícil de leer, etc. Siempre debe luchar por la perfección (aunque no exista) y por el código actualizado, eliminando todo lo superfluo, porque lo superfluo solo genera confusión e interfiere con la capacidad de ver lo que está haciendo el código. No hace falta decir que es poco probable que vea estas tareas al comienzo de un proyecto: las encuentra en etapas posteriores de desarrollo cuando la aplicación se está puliendo y perfeccionando. Aquí, puede ser apropiado consultar con los compañeros de trabajo sobre lo que harían y las trampas que ven. En el fondo, tales tareas son similares al desarrollo de nuevas funciones. Por ejemplo, suponga que recibe una tarea para editar alguna funcionalidad sin cambiar su comportamiento. Para hacer esto, elimina el código anterior, escribe el suyo propio y verifica las pruebas. Si hizo todo bien, entonces, sin hacer ningún cambio en las pruebas, todas deberían pasar como antes. Después de que todo en el código es como debería ser, lo enviamos para una revisión y tomamos un café :)

8. Redacción de documentación

Imagina que eres un nuevo desarrollador en algún proyecto de desarrollo de software a largo plazo. Debe familiarizarse con el código base o realizar alguna tarea específica, por ejemplo, diagnosticar un error. ¿Cómo navegarás por el proyecto? ¿Acosar a tus compañeros de equipo cada cinco minutos? Y si están ocupados o es fin de semana, ¿entonces qué? Esta es precisamente la razón por la que tenemos documentación: para que una persona que no esté familiarizada con el código pueda ingresar, encontrar la página relevante y descubrir rápidamente qué está pasando en la parte de la aplicación que le interesa. Pero alguien tiene que crear la documentación, jaja. Si un proyecto tiene documentación que los desarrolladores deben respaldar, cuando implementan una nueva funcionalidad, la describen y actualizan la documentación junto con cualquier cambio de código o refactorización. También puede haber situaciones en las que se contrate a un empleado independiente, un escritor técnico, para escribir, mantener y supervisar la documentación. Si tal especialista está disponible, la vida de los desarrolladores comunes es un poco más fácil.

9. Varias reuniones

Gran parte del tiempo de los desarrolladores se dedica a diversas reuniones, negociaciones y planificación. El ejemplo más simple es la reunión de pie diaria, en la que debe informar lo que hizo ayer y lo que hará hoy. Además, deberá tener llamadas telefónicas individuales, por ejemplo, con evaluadores, para que puedan demostrar/explicar los matices de reproducir un error, discutir las sutilezas y los requisitos con un analista de negocios o hablar sobre problemas organizacionales. con un PM. Esto significa que, aunque un desarrollador puede ser introvertido y prefiere la soledad, aún necesita poder encontrar un terreno común con otras personas (bueno, al menos un poco). Cuanto más alto es el rango de un desarrollador, más tiempo necesita dedicar a la comunicación y menos tiempo a escribir código. Un líder de desarrollo puede pasar la mitad, o incluso más, de su jornada laboral solo en conversaciones y reuniones y puede escribir código con menos frecuencia (lo que posiblemente le haga perder un poco de su destreza en la codificación). Pero si simplemente le encanta hablar, podría, como líder de equipo, hacer la transición a la gestión y olvidarse por completo de escribir código; en cambio, pasaría todo el día comunicándose con varios equipos, clientes y otros gerentes.

10. Realización/aprobación de entrevistas

Si trabaja para una empresa de subcontratación o subcontratación de personal, a menudo tendrá que pasar por entrevistas externas, en las que tendrá que "venderse" al cliente (puede ser entrevistado por alguien que trabaje para el cliente), así como por entrevistas internas. para subir de rango dentro de la empresa. Yo llamaría a esto una buena oportunidad de crecimiento porque las entrevistas frecuentes te obligarán a mantener tu conocimiento afilado: no te oxidarás ni te ablandarás. Después de todo, si te vuelves blando en TI, puedes quedar completamente fuera del campo. A medida que se convierta en un desarrollador más experimentado, podrá encontrarse al otro lado de la mesa, realizando entrevistas en lugar de aprobarlas. Créame, se sorprenderá mucho cuando lo mire desde esta posición, porque hacer las preguntas de la entrevista puede ser más aterrador que responderlas. Debe tener su propia estrategia de entrevista, una lista de preguntas y tiempo para hacer preguntas sobre todos los temas necesarios en una hora. Y después de eso, usted es responsable de proporcionar comentarios que influirán en la decisión de contratación y si el candidato recibe una oferta o promoción largamente esperada. O bien, puede permitir que una candidata obviamente débil obtenga un puesto para el que no califica, y luego se le puede preguntar: "¿cómo podría permitir que la contraten con ese nivel de conocimiento?" Por lo tanto, cuando esté en el banquillo durante una entrevista, tenga en cuenta que la persona que tiene delante también se enfrenta a un desafío y puede estar estresada. usted es responsable de proporcionar comentarios que influirán en la decisión de contratación y si el candidato recibe una oferta o promoción esperada desde hace mucho tiempo. O bien, puede permitir que una candidata obviamente débil obtenga un puesto para el que no califica, y luego se le puede preguntar: "¿cómo podría permitir que la contraten con ese nivel de conocimiento?" Por lo tanto, cuando esté en el banquillo durante una entrevista, tenga en cuenta que la persona que tiene delante también se enfrenta a un desafío y puede estar estresada. usted es responsable de proporcionar comentarios que influirán en la decisión de contratación y si el candidato recibe una oferta o promoción esperada desde hace mucho tiempo. O bien, puede permitir que una candidata obviamente débil obtenga un puesto para el que no califica, y luego se le puede preguntar: "¿cómo podría permitir que la contraten con ese nivel de conocimiento?" Por lo tanto, cuando esté en el banquillo durante una entrevista, tenga en cuenta que la persona que tiene delante también se enfrenta a un desafío y puede estar estresada. Cualquier entrevista es estresante tanto para el candidato como para el entrevistador. Probablemente terminaremos aquí. Gracias a todos los que leyeron este artículo. Deja un me gusta y sigue aprendiendo Java :)