2008-08-26 14 views
11

Mi jefe contrató un nuevo desarrollador directamente de CompSci en un proyecto con una cantidad considerable de deuda técnica. Mi tarea será poner a este chico al tanto y hacer una contribución decente lo antes posible. ¿Alguna sugerencia sobre la mejor manera de hacer esto? ¿Alguna experiencia de primera mano sobre cómo precisamente no hacerlo?¿Cómo poner a un nuevo empleado al día en un proyecto existente?

Mis instintos son hacer algunas revisiones de código en el código escrito por el desarrollador que está reemplazando, programar el nuevo código que estoy escribiendo, o trabajar con él en la escritura de pruebas de unidad para el código que va a heredar.

Respuesta

11

En su primer día, siéntate con él y ayúdalo a configurar su entorno de desarrollo. Si está recién salido de la universidad, puede que no esté familiarizado con un IDE, con Version Control, cualquiera que sea el marco de aplicación que esté utilizando, etc.

El segundo día, permítale jugar con cualquier cosa que crea que vale la pena aprender primero. Por ejemplo, dices que quieres que haga pruebas unitarias, bueno, si no lo hizo, utiliza el día 2 para que se ponga al corriente.

El tercer día pusieron a ese chico a trabajar. Aprender haciendo. Definitivamente haga una revisión del código de cada cosa que escribe al menos durante las primeras semanas, y tómela desde allí.

3

Cuando comencé mi primer trabajo, me lanzaron directamente al fuego con algunas tareas más pequeñas. Esto incluyó la creación de controles menores que eran auxiliares para el proyecto, pero que aún requieren el uso de algunas de las técnicas más avanzadas que estaban en uso con el resto del equipo (acceso a ORM, etc.). También se me proporcionaron algunas tareas de limpieza de la base de datos, lo que me dio una buena comprensión de cómo se presentaron en la base de datos todos los datos que el proyecto tenía que tratar.

Recomendaría no tenerlo haciendo nada más que leer documentos o hacer extensas revisiones de código. Se va a aburrir, y probablemente no recuerde mucho de lo que está haciendo en dos semanas de todos modos. Recuerde, él solicitó el trabajo porque quería escribir código. Demasiadas cosas de mantenimiento lo alejarán.

0

Experiencia de primera mano aquí. No los envíe por su cuenta para leer la documentación. Esta puede ser una tarea muy abrumadora, especialmente si el proyecto es a gran escala.

Lo mejor que se puede hacer es que realmente se meta directamente en el código y comience a trabajar con él.

1

Dele una tarea que actualice algún código existente. La tarea no debe ser terriblemente difícil, pero debe requerir el conocimiento del código. Esté disponible para preguntas, pero no le diga al empleado cómo hacerlo. Después de que se haya codificado la solución, siéntese con el programador y repase la solución.

Es bueno permitir que el programador tenga cierta libertad para escribir el código que hace el trabajo. Es probable que esto introduzca nuevos métodos en el sistema que lo ayudarán a convertirse en un mejor programador.

Solo asegúrese de ayudar al chico nuevo a aprender algunos de los estándares de codificación para su empresa. Esos siempre son un dolor de aprender.

1

En mi trabajo actual, mi primera tarea era actualizar las herramientas utilizadas para construir e implementar nuestras aplicaciones web. Realmente resultó ser una gran idea por algunas razones:

  • Las herramientas existentes se estaban desactualizando y necesitaban algunas características nuevas de todos modos.
  • Aprendí cómo se organizaron los diversos proyectos y bases de códigos.
  • Me dio la oportunidad de adaptarme a los estilos y prácticas de codificación de la empresa.

Así que sí, creo que fue un poco decepcionante que no estuviera trabajando en los productos reales de inmediato, pero creo que definitivamente era el camino correcto a seguir.

Estoy seguro de que todas las empresas tienen alguna herramienta o proyecto de baja prioridad que nadie más tiene tiempo para trabajar. Dale este proyecto al chico nuevo, dale la oportunidad de escribir un código nuevo y luego ve cómo funciona todo. En el peor de los casos, el proyecto es un fracaso pero no se dañó el código de producción.

1

La tutoría entre iguales es una muy buena forma de acelerar la contratación de nuevos empleados, consulte website y associated book para obtener más información. La técnica fue desarrollada en Microsoft (creo) y ha sido adoptada por muchas otras firmas también.

Actualmente estoy leyendo el libro, que contiene un montón de ideas interesantes, algunas de las cuales están destinadas a ayudarlo a pensar cómo usted y su aprendiz (el nuevo empleado) prefieren comunicarse y ayudarlo a establecer- un proceso ligero y simple para hacer esto.

Editar: No estoy afiliado con el autor del libro, me acaba de gustar su idea y fue presentado por mi empleador actual.

2

Recomendaría algo como leer la documentación (a menos que tenga un buen documento corto que proporcione una visión general sólida del diseño del sistema), revisiones de código o mi favorito: "familiarizarme con la base de código".

Todas estas cosas son realmente difíciles de mantener enfocadas cuando eres nuevo en un proyecto. Las revisiones del código no son útiles sin algunos conocimiento previo del sistema.

