it-swarm-es.com

¿Cómo se maneja el código intencionalmente incorrecto?

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

  • Tener una construcción inútil que hace perder 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 solicite.
  • Proporcionar documentación intencionalmente engañosa, incorrecta o inexistente para generar costosas solicitudes de soporte.
  • Generando errores fácilmente, o peor aún, generando a pesar de que todo funcionó bien, bloqueando la aplicación por lo que se requiere una costosa llamada de soporte para desbloquearla.

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 lidiar con tales construcciones? ¿Ignora el problema o simplemente elimina el código infractor? ¿Notificar a su gerente o hablar con la persona que presentó la "función"?

21
mafu

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

Intencionalmente el código 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 resolver ese problema. Esto significa, más a menudo que no, política de oficina, y esa rara vez es una situación agradable para nadie.

Cómo 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 incorrecto— y luego corregir las deficiencias obvias. Si es razonablemente posible, escriba pruebas que indiquen que el código incorrecto fallará. Verificar 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 intenciones, 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 las deficiencias obvias te da el 80% de los resultados con el 20% del esfuerzo, y ese tipo de fruta madura rara vez vale la pena ignorarla. Pero lo que es más importante, si no aborda la razón subyacente (política), es probable que se escriba un código incorrecto intencionalmente y cause más problemas, y posiblemente impida el envío.

7
Roger Pate

Nunca (en 20 años) me he encontrado con un código intencionalmente incorrecto, pero los ejemplos que citas me parecen (al menos a mí, pero a IANAL) ser intentos de defraudar a un empleador o un cliente, por lo que probablemente tengas un obligación de comunicárselo a su jefe.

28
gkrogers

Depende de la cultura de la empresa. La mayoría de las veces, simplemente no es tu trabajo arreglar y limpiar todo el código incorrecto.

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 tu código y hacerlo más limpio y, por tercera vez, será realmente 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 malos por ahí, y simplemente tratar de arreglarlos todos a medida que los encuentra, a expensas del proyecto/tarea actual, puede que simplemente no valga la pena si el producto "está funcionando". Con demasiada frecuencia, todos somos programadores de cinta adhesiva.

Vea también la publicación de Joel Spolsky: El programador de cinta adhesiva

11
spong

¡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 lo empujaran desde arriba, probablemente empezaría a buscar un nuevo trabajo.

4
Zachary K

Esa actitud es síntoma de algo peor.

  • ¿La dirección está fomentando la competencia de los desarrolladores?

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

  • ¿Las tareas las asigna alguien más que el propio equipo?

  • ...

En cualquier caso, eliminar el código infractor no es suficiente. Quejarse con su entrenador 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é haciéndole muchas preguntas sin juzgarla. Todo el equipo tiene que hacerlo sin agresividad.

En la mayoría de los casos, ese comportamiento constructivo pone de relieve el problema real (el peor), y luego puedes trabajar en él.

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

4
user2567

¿Cómo se debe lidiar con tales construcciones? ¿Ignora el problema o simplemente elimina el código infractor? ¿Notificar a su gerente o hablar con la persona que presentó la "función"?

Dependiendo del contexto, cualquiera de ellos podría ser el más apropiado. Otras posibilidades incluyen, pedir 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 el puesto que usted está describiendo preste mucha atención a nuestros consejos por valor de 2 centavos.

Si esta es una situación real de la que está hablando, podría valer la pena tener una palabra tranquila con s gerente, pidiéndoles consejo sobre lo que debe hacer. Si es posible, intente entablar una conversación sobre lo que sted puede/debe hacer, no sobre señalar con el dedo. Si es posible, no nombre nombres. Es muy probable que su gerente ya tenga una idea del problema.

Pero la otra cara es que podrías estar exagerando esto. Piense detenidamente en eso antes de hacer nada. Piensa en las consecuencias, incluida la posibilidad de que cualquier paso que tomes pueda ser contraproducente ...

2
Stephen C