¿Cuáles son las mejores prácticas al cambiar entre proyectos / volver a proyectos con frecuencia?

La naturaleza de mi trabajo es que tengo que alternar entre proyectos cada pocas semanas. Me parece que uno de los mayores impedimentos para mi productividad es el tiempo de aceleración para recuperar todos los elementos relevantes del código "de nuevo en mi cabeza" después de no verlo durante un período. Esto sucede en mayor o menor medida para pausas más breves / pausas más largas.

Obviamente, un buen diseño, documentación, comentarios y estructura física ayudan con esto (sin mencionar el cambio entre proyectos con la menor frecuencia posible). Pero me pregunto si hay prácticas / herramientas que me estoy perdiendo. ¿Cuáles son sus prácticas específicas para mejorar esto?

También cambio con frecuencia entre diferentes proyectos (tanto técnicos como no técnicos). La organización o "facilidad de recuperación" ha sido clave para mí. Antes de abandonar un proyecto, me aseguro de poner las cosas en orden para que me resulte fácil recuperar el contexto en mi cabeza. Para mí, esto significa poner todas las cosas relevantes (marcadores, archivos, documentos, correos electrónicos, etc.) o enlaces a ellas en una carpeta para que no tenga que buscar fuentes de información.

Una cosa que comencé a hacer recientemente es usar una máquina virtual para cada proyecto grande. Cuando necesito cambiar a otro proyecto, mantengo abiertas todas las aplicaciones relevantes y luego suspendo la máquina virtual. Entonces, cuando necesito volver al proyecto, puedo iniciar la VM y me presentará toda la información que ya está en la pantalla.

Algunas cosas que ayudan:

• Optimice al máximo su código para facilitar la lectura y la claridad.
• Deje punteros y sugerencias para usted en el código, en forma de comentarios.
• Sigue a KISS y DRY.
• Sea consistente, dentro de cada proyecto y entre proyectos.
• Sé religioso sobre la refactorización.
• Documentar todo; considere su futuro como una persona diferente sin forma de hacerle preguntas a su ser actual.
• Evite el código "inteligente" que rompa su IDE / editor.
• Use el control de fuente, con mensajes de confirmación que le dicen dónde dejó exactamente las cosas; etiquete las versiones que considere enviables y apunte por períodos cortos entre las versiones enviables.
• Si puede elegir el lenguaje de programación, elija uno que pueda ayudarlo a hacer las cosas bien.
• Este es un asunto de gusto personal, pero funciona bien para mí, por lo que lo recomendaré de todos modos: mantenga un documento de texto simple y conciso que contenga las próximas tareas y actualícelo cada vez que termine una tarea. Utilice también este documento para notas de nivel de diseño que no encajan en los comentarios de código. Básicamente, este documento de texto debe contener todo su diseño, solo en forma condensada (suficiente información para que usted tenga sentido, pero lo suficientemente breve como para que pueda volver a la silla en 10 minutos). Un rastreador de errores también funciona, pero el documento de texto tiene una serie de ventajas: te obliga a cortar la pelusa y enfocarte en las cosas relevantes, y puede comprometerse con el control de la fuente junto con el código real, lo que significa que está naturalmente vinculado a Versiones SCM.

Hago algo similar a lo que hace RonE.

Tener un proyecto fácil de leer, con un buen diseño ayuda, pero antes de abandonar un proyecto, asegúrese de que todo el contexto y la información que tiene en su cabeza esté escrito o almacenado en algún lugar. Por ejemplo, notas sobre las funciones de biblioteca de terceros que estaba utilizando si era una nueva que nunca antes utilizó. Siempre escribo notas sobre las cosas que aprendo o pienso, en mis propias palabras.

Además, lo que encuentro más importante para escribir en un archivo es si escribe TODO comentarios en su código, copia el último en el que estaba trabajando, y péguelo en un nuevo archivo de texto y llámelo TODO. Escriba en él información contextual sobre dónde pertenece la etiqueta TODO y escriba lo que tenía en mente o lo que cree que le gustaría saber sobre esa tarea.

Dos cosas han sido clave para mí: consistencia y especificación.

La consistencia es clave para el código. No necesito recordar dónde está todo y cómo interactúa todo si puedo extrapolar lo que hubiera hecho. Si es un proyecto con otros que se vuelve más problemático, pero los estándares de código ayudan bastante. Saber qué es algo al mirarlo y hacer algunas suposiciones seguras disminuye un poco el tiempo de incorporación.

La especificación es más útil para el diseño. Al menos para mí, encuentro que tiendo a olvidar algunos de los matices del diseño del producto después de un descanso. O cuando regrese, es debido a esta increíble idea que rápidamente aparece en el proyecto. Si su proyecto no tiene buenos requisitos (ya sea en una especificación en cascada o una cartera de pedidos del producto), básicamente tiene que reinventarlos cada vez que regrese al proyecto. Casi todas las mejores prácticas para el desarrollo de software siguen siendo las mejores prácticas cuando se trata de un proyecto personal; no escatime en ellos.

La clave IMO es una API inteligente de cada uno de sus proyectos. También cargar el código en un repositorio como GIT u otros le permite "viajar en el tiempo" a través de sus compromisos con el código.

Como realizo el soporte de desarrollo y producción para varios clientes, cambio de proyectos varias veces al día. Las dos cosas que más me ayudan son nunca abandonar un proyecto hasta que haya guardado todo (y me comprometo con una sucursal local si no está en el estado en el que quiero volver a colocarla en la rama principal de mi control de fuente) y yo establecer un punto de interrupción en el lugar donde lo dejé Solo poder encontrar rápidamente la línea exacta donde la dejé, me ayuda a volver al ritmo de un proyecto mucho más rápido. También tiendo a crear una lista de tareas pendientes para cada proyecto importante y marcar las cosas a medida que se realizan, por lo que una revisión rápida de eso me dice dónde estoy también y me recuerda mi proceso de pensamiento sobre el proyecto. En general, también me escribo una nota rápida de cosas en las que estaba pensando pero que aún no había hecho si lo necesitaba (cosas como: