Una compilación larga paraliza todo el proceso de desarrollo de software. No debe aceptar esto como un hecho de la vida sin antes tomar medidas para reducir el tiempo de construcción. Aquí hay algunas maneras en que puede hacer eso:

1. Compra un SSD .
2. Agregue más memoria RAM.
3. Si está desarrollando una aplicación web: use browserify para recargar en caliente su código del lado del cliente.
4. Durante el desarrollo, construya solo las partes del código base que están cambiando.
5. Investigue el código de compilación y, en su máquina local, cortocircuite la compilación para que genere solo las partes del código base que están cambiando.
6. Considere ejecutar pruebas unitarias automatizadas solo antes de los registros.
7. Colabore con los miembros del equipo y los gerentes para reducir permanentemente el tiempo de construcción.

Más sobre #1 y #2: Estos son especialmente efectivos. Debe hacer esto incluso si necesita gastar dinero de su propio bolsillo porque aumentará su satisfacción general en el lugar de trabajo. Un buen carpintero no toleraría una sierra desafilada y usted no debería tolerar un disco duro lento o una estación de trabajo con RAM insuficiente. Quieres estar en casa por la noche, cenar con tu familia o ver Netflix. No querrás sufrir una miserable "muerte por mil cortes" esperando construcciones lentas.

EDITAR:

1. Para aquellas personas que dijeron que no respondí la pregunta del OP: consideren esta Meta respuesta .
2. Una construcción lenta puede paralizar el lugar de trabajo. Es muy importante explorar todas las opciones antes de aceptar el hecho de que la compilación es lenta.

Una pelea de espadas es un gran ejercicio. úsalo

Para ser honesto, no hay mucho que puedas hacer con el código cuando se está compilando. Puede intentar reducir el tiempo de compilación, pero algunas veces eso no es posible. Puede intentar reducir la cantidad de compilaciones, pero nuevamente, a veces simplemente apesta.

SO..., para mejorar la productividad, solo necesitas ser mejor que una silla, una pelea de espadas. Yo sugeriría:

• Responder correos electrónicos
• Boletos de documentos
• Solicitud de documentos
• Comprométete con SCM si puedes
• Tómate un descanso legítimo.
• Manejar otras tareas de código no relacionadas
• tener reuniones con los miembros del equipo
• tomar una siesta

Honestamente, es una de las razones por las que me gustan los idiomas que me gustan. Sin tiempo de compilación. Si tiene un tiempo de compilación que es largo, simplemente tendrá que lidiar con él, suponiendo que no pueda abordarlo.

Por ejemplo, en .NET podría separar grandes porciones de lógica en archivos DLL. Entonces solo tiene que compilar secciones de código con frecuencia.

También puede mirar las opciones del compilador y elegir opciones que "aborten después del primer error".

Nota Acabo de notar que su tiempo de compilación es de 30 segundos. Eso no es un tiempo de construcción largo. Si quieres hacer algo en ese momento, haz ejercicios con los dedos o levántate y respira hondo. Los tiempos de construcción largos son de 10 minutos. o más.

Algo de mi propia experiencia:

Intenta corregir varios errores a la vez.

Claro, es muy rápido intercambiar dos columnas, después de notar que están intercambiadas. Pero asegúrese de no dejar de verificar después de encontrar 1 falla.

Por ejemplo, podría reducir el número de ciclos comprobando otras cosas:

• ¿Están las columnas al menos formateadas correctamente?
• ¿Todas las demás columnas contienen lo que deberían?
• ...

Esto es especialmente importante en los primeros 1 o 2 ciclos y podría ayudarlo a volver de 15 a 5 retrasos de 30 segundos (y probablemente también un mejor resultado).

Intente crear un script que haga lo que necesita que haga y luego haga un ruido audible y/o haga una ventana emergente. De esta manera, si desea desviar su atención, no tiene que preocuparse por distraerse por completo y olvidarse de comprobar si ha terminado. Para mí, está bien "distraerse" mirando otras cosas como otro código, pero el problema es cuando "va demasiado por el agujero del conejo" y se olvida de verificar si el proceso está completo.

No me molestaré en dar una sugerencia sobre cómo hacer esto, ya que variará según el sistema operativo, el método de compilación y otros factores. Simplemente buscaría en Google algo como "hacer sonido y aparecer en (insertar sistema operativo aquí) cuando se complete el comando" o algo por el estilo.

Actualización: como han señalado algunos de los comentarios, puede haber formas de hacer esto en ciertos programas con GUI, no solo desde la línea de comandos. Como antes, no me molestaré en dar sugerencias aquí porque variará ampliamente según el programa que sea y el tiempo que tarde.

Mi respuesta depende del compilador, pero prueba esto:

Si el compilador le permite ver el código y se está compilando en segundo plano, entonces puede realizar su propia versión de RDD . Mientras el compilador está haciendo su trabajo, simplemente revise el código que acaba de escribir, compílelo en su cabeza, revíselo e intente encontrar cualquier error.

