unit-testing - unitarias - unit test c# visual studio 2015
¿Cómo poner a un nuevo empleado al tanto de un proyecto existente? (12)
Aconsejo que no lea la documentación (a menos que tenga un buen documento breve que brinde una descripción general sólida del diseño del sistema), revisiones de código o mi favorito: "familiarizarse con la base de código".
Todas esas cosas son realmente difíciles de enfocar cuando eres nuevo en un proyecto. Las revisiones del código no son útiles sin algún conocimiento previo del sistema.
Idealmente, le daría una tarea muy pequeña y localizada en la que él solo puede trabajar por sí mismo y hacer preguntas según sea necesario. 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á código y se familiarizará con cómo se supone que funciona.
Mi jefe contrató a un nuevo desarrollador directamente de CompSci para 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?
Mi instinto es hacer algunas revisiones de código en el código escrito por el desarrollador que está reemplazando, la programación de par en el nuevo código que estoy escribiendo, o trabajar con él en la escritura de pruebas de unidad para el código que heredará.
Corrección de errores.
Esa es, de lejos, la mejor forma de aprender una base de código. Sí, apesta, pero es una gran manera de aprender.
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.
Aconsejarí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.
Dale 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úrate de ayudar al chico nuevo a aprender algunos de los estándares de codificación para tu empresa. Esos siempre son un dolor de aprender.
En mi trabajo actual, mi primera tarea fue actualizar las herramientas utilizadas para construir y desplegar nuestros webapps. Realmente resultó ser una gran idea por algunas razones:
- Las herramientas existentes se estaban desactualizando y necesitaban algunas funciones nuevas de todos modos.
- Aprendí cómo se organizaron los diferentes 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.
En su primer día, siéntese con él y ayúdelo a establecer su entorno de desarrollo. Si está recién salido de la universidad, es posible que no esté familiarizado con un IDE, con el Control de versiones, con los marcos de aplicaciones que esté utilizando, etc.
El segundo día, déjalo engañar con todo lo que creas que vale la pena aprender primero. Por ejemplo, dices que quieres que haga Pruebas Unitarias, bueno, si no lo hizo, usa el día 2 para que se ponga al corriente.
El día tres 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í.
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 empiece a trabajar con él.
Una de las cosas más útiles para hacer es caminar a través del 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.
La tutoría entre pares es una muy buena manera de poner al día a las nuevas contrataciones, consulte el sitio web y el libro asociado 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 ayudarte a pensar sobre cómo tú y tu aprendiz (el nuevo empleado) prefieren comunicarse y para ayudarte a configurar un peso ligero y proceso simple para hacer esto.
Editar: No estoy afiliado con el autor del libro, me acaba de gustar su idea y fue presentado por mi actual empleador.
Programación de par
Estoy de acuerdo con muchas de las respuestas aquí, especialmente Aprender haciendo . Experimenté de muchas maneras al permitir que el nuevo empleado:
- Trabaje un proyecto paralelo para sentirse cómodo con el medioambiente
- Tinker y dejar que resuelvan las cosas lentamente con el tiempo, con revisiones de código continuas
- Haz turnos para emparejar la programación con diferentes miembros del equipo mientras trabajas en el proyecto
Lo pienso de una manera en la que si fuera un nuevo empleado de una empresa de construcción y tuviera la tarea de construir una pared en una casa existente, pero no había estado allí durante los últimos 6 meses de esta casa en desarrollo, el riesgo involucrado conmigo hacer las cosas correctamente va hacia arriba. 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 lo había hecho. antes ... y hecho bien .
De las diferentes cosas probadas, nada ha sido tan exitoso como la programación de pares . 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, arreglando errores, proyectos secundarios, sistemas de compilación, etc. Hay una gran diferencia entre alguien que realmente le dice cómo funcionan las cosas y le muestra cómo hacerlo.
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.
Tomamos un interno en este año, y le dimos mucha más supervisión, incluyendo la revisión cuidadosa de su primer código, y varias veces hasta que estuvo 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. Bríndeles un mentor (podría ser usted), exponiéndolos gradualmente a sus sistemas y al código base, y trabaje desde allí.
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.
Mientras hacía 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 sustancioso para el chico / chica nuevo, trataría de inventar proyectos a corto plazo que no sean trabajos triviales, pero cuya experiencia te ayudará cuando haya 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.