Idealmente, le daría una tarea muy pequeña y localizada en la que puede trabajar solo y hacer las preguntas que considere necesarias. Esto lo ayuda a comenzar con sus procesos de desarrollo, control de fuente, etc. mientras realiza el código real.

Es incluso mejor si ya conoce la solución para la tarea, de esa manera ya conoce las respuestas a cualquier pregunta que pueda hacerle y responda rápidamente.

Escribir pruebas de unidad para el código que heredará también es una gran idea: escribirá el código y se familiarizará con cómo se supone que debe funcionar.

2

Corrección de errores.

Esa es la mejor manera de aprender una base de código. Sí, apesta, pero es una gran manera de aprender.

+0

No realmente. Las correcciones de errores no ayudan a obtener una visión general de todas las piezas en movimiento. A menudo puede ser solo un ejercicio de extrema frustración a medida que avanzas por las locas persecuciones tratando de encontrar sistemas y subsistemas que hagan las cosas. Creo que esta es la peor forma de acelerar la velocidad de un programador. – PlexQ

0

Una de las cosas más útiles que hacer es recorrer el programa que va a mantener y explicar cómo funciona el sistema. Asegúrese de que la explicación del proceso comercial sea una de las principales cosas cubiertas el primer día. Independientemente de cómo funciona el código (o no funciona), debe comprender lo que se supone que debe lograr.

0

Mucho de esto se trata de aprender los procesos de su organización. No es solo aprender cómo funciona el código.

Empleamos dos novatos el año pasado.Nos aseguramos de que tuviéramos tareas reales para ellos, lo que les permitió estar al tanto del control de versiones, bases de datos de errores, wiki, etc., les dio tanta supervisión y ayuda como pidieron, y luego un poco más, verificaron qué hizo, y por dos semanas en que estábamos muy contentos con ellos y confiamos en ellos para hacer el trabajo. A medida que pasó el tiempo, contribuyeron a nuestros procesos existentes y los mejoraron.

Hicimos una pasantía en este año, y le dimos mucha más supervisión, incluida la revisión cuidadosa de su primer código, y repetidamente hasta que fue correcto. Tres meses todavía necesita ayuda de vez en cuando, pero sabe cuándo preguntar y se ha convertido en un miembro útil del equipo.

Si ha decidido emplearlos, ya ha tomado la decisión de confiar en ellos. Déles un mentor (podría ser usted), exponiéndolos gradualmente a sus sistemas y al código base, y trabaje desde allí.

1

la programación en parejas

Estoy de acuerdo con muchas de las respuestas aquí, especialmente aprender con la práctica. He experimentado con muchos aspectos diferentes al permitir que el nuevo empleado:

  • Trabajo un proyecto paralelo para obtener el cómodo con el medio ambiente
  • Tinker y dejar que resolver las cosas poco a poco con el tiempo, con las revisiones de código continua
  • Turnarse programación en parejas con diferentes miembros del equipo, mientras que en realidad trabaja en el proyecto

lo pienso de una manera en la que si yo fuera un nuevo empleado en alguna empresa de construcción y tenía la tarea de construir un muro en una casa existente, pero no había sido Durante los últimos 6 meses de desarrollo de esta casa, el riesgo que implica hacer las cosas correctamente aumenta. Sin embargo, si en ese primer día (y días después) me emparejaron con alguien que supiera qué esperar, me sentiría más cómodo y estoy seguro de que la compañía se sentiría más cómoda sabiendo que estaba aprendiendo de alguien que tenía hecho antes ... y hecho bien.

De las diferentes cosas probadas, nada ha sido tan exitoso como Par Programming. Parece que no hay sustitutos para ayudar a alguien a aprender los pormenores del sistema/herramientas/idioma/proyecto/etc. Realmente no importa en qué están trabajando ... ya sean nuevas características, corrección de errores, proyectos secundarios, sistemas de compilación, etc. Hay una gran diferencia entre alguien realmente diciendo cómo funcionan las cosas versus mostrando cómo.

2

Recientemente fui el nuevo empleado en esta situación ... aunque sí tuve experiencia previa en el "mundo real".

Mi jefe y sus representantes siempre decían "jugar con el sistema" o "leer documentación". Encontré esto realmente molesto. Integré mis propias tareas, es decir, estableciendo puntos de corte que sabía que serían afectados, y luego hacer una operación simple pero esencial en el sistema, y ​​pasar de la cuna a la tumba.

Al hacer esto, dibujé diagramas de pseudodiseño de quién llamaba a quién con qué, básicamente, ingeniería inversa. Luego, me gustaría que uno de los otros desarrolladores se sentara conmigo y me corrigiera mientras le dictaba lo que creía que era la responsabilidad de cada clase y lo que estaba haciendo.

Aparte de eso, si no tienes ningún trabajo carnoso para el chico/chica nuevo, trataría de inventar proyectos a corto plazo que no sean trabajos triviales, pero cuya experiencia te ayudará cuando hay un trabajo real para que él/ella haga.

Por supuesto, si hay trabajos a corto plazo pero significativos disponibles, comience con eso. El resultado final es dar tareas bien definidas con un objetivo. De lo contrario, si son como yo, se les ocurrirán sus propias tareas y objetivos para evitar el aburrimiento.

Cuestiones relacionadas