Vas a:

1. No distraerse y perder el foco.
2. Si hay algún error, no te llevará ni dos minutos arreglarlo y compilarlo de nuevo, pero mucho menos.

Por ejemplo, intercambiar dos identificaciones (mal documentadas).

He visto este problema en muchos programas que usan Into Stringpara cada ID individual; en este caso, es fácil pasar accidentalmente una identificación en lugar de otra y no notarlo... durante mucho tiempo.

Si puede pasar una identificación de pollo a la máquina de bebidas, su código tiene un problema (*).

El truco, entonces, es etiquetar las identificaciones. Dado que está hablando de largos tiempos de compilación, asumo que tiene un lenguaje tipificado estáticamente a su disposición, en cuyo caso debe aprovechar dichos tipos. ChickenIdNo es lo mismo A que DrinkIdA. DrinkIdNo es lo mismo A que FuelIdA.

Hágalos de diferentes tipos, y el compilador felizmente le señalará sus errores, lo que acelerará el ciclo Arreglar-Compilar-Prueba (cortando el paso de Prueba e interrumpiendo el de Compilar).

Esta es la versión estáticamente tipada del principio Fail Fast : no hay nada más rápido que tener el compilador (o incluso IDE si compila en segundo plano) señalándote los errores.

Como beneficio adicional, incluso puede introducir alguna validación en el mismo sistema. En mi parte del mundo, pocas identificaciones son negativas para ejemplos... o si eres una String, una identificación de 2 KB es sorprendente, por decir lo menos.

(*) A menos que beber sangre de pollo sea una práctica habitual en tu casa, qué sé yo...

La forma obvia de mitigar esto es dejar de cometer numerosos errores pequeños en primer lugar. Aquí es donde empezaría de todos modos.

Si el compilador tarda 30 segundos, entonces el compilador tarda 30 segundos. Todos cometemos errores, pero 15 veces por hora sería una bandera para mí para tener una metodología de verificación de errores más sólida.

Probablemente hay tantas formas de hacer esto como programación de personas. Lo que funcione para ti. Solucione el problema en su origen.

No soy un programador, así que necesito hacer un poco de juego para que las cosas funcionen a veces. La forma en que me mantengo productivo es mediante la multitarea, cuando no se puede trabajar en una cosa, trabajo en otra.

A menudo me encuentro presionando el botón de compilación y esperando unos 30 segundos o distrayéndome. Después de esos 30 segundos, vuelvo al trabajo, solo para descubrir que cometí un pequeño error y tengo que presionar compilar nuevamente en dos minutos.

Esperar 30 segundos una vez no es demasiado terrible, pero tener que hacerlo unas 15 veces por hora es tedioso.

Si tiene que recompilar 15 veces por hora porque cometió muchos errores pequeños, entonces claramente la distracción no es su problema, simplemente no está siendo lo suficientemente cuidadoso.

Y si está cometiendo pequeños errores que el compilador detecta, probablemente sea una señal de que también está cometiendo errores lógicos que no detecta.

Haga un esfuerzo por ser más consciente de su código antes de compilar.

Míralo, escribe algunos comentarios, míralo de nuevo. Luego compila.

Si te encuentras cometiendo el mismo tipo de pequeño error repetidamente, entonces quizás necesites dedicar más tiempo a entender tu lenguaje de programación. Una pequeña inversión en aprendizaje puede dar sus frutos a largo plazo.

Invierte el tiempo en ti mismo.

10 segundos gratis: Haz flexiones.
60 segundos gratis: Explore las preguntas de la red activa de Stack Exchange.
120 segundos gratis: Levántate y bebe un poco de agua.

Acabo de levantarme de hacer 20 flexiones mientras esperaba que un compañero de trabajo me respondiera en Slack. Cada vez que veo que tengo que10 < seconds < 120 esperar por algo, uso el tiempo para mejorar . Desde que comencé a hacer esto hace unas semanas, me siento más saludable, con más energía y menos cansada. Veo que mi productividad se ha disparado. Y me siento genial.

Sea más cuidadoso/Obtenga un mejor software

¿El problema real es que tiene que esperar a que finalice la compilación para saber si cometió un error, o que está dejando pasar suficientes errores pequeños que el tiempo de compilación muy corto (30 segundos) se convirtió en un problema?

No todos los problemas serán inmediatamente obvios; es por eso que programar por accidente es una idea horrible, y suena como lo que estás haciendo.

Su edición sugiere que está haciendo esto porque el software que está utilizando carece de documentación. Eso es un problema con el software y debe solucionarse. La documentación no es un buen extra, es una funcionalidad central. Si ha pasado suficiente tiempo adivinando sobre la API para hacer esta pregunta, probablemente sea el momento de discutir si ese software se ha convertido en una responsabilidad.

