¿Cómo manejas el código intencionalmente malo?

Hay muchas historias sobre códigos intencionalmente malos, no solo en TheDailyWTF sino también en SO. Los casos típicos incluyen:

• Tener una construcción inútil que desperdicia el tiempo (por ejemplo, un bucle vacío que cuenta con un valor enorme) para que los programadores puedan "acelerar" fácilmente la aplicación eliminándola cuando se les encomiende.
• Proporcionar documentación intencionalmente engañosa, errónea o nula para generar costosas solicitudes de soporte.
• Generando fácilmente errores, o peor, generando aunque todo funcionó bien, bloqueando la aplicación por lo que se requiere una costosa llamada de soporte para desbloquear.

Estos puntos muestran una actitud más o menos maliciosa (aunque a veces por accidente), especialmente el primer punto ocurre con bastante frecuencia.

¿Cómo se debe tratar con tales construcciones? ¿Ignorar el problema o simplemente eliminar el código ofensivo? ¿Notificar a su gerente o hablar con la persona que introdujo la "función"?

La mayoría de los códigos malos se deben a una falta de comprensión y la solución es la educación.

El código intencionalmente incorrecto es completamente diferente, debido a algo completamente ajeno a la experiencia del codificador o al resto del proyecto. Como tal, debe averiguar por qué están saboteando el código a propósito y abordar ese problema. Esto significa, más a menudo que no, políticas de oficina, y esa rara vez es una situación agradable para alguien.

La forma en que manejaría el lado de la política depende de muchas circunstancias (no mencionadas anteriormente). La forma en que manejaría el código es primero asegurarme de que no soy el único malentendido, que realmente es un código malo, y luego corregir las deficiencias obvias. Si es razonablemente posible, escriba pruebas de que el código incorrecto fallará. Comprobar dos veces que he entendido correctamente significaría hablar con la persona que escribió el código. Eso debe hacerse de una manera muy amable y educada, sin asumir la intención, y puede ayudar a encontrar la razón subyacente (política) necesaria más adelante.

El envío es más importante que la perfección de la torre de marfil, pero hay dos puntos que vale la pena abordar. Arreglar deficiencias obvias te da el 80% de los resultados con el 20% del esfuerzo, y rara vez vale la pena ignorar ese tipo de fruta de bajo perfil. Pero lo que es más importante, si no aborda la razón subyacente (política), es probable que se escriba un código intencionalmente más malo y cause más problemas, y posiblemente evite el envío.

Nunca (en 20 años) encontré un código intencionalmente malo, pero los ejemplos que usted cita parecen (al menos para mí, pero IANAL) son intentos de defraudar a un empleador o un cliente, por lo que probablemente tenga un legal obligación de señalarlo a su gerente.

Depende de la cultura de la empresa. La mayoría de las veces, simplemente no es su trabajo arreglar y limpiar todos los códigos incorrectos.

De Coders at Work , el pensamiento de Jamie Zawinski sobre la sobreingeniería, que también se puede aplicar en esta situación:

Al final del día, ¡envía la maldita cosa! Es genial reescribir su código y hacerlo más limpio y, por tercera vez, en realidad será bonito. Pero ese no es el punto: no estás aquí para escribir código; Estás aquí para enviar productos.

Hay muchos codificadores y códigos defectuosos, y simplemente tratar de corregirlos a medida que los encuentra, a expensas del proyecto / tarea actual, simplemente puede no valer la pena si el producto "está funcionando". Con demasiada frecuencia, todos somos programadores de cinta adhesiva.

Ver también la publicación de Joel Spolsky: The Duct Tape Programmer

Esa actitud es el síntoma de algo peor.

• ¿La gerencia fomenta la competencia de los desarrolladores?

• ¿Dónde está el espíritu de equipo?

• ¿Las tareas son asignadas por alguien más que el propio equipo?

• ...

En cualquier caso, eliminar el código ofensivo no es suficiente. Quejarse con su gerente ciertamente no ayudará a mejorar el espíritu de equipo.

Trataría de hablar con la persona directamente y trataría de entender por qué haciendo muchas preguntas sin juzgarlo. Todo el equipo tiene que hacerlo sin agresividad.

En la mayoría de los casos, ese comportamiento constructivo pone el problema real (el peor) bajo luz, y luego puede trabajar en ello.

Si realmente no funciona. Eliminar a ese desarrollador del equipo.

¡Si pensara que fue intencional, probablemente despediría al tipo! Si es el resultado de que alguien no sea un programador lo suficientemente bueno, trabajaría en sus habilidades. Si fuera empujado desde arriba, probablemente comenzaría a buscar un nuevo trabajo.

¿Cómo se debe tratar con tales construcciones? ¿Ignorar el problema o simplemente eliminar el código ofensivo? ¿Notificar a su gerente o hablar con la persona que introdujo la "función"?

Dependiendo del contexto, cualquiera de esos podría ser el más apropiado. Otras posibilidades incluyen, solicitar la transferencia a un proyecto diferente, conseguir un nuevo trabajo y varios actos de moralidad y / o legalidad cuestionables.

Sin embargo, dado que no conocemos los hechos reales y las personas reales involucradas, no hay forma de que alguien en la posición que usted describe deba prestar mucha atención a nuestros consejos / valor de 2 centavos.

Si esta es una situación real de la que está hablando, puede valer la pena hablar en voz baja con su gerente y pedirle consejo sobre lo que debe hacer. Si es posible, trate de conversar sobre lo que puede / debe hacer, no sobre señalar con el dedo. Si es posible, no nombre los nombres. Existe una buena posibilidad de que su gerente ya tenga una idea del problema.

Pero el otro lado es que puede estar soplando esto fuera de proporción. Piensa mucho sobre eso antes de hacer algo. Piense en las consecuencias, incluida la posibilidad de que cualquier medida que tome pueda ser contraproducente ... gravemente.