Mencioné que mi compilador me está dando errores en esas líneas, pero él parece creer que es un error con la configuración de mi computadora.

En este punto, debe detenerse por completo y asegurarse de que su computadora esté configurada exactamente como la suya.

Si el error continúa, solicite más orientación.

Mi pregunta es si debo o no volver a mencionarle esto y explicarle mi razonamiento.

No. Ya te han dicho cuál es el problema. Es hora de escuchar, arreglar su computadora y volver a las cosas que están dentro de su área de responsabilidad.

¿Es una buena idea seguir impulsando esto, especialmente dada mi situación actual?

Digamos que alguien que me reporta dijo que el software no compilaría. Después de investigar, descubro que no están usando las herramientas adecuadas, así que les digo que arreglen la máquina para que cumpla con los requisitos.

Si esa persona volviera a mí e insistiera en que el programa debe compilar usando el conjunto de herramientas incorrecto, entonces tendríamos una "buena" charla sobre cómo los programadores, de todas las personas, deberían entender cómo seguir instrucciones. Si sucediera una tercera vez, los despediría.

Recomiendo encarecidamente que, antes de volver a plantear este problema, arregle su computadora. Luego infórmese sobre por qué se han dirigido a este compilador/configuración específico. Hay bastantes razones para usar un compilador sobre otro: antes de que comprenda por qué se excluyeron los demás, no hay ninguna razón para insistir en que se usen.

Felizmente escucharé a alguien decirme que estoy equivocado. Sin embargo, lo que no soportaré es que alguien afirme que algo anda mal antes de haberse molestado en dedicar tiempo a comprender el problema o las razones de las elecciones que ya se han hecho.

Si el proyecto actualmente solo funciona correctamente en una versión específica de un compilador específico, entonces sería razonable esperar que ese mismo compilador sea el que se use en la versión final también, a menos que ese compilador deje de ser compatible en algún momento en el futuro; de lo contrario tal vez hay algunas buenas razones que desconoce para usar este compilador en particular.

Suponiendo que pueda hacer que este proyecto funcione cambiando su compilador y usando la configuración/marcas correctas, esto no es realmente un "error" como tal; sin embargo, es un indicador de una configuración de proyecto potencialmente frágil, que podría surgir como un riesgo potencial para el proyecto en el futuro; sin embargo, ese no parece ser el caso en este momento; parece que no hay razón para preocuparse por esto todavía.

Los próximos pasos constructivos que podría tomar serían primero arreglar su entorno de desarrollo/prueba/construcción utilizando las herramientas y la configuración correctas, luego capturar esos procedimientos de configuración inicial en forma de alguna documentación (si aún no existe). ) - por ejemplo, un Léame, una página Wiki privada, una página de OneNote, etc.

Mientras arregla su entorno de desarrollo, tome nota de todos los pasos únicos que es poco probable que recuerde dentro de unos meses. Por ejemplo: "Install [Tool] [Version] into [Folder]", o "Create an Environment Variable called [Name] set to [Value]", o "edit [Configuration File] and change [Line] to [Something else]", etc.

Si dicha documentación ya existe, pero resulta ser incompleta o inexacta, entonces podría darle un buen uso a esta experiencia editando la documentación para agregar la información que falta o para aclarar las instrucciones que le resultaron difíciles de entender o seguir. Esta información será valiosa para los desarrolladores que se unan a su proyecto en el futuro (o incluso para usted mismo si necesita reinstalar su sistema operativo).

Mientras que los proyectos maduros generalmente terminan teniendo un proceso simple de construcción de un solo paso, los proyectos nuevos e incompletos a menudo requieren otros procedimientos torpes/desordenados hasta que alguien tenga tiempo para optimizar el proceso. En realidad, se necesita tiempo para refinar este tipo de cosas y, por lo general, son de baja prioridad en comparación con la corrección de errores reales y la implementación de nuevas funciones. Hasta entonces, es útil mantener actualizados los documentos de configuración del proyecto para que los nuevos desarrolladores puedan saltar directamente al código y ser productivos más rápidamente.

El problema está en otra parte: como dices en tu PC no está compilando, pero en su sistema todo funciona bien.

En todas las empresas en las que he trabajado, había un servidor de compilación central: todos tienen un entorno de programación en su propia PC, pero al modificar una parte del código fuente, esto se ingresa en un sistema de control de versiones central, el servidor de compilación central. luego está recuperando las últimas versiones de todas las piezas de código fuente e intenta compilar. Si esto funciona, entonces todo está bien. Si no, entonces hay un problema.