Usa el tiempo para pequeñas tareas puntuales

30 segundos parecen la cantidad perfecta de tiempo para hacer varias tareas pequeñas, que probablemente no te distraigan del todo. Los mejores ejemplos que se me ocurren son reproducir/cambiar una pista de música y consultar tu correo electrónico oficial. Si bien el segundo puede distraerlo, eso podría no ser algo malo inherentemente.

Tarea múltiple

Como decía mi comentario sobre la pregunta, estoy acostumbrado a compilaciones que tardan mucho más de 30 segundos. Si sus compilaciones comienzan a tomar más tiempo, es posible que desee asegurarse de tener siempre una segunda tarea a la que cambiar durante ellas.

Intento tener una tarea A y una tarea B: la tarea B no tiene nada que ver con los programas compilados, en los que puedo trabajar mientras la tarea A está construyendo y absorbiendo casi todo mi disco IO.

Implemente un servidor de integración/compilación continua y pruebas automatizadas.

Una vez que realice una confirmación, su servidor de compilación debería notarlo e iniciar una compilación automatizada. Esto lo libera inmediatamente para continuar trabajando.

Cuando finalice la compilación, su servidor debería ejecutar algunas pruebas automatizadas para detectar problemas comunes como los que describió (columnas mixtas, etc.). El servidor debe enviarle un correo electrónico si encuentra algún error de compilación y/o prueba.

Los beneficios de este flujo de trabajo es que nunca se pierde de vista. Continúa trabajando en su tarea actual y recibe comentarios de forma asincrónica sobre la compilación. Esto le permite completar un pensamiento y luego regresar para corregir los errores, no rebotar constantemente de un lado a otro, lo que provoca muchos cambios de contexto.

(Esto es en respuesta a la edición de la pregunta original que indica que los errores en cuestión no son errores de compilación, sino aquellos que solo detecta una vez que el programa se está ejecutando).

El tiempo dedicado a problemas de comportamiento o tiempo de ejecución se puede reducir o eliminar drásticamente escribiendo pruebas unitarias. No solo ahorrará tiempo al no tener que ejecutar manualmente los mismos pasos después de cada iteración (deje que la máquina haga el trabajo secundario por usted), sino que el acto de escribir código para asegurarse de que puede probarlo en primer lugar lo ayudará a razonar. mejore su código y lo obligue a pensar en el flujo de datos y considerar los casos extremos.

Dado que los errores aquí no son una codificación deficiente sino una documentación deficiente, ¿es posible (1) capturar muchos ID en una ejecución de compilación, en lugar de corregirlos individualmente, entonces puede trabajar de manera más productiva dado su sistema de compilación o (2 ) mueva las ID con las que tiene un problema a un archivo de texto que se pueda leer en tiempo de ejecución. Luego compilará bien y luego pasará su tiempo en un ciclo de ejecución, edición y ejecución, que puede ser más rápido en su caso.

Mejor hardware

Antes de cambiar nada , ¿has intentado lanzar más/mejor hardware al problema? Tener una estación de trabajo actualizada no es solo algo agradable, sino que en realidad le ahorra dinero a la empresa. Cada vez que te distraes, la empresa pierde dinero (por el tiempo que dedicas a concentrarte de nuevo).

Mejor proceso de construcción

Si más/mejor hardware no resolvió el problema, analice la racionalización del proceso de compilación para que sea más rápido o incluso cambie la cadena de herramientas por una más rápida.

Mejor tú mismo

La razón por la que sugiero ambos enfoques primero es que esto reducirá el tiempo de distracción para todos los desarrolladores de su empresa, en lugar de solo para usted. Si ninguno de estos enfoques hace que el problema desaparezca, entonces, de hecho, solo queda una variable y esa es usted.

Cuando estoy trabajando en un problema, planifico cómo resolver algo en varios pasos. Un ejemplo sería implementar un botón de inicio de sesión. Este es un proceso de múltiples pasos.

- Find the appropriate button icon and place it in the index.html file.
- Make the button call something on the backend, usually an API
- Make the API call the appropriate service.
- Let the service call the appropriate DataAccess methods
- Create tests for valid and invalid logins (backend)
- Create tests for valid and invalid logins (integration)
- Add these tests to automated test repo
- Commit code
- proceed to next task

Tenga en cuenta que todas las tareas están en un orden lógico (al menos para mí), pero no son dependientes en el sentido de que el cambio en el código ocurriría en diferentes lugares. Esto me permite planificar mi próxima tarea mientras mi tarea actual está compilando y/o ejecutando pruebas.

Sin embargo, este enfoque exige que su capacidad para cambiar de contexto entre dos tareas esté a la altura. Si no es así, entonces este enfoque no es adecuado para usted. Otros enfoques (mencionados anteriormente) como estiramientos, ejercicios con los dedos también podrían funcionar.