Mi colega no entiende las cosas con las que trabaja. ¿Qué hacer? [cerrado]

13

Pasé 3 días depurando un error muy oscuro en una biblioteca hecha por mi colega, este error ocurre con poca frecuencia. Después de todo, descubrí que este error ocurre debido al acceso cruzado a un objeto sin ningún bloqueo. En realidad, este no es un primer error de este tipo, hubo errores similares antes. Simplemente ejecuta las pruebas de su unidad, y si algo falla, coloca un candado en alguna parte. Y si nada falla, ughm, entonces su código es perfecto. Parece que no tiene idea de enhebrar la seguridad. Estoy 100% seguro de que hay muchos errores similares que aún no han aparecido. Parece que PM no entiende cosas de subprocesos también.
El problema es que trabaja mucho más tiempo en la empresa que yo. De todos modos, no puedo decir "este tipo es incompetente en esta área", porque esto siempre te muestra como un "mal jugador de equipo", etc.

project-management tika
fuente
Que pais es este
Es una empresa internacional.
tika
2
Si realmente es un gran problema y está 100% seguro de que su colega está cometiendo un error, lo primero es señalarlo cortésmente de tal manera que no esté amenazado. La segunda cosa es, si su colega no escucha, es solo señalar los posibles daños en efectivo. Eso es lo que escuchan todos los gerentes, y con mucho cuidado. Tener un problema de subprocesos como el que describió es potencialmente muy dañino y, a menos que esté 100% seguro en sus declaraciones, continúe con ellas.
NB
Probablemente pertenece al sitio de Project Management SE.
Bernard
1
El sitio de Project Management SE no tiene una etiqueta "Multithreading", que esta pregunta debería tener.
RalphChapin

Respuestas:

13

Convencer al primer ministro de que para evitar tales errores, se debe mejorar el conocimiento del equipo sobre el enhebrado de cosas y decirles que está dispuesto a organizar algo como un taller o una presentación al respecto. No lo convierta en algo personal entre usted y su colega.

Doc Brown
fuente
Me temo que este tipo no será bienvenido, porque cree que es profesional en esta área (y puede enseñar a todos por sí mismo). Pero puedo intentarlo.
tika
Ah, sí, y un gran problema: el inglés no es mi lengua materna, no hablo muy bien.
tika
Si tanto su colega como el PM tienen conocimientos limitados sobre el enhebrado y la seguridad del enhebrado, entonces la capacitación es definitivamente el mejor enfoque. El problema no es la incompetencia de un tipo, sino la competencia del equipo.
boisvert
1
Un taller es algo donde todos ustedes pueden aportar sus conocimientos, y todos deben aprender algo de él. Si su colega cree que sabe algo sobre el enhebrado, quizás también pueda aprender algunas cosas de él.
Doc Brown
8

Escriba una prueba unitaria que muestre el error y pídale que lo arregle.


fuente
1
Él ya está al tanto de este error. Simplemente no puede encontrar la razón.
tika
¿No encontraste el motivo en la sesión de depuración de tres días? ¿O leo tu pregunta incorrectamente?
1
@scarfridge Depende de la plataforma. Para Java, puede usar instrumentación de código de bytes o programación orientada a Aspectos para insertar una espera exactamente donde está el problema (o usar JVMTI para controlar la ejecución). ¡Es posible hacerlo!
1
No es solo cuestión de secuencia. Muchos otros factores están implicados - que los núcleos de ejecutar código, cuando se produce GC y cómo se mueve objetos, cómo se propagan los cambios de la memoria caché de un núcleo a otro, etc.
tika
1
En realidad, es solo un conjunto de llamadas de método repetidas miles de millones de veces. Pero esto no importa mucho. La verdadera razón es el acceso a un objeto de diccionario desde 2 hilos sin bloqueo (es decir, sin barreras de memoria). El hilo A lo crea, el hilo B lo lee.
tika
4
  • El trabajo de un desarrollador senior es revisar su código y sugerir mejoras.
  • No está allí para verificar después de su trabajo, personalmente odiaría si alguien volviera a verificar todos mis cambios para ver si algo se rompió
  • Si él no acepta su consejo, entonces el trabajo de PM es solucionar el problema de comunicación.
  • El problema de subprocesos en una prueba unitaria me hace preguntarme si esta prueba es realmente una prueba unitaria, en lugar de una prueba de integración o componente.
CodeART
fuente
Ya entiendo tu idea. Obedece tu orden.
tika
2
¿Qué importa si una prueba que muestra un problema se llama "prueba unitaria" o "prueba de integración"? Toda la situación sigue siendo la misma.
Doc Brown
1
Mi preocupación es que su colega podría no saber la diferencia entre la unidad y la prueba de componentes, por lo tanto, es posible que se requiera capacitación adicional para abordar este problema.
CodeART
@CodeRush - ¿Supongo que no crees en la revisión por pares? ¿Qué haría falta para que usted realmente aprecie que alguien más estaba volviendo a verificar su código (en lugar de simplemente bloquearse en la producción)?
Tengo la idea, pero no la he visto funcionar de manera efectiva en mis trabajos anteriores. Creo que las revisiones de un desarrollador senior son un mejor mecanismo de retroalimentación.
CodeART el
-5