Así que ese podría ser un enfoque valioso para su problema: "Señor, aquí tenemos la situación de que algo funciona en una PC pero no en la otra. En lugar de discutir qué PC es la correcta, usemos esta situación para configurar una central". build server, y en el futuro, si alguna vez volvemos a encontrarnos con una situación así, ese sistema será el juez de quién tiene razón".

Buena suerte

Busque una solución que funcione en ambas configuraciones

Un principio general en situaciones como esta es la Regla Scout :

Deje el código en (al menos) la misma forma o (preferiblemente) mejor que cuando lo encontró.

Entonces, su colega senior tiene su entorno de desarrollo configurado de una manera específica. Puede haber muchas razones para eso, algunas posibles buenas y muy válidas, algunas innecesarias y quizás incluso dañinas.

Buenas razones para esta configuración pueden incluir que...

• Acelera el desarrollo, la depuración y/o la implementación.
• Incluye funcionalidad que no está presente en otras configuraciones
• Se ocupa de la compatibilidad con versiones anteriores que se requiere para la interoperabilidad con otros módulos.
• Cambiar a otra configuración puede requerir mucho trabajo para garantizar que el resto del código siga funcionando según lo previsto _(*) .

Las malas razones para esta configuración pueden ser...

• Pereza u otra resistencia irracional a mantener actualizado el entorno de desarrollo ("¡Funciona bien para mí, no lo tocaré!")
• Prejuicio contra las versiones más nuevas como "No probado, por lo tanto inseguro".
• "Siempre lo hemos hecho así"

Lo que puede hacer aquí es preguntarle a su colega principal : "¿Cómo es que está usando eso? ¿Hay alguna razón específica?". Y te lo dirán. Tal vez su razón sea, en su opinión, buena y válida, o será, nuevamente en su opinión personal, una mala razón. Pero tenga en cuenta que lo más probable es que sientan que la razón es válida.

Lo que haría el menor alboroto es si realiza un cambio que funcione en ambas configuraciones, siempre que lo haga correctamente. Para eso hay que pasar por un...

Lista de Verificación

Si desea utilizar la Regla Scout y "arreglar" un problema que no está directamente relacionado con su trabajo, generalmente se agradece que lo haga. Pero solo si te aseguras de que lo que haces es realmente mejor. Como tal, debe asegurarse de que...

1. Mis cambios no romperán nada

El camino al infierno está pavimentado con buenas intenciones

Lo primero que debe hacer es asegurarse de que su solución no rompa nada. Las salvaguardas habituales (sin errores de compilación, revisión de código, pruebas automatizadas) lo ayudarán allí. Evite verificar una corrección de regla de Scout en la pista de desarrollo principal; en su lugar, use la rama lateral del código y pruebe el cambio antes que nada.

2. Mis cambios no harán las cosas más confusas ni agregarán complejidad innecesaria

Este punto se explica por sí mismo. Es una virtud mantener el código simple y mantenible. Si su cambio significa que se vuelve más difícil leer, compilar o implementar el código, entonces es mejor omitir el cambio. Pero si se puede agregar sin cambiar la complejidad del código, ni el proceso de compilación e implementación, entonces está bien.

3. Mis cambios mejorarán las cosas

Al igual que el desarrollador senior piensa que su configuración funciona para ellos, usted puede caer en la misma trampa. Y si bien una mejora para usted es razón suficiente para afectar un cambio, es posible que también desee preguntar a los demás "¿Vale la pena?". Si están de acuerdo en que esto es una mejora, adelante.

_{(*) Tuve problemas con el código simplemente por actualizar a una nueva subversión de un kit de desarrollo... ni siquiera la versión secundaria, sino la subversión .}

Para mejorar las posibilidades de que acepte su entrada, no comience con un simple "He encontrado un error en su código". Tómelo de lado y pídale que se siente con usted y revise el código, para que pueda entender la lógica.

Explique qué y por qué cree que está mal, y escuche sus respuestas. Hay dos posibilidades:

1. tienes razón, y él entenderá el error sin estar "molesto" por tu declaración "audaz".
2. estás equivocado y te has esforzado en entender el código con él sin afirmar que tenía errores.

