En programación, la técnica Duck es una técnica mediante la cual coloca una supervisión obvia y fácil en su código con la esperanza de que llame la atención durante la revisión y mitigue los cambios de diseño grandes que consumen mucho tiempo.
Había un equipo en mi empresa bien conocido por ser muy exigente en el momento de la revisión; Si usáramos Lib A, querrían Lib B. Pero si hubiéramos usado Lib B, querrían Lib A. No están contentos con este patrón de diseño y quieren ver uno diferente. Pero juro que si hubiéramos usado originalmente el patrón que sugirieron, habrían querido el otro. Era como si tuvieran que agregar algunoscomentario para demostrar valor. Estos grandes cambios eran problemáticos porque podían convertir una tarea de 1 hora en varias horas, prolongando el transcurso de los días y bloqueando el progreso. Y sé lo que estás pensando: ¿por qué no discutir el cambio con ese equipo de antemano? Lo hicimos. Tendríamos reuniones para presentar el cambio, explicar cómo el diseño mantiene la compatibilidad con versiones anteriores y asegurarnos de que se sintieran escuchados, tuvieran aportes y estuvieran a bordo. No importaba. Una vez que llegó la revisión del código, fue como si todo lo acordado se hubiera olvidado.
En un momento, un compañero de trabajo y yo tuvimos que hacer un cambio en una biblioteca que usábamos y que era de su propiedad para que pudiéramos usar la modificación en nuestro programa. Fue un pequeño cambio, pero suspiramos, nos agachamos y nos pusimos manos a la obra, preparándonos para la revisión del código. Estábamos programando en pareja el cambio y dándole una revisión rápida antes de enviarlo para la revisión del código. Conociendo la tendencia de este otro equipo a ser quisquilloso, tuve una idea:
Compañero de equipo: ¿Deberíamos reemplazar esto aquí con la sintaxis abreviada que introdujo la versión más reciente del lenguaje?
Yo: Buena idea... en realidad, déjalo por ahora.
Hubo algunos otros casos. Nada crítico como dejar un error, pero cosas como dejar la sintaxis que sabíamos que al otro equipo no le gustaba, dejando espacio para extraer métodos o cambiar el nombre de las variables. Funcionó maravillosamente. Comentaron sobre cada pato, respondimos con "¡Gracias! ¡Arreglando ahora!" y eso fue eso. La revisión del código terminó en unos 10 minutos y pudimos continuar sin que nos bloquearan.
Pero esto me hizo pensar, ¿hay algún problema ético en torno a esto? Particularmente no me gusta hacerlo y no lo hago para ningún otro equipo. Pero en este caso pudimos convertir una posible revisión de código de ida y vuelta de 2 horas en 10 minutos. Una victoria en mi libro. Tengo curiosidad por saber qué piensan los demás o si tienen soluciones alternativas para lidiar con equipos difíciles.
Edite para mayor claridad: esta pregunta sigue surgiendo, así que quería abordarla aquí.
Si el equipo está perdiendo el tiempo de todos, ¿por qué no confrontarlos, presionarlos o hablar con la gerencia?
Primero seguimos todos los canales habituales/oficiales. No tuvieron la última palabra en la revisión del código (aunque no obtener su aceptación habría sido una pérdida política para mí) y cualquier cosa que fuera completamente tonta o peligrosa no la acomodaríamos, pero a veces acceder a la solicitud ahorraría más. tiempo a largo plazo. Felizmente cambiaría cosas pequeñas como "espacios vs tabulación" o "colocación de llaves". Rechazaría las cosas más grandes y solicitaría una razón por la que valiera la pena dedicar tiempo a hacer el cambio. A veces funcionaba, a veces no. Otros y yo nos habíamos acercado a ellos individualmente, ya sea en el trabajo, en el almuerzo o con unas cervezas, diciendo que estos cambios de diseño de revisión de código eran perjudiciales para el progreso y un dolor para trabajar. Informé su comportamiento como problemático para la gerencia y otros también pueden haberlo hecho.
Idealmente, se les diría que su comportamiento es inaceptable, verán el error de sus formas y cambiarán. Pero los humanos no son computadoras y realmente no tienen que hacer nada de la manera en que yo o cualquier otra persona querría que se hiciera, independientemente de cuánto tiempo y dinero de la empresa se desperdiciara. Cualquier crítica podría contrarrestarse con "No estamos perdiendo el tiempo, nos estamos asegurando de que el código se haga de la manera correcta. Eso ciertamente vale la pena un poco más de tiempo por adelantado, ¿no es así?" Desafortunadamente, no es realmente blanco y negro y, al final, como mencioné más adelante, decidí que esta no era una colina en la que quería morir. Especialmente porque mis interacciones directas con este equipo eran poco frecuentes.
Es difícil de explicar además de describirlo como "quisquillosidad por el bien de la quisquillosidad". Por ejemplo, intentamos automatizar cosas estilísticas ya que es una tarea para el editor, pero generarían reglas intrincadas que el editor simplemente no podría manejar de manera consistente. No creo que estuvieran siendo maliciosos. Cosas como, tal vez una semana les encantaría el Patrón A. Sabiendo esto, me aseguraría de usar el Patrón A en su código cuando sea apropiado. Pero en algún momento intermedio, leyeron en alguna parte que el patrón A es malo y que todos deberían usar el patrón B. Es posible que esto no se mencione en las discusiones preliminares de diseño y no pensaría en preguntar porque pensé que les gustaba el patrón A, pero surgiría en el momento de la revisión. Tenían un pequeño y extraño feudo y lo gobernaban con puño de hierro, pero habían estado en la empresa durante mucho tiempo y la gerencia los quería. En última instancia, eran un buen grupo de personas un poco extrañas. Es solo una de esas cosas extrañas del lugar de trabajo que probablemente suene loco a menos que te hayas encontrado con algo similar.
Si alguien sugiere un cambio (que requiere mucho tiempo) (o muchos cambios pequeños) a algo equivalente o peor sin ninguna justificación, probablemente debería rechazarlo en lugar de simplemente hacer el cambio. La revisión no es (o al menos no debería ser) un proceso unidireccional en el que solo tiene que hacer todo lo que dice el revisor sin cuestionarlo, incluso cuando tiene un buen argumento para no hacerlo. Y, quién sabe, tal vez tengan un argumento mejor de lo que piensas y discutir el cambio lleve a que uno o ambos aprendan algo.
Si no solo quiere estar en desacuerdo con ellos (o eso no funciona), siempre puede probar el enfoque de "gracias, pero no gracias":
[De acuerdo con ellos] Podrías tener un buen punto allí. [Señale el problema] Aunque parece que podría ser un cambio que llevaría bastante tiempo, por lo que preferimos mantener las cosas como están por el momento, [Dé razones con las que no pueden discutir] ya que lo que hemos obras ya concluidas y esto nos permite centrarnos en cuestiones más apremiantes. [Terminar con una nota alta] ¡Definitivamente lo anotaremos y lo tendremos en cuenta en el futuro!
Por supuesto, esto no necesariamente los llevaría a dar su aprobación.
Si solo se trata de algunos cambios muy pequeños , es posible que no valga la pena el tiempo o el esfuerzo de retroceder y probablemente debería simplemente hacer los cambios (a menos que obtenga un montón de estos con cada revisión, y el tiempo necesario para resolverlos se está acumulando rápidamente) ).
Si alguien parece obligado a dar al menos alguna retroalimentación (por inútil o dañina que sea) por cada cambio, debe discutir esto primero con ellos y luego con la gerencia, porque deberían dejar de hacerlo. Tengo el deseo de dar visibilidad a lo que estás haciendo (porque una simple revisión de "todo bien" no le dice a nadie si le dedicaste unos segundos o unas horas), pero lo haces notando regularmente cosas sutiles pero problemas sustanciales, no perdiendo el tiempo de todos con comentarios sin sentido.
El daño en la "técnica del pato" es que ahora eres tú quien desperdicia el tiempo de los demás, lo que podría tener una variedad de consecuencias, como que se pierdan otros problemas más importantes en tu código, resten tiempo a su trabajo o tengan este ser descubierto y ser reprendido.
Si ya probó todo lo anterior hasta la saciedad , probablemente se haya quedado sin opciones y es posible que desee hacer lo que funcione para su proceso de revisión irreparable.
[Give reasons they can't argue with]es el quid del problema; Podría encontrar infinitas razones por las que el código debe cambiarse si quisiera. Y debo señalar que esto fue algo de una sola vez. Se sentía como un poder demasiado grande y terrible para ejercer. Después de dejar esa empresa no me he encontrado con nadie como ellos. Pero su respuesta me ha dado una gran nueva perspectiva sobre las trampas de esta "técnica".El único problema no es ético sino práctico: si el otro equipo SÍ alguna vez está en posición de contribuir con algo útil, habrás reducido la probabilidad de que te enteres. De lo contrario, parece totalmente justificado el uso de cualquier método para mantener el proceso de revisión del código en marcha.
¿Ese equipo tiene un historial establecido de proporcionar información valiosa junto con sus objeciones capciosas? Creo que el punto es que, incluso si lo hicieran, cualquier aporte útil de ellos no vale la pena atravesar montones de marrón pegajoso para llegar.
Una vez que llegó la revisión del código, fue como si todo lo acordado se hubiera olvidado.
Esto me hace pensar que tienen una gran oportunidad de inyectar cualquier preocupación genuina en el proceso de diseño, lejos de la revisión del código. Esto también significa que es su comportamiento lo que lo ha llevado a manipular el proceso de revisión de código.
No veo motivos éticos para censurar su uso de la técnica del pato en este caso. Al contrario, lo felicito por la corrección de su solución.
Parece que la forma en que su empresa realiza revisiones de código, y especialmente la forma en que otro grupo realiza las revisiones, es una pérdida de tiempo completamente ridícula. Ridículo, no ridículo, porque es tan ridículo que ni siquiera vale la pena escribirlo bien.
Si yo fuera el gerente de los dos grupos, estaría muy, muy enojado si descubro lo que está pasando. No hay nada de malo en lo que has estado haciendo, pero no deberías tener que hacerlo. Hablaría con su gerente, le diría que haga lo que haga, van a querer exactamente lo contrario, y que esto está creando un trabajo totalmente innecesario. Denuncie el subterfugio que ha estado usando, que también es una pérdida de tiempo, solo que menos. Su empresa está pagando por todo el trabajo innecesario. Podrías estar haciendo cosas útiles en ese momento. Y el otro grupo se dará cuenta de lo que estás haciendo y eso empeorará las cosas.
Su gerente debe saber y su gerente debe tomar medidas.
El trabajo no es la escuela secundaria.
Digamos que uno de sus colegas sugiere con frecuencia cambios pequeños e inútiles que son cambios por cambiar y que están ralentizando el progreso.
Lo que dices es:
Mmm. Steve, con frecuencia estás sugiriendo cambios pequeños e inútiles que son cambios por cambiar y que están ralentizando el progreso.
Para repetir, el trabajo no es la escuela secundaria .
¡Abróchese el cinturón y haga el trabajo!
Work is not high schoolDesafortunadamente, puede parecerse mucho más a la escuela secundaria de lo que nos gustaría. En particular, las jerarquías sociales tienen poder real. Especialmente si Steve es más antiguo que tú, decirle que sus sugerencias no son útiles puede resultar en una discusión y/o que él se extienda sobre por qué estás equivocado y es importante seguir sus sugerencias.Encuentro que su solución es terriblemente poco ética. Eventualmente resultará en un error importante porque distrajiste al equipo de CR con tu pato. Si tuviera un empleado que descubrí que estaba haciendo algo así, lo despedirían tan rápido que su cabeza daría vueltas.
Ahora reconozco que tienes una mala situación aquí. Básicamente, es mejor que no estés revisando el código. El primer paso para arreglarlo es establecer estándares por escrito que todos deben seguir y luego seguirlos. Si el equipo de RC se opone a que algo se haga de la manera que describe el estándar, entonces señale ese estándar y siga adelante e ignore esa parte de la entrada. Si tienen razón en algo, añádelo al estándar.
El siguiente paso es definir mejor el proceso de CR. Lo que es apropiado y lo que debes cambiar vicio lo que simplemente tienes que comentar e ignorar. Si el equipo y el CR no están de acuerdo, entonces envíe todo el lío a la gerencia para adjudicar como parte de su proceso escrito. A medida que vean y sientan el dolor de los comentarios innecesarios y el tiempo que tienen que dedicar a lidiar con ellos, es posible que se tomen más en serio la idea de alinear a este otro equipo. Cuanto más tiempo de gestión se desperdicie con esto, más entenderán. Tómese el tiempo para escribir su justificación para ignorar la solicitud de cambio, incluido el hecho de que la última vez querían A, así que esta vez les dio un patrón y ahora eso no es lo suficientemente bueno. No se preocupe por los retrasos en los proyectos al hacer estos escritos. La gerencia ha acordado que los retrasos son menos importantes que el CR, incluso el CR sin sentido en este punto. Desea mostrarles a través de su propia experiencia de tener que lidiar con los cambios de CR por qué esa fue la elección incorrecta.Recuerde que el problema aquí no es que el otro equipo haga el CR. Entonces el problema es la gestión incompetente. Su mejor opción es hacer que esto sea lo suficientemente doloroso para la gerencia como para que finalmente se muevan y hagan algo al respecto.
A continuación, ¿puede encontrar formas de asignar a otras personas para que hagan el CR en primer lugar? Esto resuelve completamente el problema.
Lilienthal
jose johnson
komodosp
jose johnson
Myles
phil m
jose johnson