¿Escribes código malo cuando estás bajo presión? [cerrado]

Cuando está bajo presión, se acerca la fecha límite y un gerente le está respirando en el cuello, ¿se encuentra comenzando a escribir un código incorrecto? ¿El TDD y las mejores prácticas pasan por alto para poder hacer las cosas? ¿Qué haces en situaciones como esa? ¿Cuáles fueron tus experiencias?

En una palabra, si. Cualquiera que le 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 "funcione" si es posible, porque no lo hará. Aún debe seguir algún tipo de proceso (ya sea el suyo o el de su empresa, o una combinación de ambos).

La experiencia me dice que es mucho mejor ( jadear ) pasar el programa un par de días para evitar reparaciones de una semana, especialmente cuando "bajo presión" significa un lanzamiento acelerado a la producción. Si se está apresurando a liberar el código, los probadores probablemente también tengan prisa por sellarlo.

Si el equipo está en apuros, entonces algo se hizo mal.

La falta de plazos es una señal de mala planificación y estimación. Reconozca que se perderá el plazo y resuelva el problema. A veces no tienes control sobre la planificación o la estimación. Identifique quién lo hace y asegúrese de que sepan que esto se hizo por error.

En una situación en la que la fecha límite no se puede mover, usted saca las bebidas altamente cafeinadas y se apresura. Identifique cualquier cosa que pueda sacrificar y recórtela. Tome lo que queda e impleméntelo lo más rápido posible. Esto causará problemas como inestabilidad, errores extraños, prácticas de codificación ineficientes, correcciones de curitas y todo tipo de otros horrores. No es necesariamente un código incorrecto , pero no es ideal .

Una solución del 50% que la gente realmente tiene resuelve más problemas y sobrevive más tiempo que una solución del 99% que nadie tiene porque está en su laboratorio donde está puliendo sin parar. El envío es una característica .

^{De Joel en el software The Duct Tape Programmer .}

No se puede tratar el código ideal si se trata . 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 que la aplicación se pega de forma tan interdependiente que las adiciones solo pueden ser realizadas por los programadores más cuidadosos a un costo de tiempo exorbitante. Si bien el envío es una característica, por lo que es mantenibilidad

Soy un gran admirador de la artesanía del software: escribir código limpio lo mejor que puedo, etc., pero a veces he tenido que apresurarme en momentos en que el tiempo es corto y se acerca una fecha límite. Realmente trato de no hacer esto lo mejor que puedo, pero a veces no puedes escapar de eso.

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

Al escribir un código apresurado, puede terminar sacando el software a tiempo, pero lo que 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 apresuró para terminar). ¿O recibe un cliente enojado que le pregunta por qué su módulo de informes ya no funciona, a pesar de que prometió que estaría bien el día del lanzamiento?

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

Si. Pero siempre vuelve a perseguirme más tarde.

Cuando estoy bajo 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 asuntos, lo cual es malo, en mi opinión.

Aunque trabajaré en eso.

No creo que personalmente escriba un código significativamente peor, pero 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 omitimos por completo). Probamos menos, omitimos las pruebas unitarias detalladas para las pruebas de integración de tipo de verificación puntual, 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 / rechazo. Nos saltamos las actualizaciones de documentación, no verificamos dos veces las notas de la versión, nos olvidamos de buscar en la lista de entregables los archivos que ya no son necesarios.

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

Depende

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

¡Código malo en camino!

Pero si es porque el cronograma es realmente muy apretado, pero el plan general es sólido y solo tengo que trabajar mucho más de lo habitual y mantenerme enfocado continuamente mientras modifico algunas características, escucho y listo ... Entonces produzco un código mucho mejor que si el horario permite toneladas de tiempo. Incluso si eso significa que no escribo todas las pruebas unitarias, sino que cubro las partes principales del código.

Conozco a alguien que nunca escribe mal código bajo presión. También tiene algunos frijoles mágicos que te pueden interesar.

Todo el mundo escribe un código incorrecto a veces y los plazos inminentes son la razón habitual, el truco es evitar entrar en esa situación en primer lugar (y eso tampoco es fácil).