Lo primero que debe hacer es asegurarse de conocer las reglas de idioma exactas para el software. Por lo general, a medida que evolucionan los idiomas y sus estándares, se agregan nuevas características. A veces, los compiladores particulares tienen características que van más allá de cualquier estándar formal. Las características del idioma que se permite usar son generalmente una decisión de los desarrolladores senior, pero pueden verse afectadas por problemas de marketing si los clientes necesitan poder compilar el código. "¿Podemos usar la extensión de idioma X?" es una pregunta legítima para que usted haga.

Si planea no estar de acuerdo con el desarrollador senior sobre qué funciones se deben usar, necesita razones muy sólidas por las que tiene que ser absolutamente de la manera que está proponiendo. Si es solo una cuestión de opinión y preferencias, gana la opinión del desarrollador principal.

Después de averiguar el conjunto previsto de características del idioma, debe asegurarse de que su compilador admita todas las características que permiten las reglas. Eso puede requerir la instalación de un compilador diferente, bibliotecas adicionales o la configuración de indicadores del compilador para habilitar funciones que están deshabilitadas de manera predeterminada.

Si el código no se compila con un compilador y una configuración que admita todas las características permitidas en el programa, entonces tiene un problema que discutir, en esos términos, con el desarrollador senior.

Voy a desviarme un poco del tema aquí y concentrarme obsesivamente en una pequeña cosa que dijiste...

errores tontos de mi parte

Hay una solución para esto. PRUEBAS DE UNIDAD ! Para cada función significativa que escriba, ¿por qué no tener un conjunto de pruebas unitarias que conozcan el resultado esperado para una entrada dada? Mientras escribe estas pruebas, comenzará a pensar en casos extremos extraños en las entradas. Diablos, para algunas funciones clave, incluso podría escribir las pruebas primero y ver cómo cambian lentamente de rojo a verde a medida que implementa su fn.

Este enfoque ayudará mucho con esos "errores tontos", porque los está verificando explícitamente en lugar de simplemente arrojar el código por la pared para el control de calidad.

Averigüe qué tipo de marco de pruebas unitarias está utilizando su grupo. Si no hay uno (estoy llorando y rechinando los dientes aquí), pida algo de tiempo para encontrar e instrumentar uno. Hay muchos buenos con nombres similares (nUnit, jUnit, xUnit, ...)

No te arrepentirás.

Está bastante claro que los desarrolladores tienen diferentes configuraciones en sus máquinas, y el mundo es perfecto si la solución se basa en su propia máquina.

Obviamente, esto es una tontería y depende de al menos una persona para construir e implementar la solución en su propia visión del mundo.

La respuesta es estandarizar mediante el uso de un servidor de compilación Jenkins o algo similar.

Tenemos uno para nuestras principales soluciones. Cada pocos minutos, toma los archivos de código más recientes del administrador de código fuente (TFS en nuestro caso) y luego intenta construir la solución. Si la compilación falla, todos los miembros del equipo reciben automáticamente un correo electrónico y quienquiera que rompió la compilación es nombrado y avergonzado implícitamente.

Obviamente, las opciones y el entorno del compilador en el servidor Jenkins son simples y están orientados a una compilación completamente válida/verdadera.

Esto elimina cualquier ambigüedad causada por personas que hacen referencia a copias locales de fuente/dlls en la naturaleza y no implementará una solución que haga referencia a una pieza de código que vive en la máquina de desarrollo de alguien.

El uso de un servidor de compilación como este nivela y estandariza el campo de juego y garantiza una consistencia total en el resultado final.

El hecho es que ya informó el problema a este desarrollador senior. Lo que realmente estás preguntando no es cómo denunciarlo, sino cómo convencerlo de que haga un cambio.

Has cumplido con tu responsabilidad. Informaste lo que crees que es un error. Él es el desarrollador senior, decidió que estabas equivocado y el código es correcto, así que eso es todo. Ahora hay dos posibilidades: O tiene razón o está equivocado. Si está equivocado, o no es muy senior, o es un tonto y no acepta nada de un desarrollador junior. En cualquiera de estos casos, perseverar no te llevará a ninguna parte.

En lugar de encontrar un error en el código, donde es su opinión contra la de él, averigüe si esto lleva a que el software se comporte mal de alguna manera. Eso es algo que se puede comprobar objetivamente y puede que tenga que arreglarse. Si no puede averiguar cómo este error hace que el software se comporte mal, entonces no hay error o no es importante.