¿Escribe un código incorrecto cuando está bajo presión? [cerrado]

14

Cuando estás bajo presión, se acerca la fecha límite, y un gerente te está echando el cuello. ¿Estás empezando a escribir un código incorrecto? ¿Se hacen a un lado el TDD y las mejores prácticas para poder hacer las cosas? ¿Qué haces en situaciones como esa? ¿Cuáles fueron tus experiencias?

    
pregunta ysolik 19.10.2010 - 17:28
fuente

8 respuestas

27

En una palabra, sí. Cualquiera que te diga lo contrario, probablemente esté, en el mejor de los casos, equivocado.

Sin embargo, la clave es aprovechar su experiencia para escribir código que sea menos malo. Resista la tentación de poner algo para que "simplemente funcione" si es posible, porque no lo hará. Aún debe seguir algún tipo de proceso (ya sea el suyo propio, el de su compañía o una combinación de estos).

La experiencia me dice que es mucho mejor ( jadear ) pasar el horario un par de días para evitar reparaciones de una semana, especialmente cuando "bajo presión" significa un lanzamiento acelerado a producción. Si se apresura a lanzar el código, es probable que los evaluadores también tengan prisa para llevarlo a cabo.

    
respondido por el Wonko the Sane 19.10.2010 - 17:36
fuente
16

Si el equipo está en una situación crítica, algo se hizo mal.

La falta de fechas límite es un signo de planificación y estimación deficientes. Reconozca que el plazo se perderá y resuelva el problema. A veces no tiene control sobre la planificación de la estimación o . Identifique quién lo hace y asegúrese de que sepan que esto se hizo por error.

En una situación en la que no se puede mover la fecha límite, se pueden extraer las bebidas altamente cafeinadas y apresurarse. Identifica cualquier cosa que puedas sacrificar y recórtala. Toma lo que queda e implementalo lo más rápido posible. Esto causará problemas como inestabilidad, errores extraños, prácticas de codificación ineficientes, correcciones de curita y todo tipo de otros horrores. No es necesariamente el código malo , pero no es ideal .

  

Una solución buena al 50% que las personas   En realidad han resuelto más problemas y   sobrevive más de una solución al 99%   que nadie tiene porque está en tu   Laboratorio donde estás puliendo sin cesar   la maldita cosa El envío es un   característica .

De Joel en Software The Duct Tape Programmer .

El código ideal no se puede tratar con si se trata con . El código que no se ha tratado se acumulará y, a su vez, hará que los cambios adicionales sean más difíciles, si no imposibles. Puede llegar al punto en el que la aplicación se grabe de manera interdependiente, de manera que las adiciones solo pueden realizarlas los programadores más cuidadosos a un costo de tiempo exorbitante. Mientras que el envío es una característica, por lo que es mantenibilidad.

    
respondido por el Josh K 19.10.2010 - 17:38
fuente
6

Soy un gran fanático de la artesanía de software: escribir código limpio lo mejor que pueda, etc., pero a veces he tenido que apresurarme en momentos en que el tiempo es corto y se acerca el plazo. Realmente trato de no hacer esto lo mejor que puedo, pero a veces no puedes alejarte de ello.

Algunas personas dirán "Bueno, eso es vida, tienes que enviar" , pero realmente no estoy de acuerdo con esta actitud.

Al escribir código apresurado, puede terminar recibiendo el software a tiempo, pero ¿qué sucede cuando, durante los próximos días, termina recibiendo llamadas de soporte relacionadas con errores en el software (estos errores viven en la misma pieza de código que se apresuró a terminar). ¿O es que un cliente enojado lo llama y le pregunta por qué su módulo de informes ya no funciona, aunque prometió que estaría bien el día del lanzamiento?

Todo está muy bien diciendo "Tienes que enviar" , pero hay una diferencia entre parecer eficiente y parecer un trabajador descuidado.

Saludos. Jas.

    
respondido por el Jason Evans 19.10.2010 - 17:55
fuente
3

Sí. Pero siempre vuelve a atormentarme más tarde.

    
respondido por el Dima 19.10.2010 - 23:09
fuente
2

Cuando estoy en una situación de estrés, mi código está destinado a hacer el trabajo. Eso es. No me concentro en la eficiencia y otros temas, lo cual es malo, en mi opinión.

Aunque trabajaré en ello.

    
respondido por el ivorykoder 19.10.2010 - 18:19
fuente
1

No creo que personalmente escriba un código significativamente peor, pero sí entrego un producto peor.

Cuando nos enfrentamos a una fecha límite arbitraria e imposible, escatimamos en el proceso de desarrollo. Hacemos revisiones de código más superficiales (o las saltamos por completo). Examinamos menos, pasamos por alto las pruebas unitarias detalladas para las pruebas de integración de tipo de verificación al azar, luego intentamos contar la prueba de integración como una calificación formal. Tendemos a pasar por alto las anomalías durante las pruebas si no están directamente vinculadas a los criterios de aprobación y rechazo. Nos saltamos las actualizaciones de la documentación, no revisamos las notas de la versión, nos olvidamos de limpiar la lista de entregables de los archivos que ya no son necesarios.

El código fuente que escribes durante una crisis puede ser de alta calidad, pero es casi seguro que se enviará como parte de un producto de mala calidad.

    
respondido por el AShelly 19.10.2010 - 21:44
fuente
0

Depende.

¿Es la presión porque no hay forma de que todo se pueda hacer y porque se están agregando nuevas funciones importantes horas antes del lanzamiento?

¡Aparece un código incorrecto!

Pero si es porque el programa es realmente muy ajustado pero el plan general es sólido y solo tengo que trabajar mucho más duro de lo habitual y mantenerme continuamente enfocado mientras se ajustan algunas características. Mejor código que si el horario permite mucho tiempo. Incluso si eso significa que no obtengo todas las pruebas de unidad escritas, pero cubro las partes principales del código.

    
respondido por el ElGringoGrande 19.10.2010 - 18:05
fuente
0

Conozco a alguien que nunca escribe código mal bajo presión. También tiene algunos frijoles mágicos que podrían interesarte.

Todo el mundo escribe un código incorrecto a veces y las fechas límite que se avecinan son la razón habitual, el truco es evitar entrar en esa situación en primer lugar (y eso tampoco es fácil).

    
respondido por el FinnNk 19.10.2010 - 23:19
fuente

Lea otras preguntas en las etiquetas