Creo que su empresa no debería estar usando subprocesos múltiples.

Después de hacer un proyecto multiproceso masivo, descubrí que dos técnicas eran críticas para hacer que las cosas funcionen. Primero , el código tenía que estar escrito correctamente. Todos los campos tenían que verificarse manualmente para asegurarse de que se declararan correctamente y que se sincronizaran correctamente donde se haga referencia. (Advertencia: estoy simplificando un poco las cosas aquí para que mi respuesta sea corta, o en cualquier caso, más corta). En segundo lugar , el código tuvo que probarse ejecutándolo en máquinas simples y multinúcleo, muchos minutos usando 100% de cada núcleo. (Y si solo usa el 2% de cada núcleo, como solía hacerlo para mí, también es un error).

Es posible que pueda administrar esto, pero su organización no puede. Incluso si entendieron el problema, que no lo hacen, no tienen la experiencia.

La mayoría de los idiomas proporcionan formas de evitar esto. Si tiene un lector de socket, que generalmente tiene su propio hilo, haga que obtenga la información en el hilo principal de la forma más rápida y sencilla posible. Mejor aún, busque las clases / funciones del sistema que manejarán la parte del hilo de la lectura por usted. Use una cola que ejecute "eventos" uno tras otro, como lo hacen la mayoría de las API de GUI. (Utilice la cola de eventos de la API GUI en sí misma). Si necesita un procesamiento paralelo, probablemente pueda encontrar algún tipo de "subproceso de trabajo" que le permita mantener datos / campos en un solo subproceso, manejando todas las transferencias por usted.

Haga hincapié en todos los peligros del subprocesamiento múltiple. (Historias de miedo: mi error favorito involucraba un par de líneas como:, lo int i = 5; i = i * i;que resultó en iun valor de 35. Una que vi mucho fue:if (thing != null) thing.reset(); lanzar una excepción de puntero nulo). Creo que su única esperanza es hacerles entender que son entrando en un mundo nuevo, nuevo y extraño, y que tal vez deberían dar un gran paso atrás.

No estoy muy seguro de cómo se debe manejar el subprocesamiento múltiple. Si el trabajo se puede dar a una persona, y todo lo que hacen se tira si fallan, está bien. Pero un equipo solo será tan fuerte como su miembro más débil, e incluso un buen programador tendrá problemas con el subprocesamiento múltiple completo. Espero que la gente del idioma encuentre la manera de hacerlo seguro. He visto algún software útil por ahí. Pero creo que es mejor evitar el subprocesamiento múltiple a menos que el tiempo de ejecución sea crítico y haya un buen programador o un equipo probado disponible.

RalphChapin
fuente
2
No tiene idea de qué compañía es o qué están haciendo, por lo que el comentario "Quizás pueda administrar esto, pero su organización no puede" es un poco infundado: por lo que sabe, tika podría funcionar en Microsoft . Quienquiera que sean, el multihilo puede ser la mejor manera de resolver su problema; Hay muchas situaciones en las que encaja. Y dejando todo eso a un lado, la pregunta no se trata de subprocesos múltiples, se trata de manejar a un colega que está causando problemas debido a la falta de experiencia.
anaximander
@anaximander: Multithreading produce errores que son muy difíciles de reproducir y muy difíciles de rastrear. Para producir un software MT utilizable y reparable, necesitará, como mínimo, tener programadores y administradores conscientes de los peligros. La organización de Tika claramente no podía manejar esto. He visto que las personas de pruebas / control de calidad obligan a los programadores a escribir código de sonido probando mucho y exigiendo soluciones para cada error. Eso no funciona con MT. Si el colega carece de habilidad, interés y motivación, trátelo manteniéndolo alejado de MT.
RalphChapin
@anaximander: Debes haber tenido mejores experiencias con Microsoft que las que he tenido. Aunque para ser justos, nunca he visto nada que parezca un error de lectura múltiple de ellos. ....Y gracias por el comentario.
RalphChapin
1
De todos modos, cuando la pregunta es "¿cómo manejo a un colega que carece de experiencia?", No creo que "su empresa está creando un software incorrecto" es una respuesta válida. En cualquier organización, no importa cuán vasto y bien informado, siempre habrá personas con lagunas en su conocimiento. Sin saber quién es la organización o qué está haciendo el software, no creo que pueda juzgar de manera confiable que la compañía no sabe lo que está haciendo, o que su problema puede resolverse sin múltiples subprocesos.
anaximandro