Estándares sobre cómo trabajan los desarrolladores en sus propias estaciones de trabajo

18

Acabamos de encontrarnos con una de esas situaciones que ocasionalmente aparece cuando un desarrollador se enferma durante unos días a mitad del proyecto.

Hubo algunas preguntas sobre si había cometido la última versión de su código o si había algo más reciente en su máquina local que deberíamos estar viendo, y teníamos una entrega pendiente a un cliente, por lo que no podíamos esperar que regrese

Uno de los otros desarrolladores inició sesión como él para ver y encontró un desorden de espacios de trabajo, muchos aparentemente de los mismos proyectos, con marcas de tiempo que dejaron en claro cuál era "actual" (estaba creando prototipos de algunas partes del proyecto que no fueran su "núcleo").

Obviamente, esto es un dolor de cabeza, sin embargo, la alternativa (que parecería ser estándares estrictos sobre cómo cada desarrollador trabaja en su propia máquina para asegurarse de que cualquier otro desarrollador pueda recoger las cosas con un mínimo esfuerzo) es probable que rompa muchos Los flujos de trabajo personal de los desarrolladores y conducen a la ineficiencia a nivel individual.

No estoy hablando de estándares para el código registrado, o incluso estándares generales de desarrollo, estoy hablando de cómo un desarrollador trabaja localmente, un dominio generalmente considerado (en mi experiencia) que está casi completamente bajo el control del desarrollador.

Entonces, ¿cómo manejas situaciones como esta? ¿Es una de esas cosas que simplemente sucede y tiene que lidiar con el precio que paga para que los desarrolladores puedan trabajar de la manera que mejor se adapte a ellos?

¿O le pide a los desarrolladores que se adhieran a los estándares en esta área: uso de directorios específicos, nombres de estándares, notas en una wiki o lo que sea? Y si es así, ¿qué cubren sus estándares, qué tan estrictos son, cómo los vigila y así sucesivamente?

¿O hay otra solución que me falta?

[Supongamos, por el argumento, que no se puede contactar al desarrollador para hablar sobre lo que estaba haciendo aquí, incluso si pudiera saber y describir qué espacio de trabajo es cuál de memoria no será simple e impecable y, a veces, las personas realmente pueden hacerlo. No me contacte y me gustaría una solución que cubra todas las eventualidades.]

Editar: entiendo que pasar por la estación de trabajo de alguien es una mala forma (aunque es una pregunta interesante, y probablemente fuera de tema , en cuanto a por qué es eso) y ciertamente no estoy buscando acceso ilimitado. Piense más en la línea de un estándar donde sus directorios de códigos están configurados con un recurso compartido de solo lectura: no se puede cambiar nada, no se puede ver nada más, etc.

development-process coding-standards

— Jon Hopkins
fuente

8

-1 por ir a la Gestapo al centro de comando de un programador.

— systemovich

17

Espera, ¿cómo sabía el segundo desarrollador la contraseña del primer desarrollador?

— TheLQ

12

+1 para una excelente pregunta. En mi opinión, "ir a la gestapo" no es relevante en un entorno corporativo, ya que los desarrolladores están trabajando para la corporación y, por lo tanto, renuncian a los derechos de acceso a sus máquinas locales. Desea privacidad, use su propio hardware.

— Gary Rowe

44

Si se pudo contactar al desarrollador para obtener la contraseña, ¿por qué no le preguntas qué versión era la actual?

— Ben L

2

@ Gary: ¿qué? no, eso es una tontería completa (y muy peligrosa). Es una oportunidad remota (tanto lógica como legalmente) desde trabajar para una empresa hasta renunciar a los derechos personales de privacidad. No llamaría a la acción de Jon "ir a la Gestapo" (incluso antes de que él lo explicara más), pero las empresas sí van a la Gestapo a veces y esto es algo que debe evitarse y combatirse en todos los niveles. Sólo puedo hablar en nombre de Alemania, pero aquí se haga tener ciertos derechos de privacidad, incluso cuando se trabaja en el hardware de propiedad de la empresa.

— Konrad Rudolph el

64

" Si no está en el control de la fuente, no existe " .

Esta es una de las pocas cosas en nuestra profesión sobre la que soy dogmático límite. Por las siguientes razones:

Aunque la estación de trabajo es propiedad de la compañía, seamos sinceros: hay una regla no escrita de que la propia estación de trabajo de un programador es su castillo. Simplemente estoy incómodo con una cultura del lugar de trabajo donde cualquiera puede iniciar sesión y pasar por ella de manera rutinaria.
Todos tienen su propio flujo (como también dijiste). Intentar obligar a todos los desarrolladores a organizar sus propios espacios de trabajo locales de una determinada manera puede ir en contra de su forma particular de trabajo, y romper su flujo y hacerlos menos eficientes.
Las cosas que no están en el control de la fuente son códigos a medio hornear. Si es un código completamente preparado que está listo para su lanzamiento, debería estar en control de fuente. Que vuelve de nuevo al punto principal ...
"Si no está en el control de la fuente, no existe".

Una posible forma de mitigar el problema de querer mirar el código en las estaciones de trabajo de las personas es fomentar una cultura de registros regulares. Una vez trabajé en una empresa en la que, aunque no había un mandato oficial para hacerlo, se veía una especie de orgullo tener siempre todo registrado durante el fin de semana. En las fases de mantenimiento y liberación de candidatos, los artículos CR fueron deliberadamente de grano muy fino para permitir cambios pequeños, claramente visibles, y registros regulares para realizar un seguimiento de ellos.

Además, tener todo registrado antes de irse de vacaciones era obligatorio .

TL; versión DR : revolver las estaciones de trabajo de las personas es una mala forma. En lugar de tratar de fomentar una cultura de facilitar el paso por las estaciones de trabajo de las personas para encontrar lo que queremos, es una mejor práctica fomentar una cultura de uso de control de fuente sensible y registros regulares. Posiblemente incluso registros hiper-regulares y tareas detalladas cuando se encuentran en fases críticas de los proyectos.

— Mesas Bobby
fuente

10

+1: Alguien está enfermo, perder el tiempo en su estación de trabajo probablemente va a costar más que el valor. Una persona ya se fue. Ahora, otro es perder el tiempo tratando de descubrir qué está pasando. Enorme pesadilla de gestión sin valor. Hasta que esté en control de fuente, nunca existió.

— S.Lott

1

¿Si se va por el día? Sí, por el resto de la semana? Tal vez, por un mes? Ninguna posibilidad. Este es uno de esos desagradables problemas de "tonos de gris" ... volvemos, una vez más, a comprometernos temprano, comprometernos a menudo, por lo que los patrones no necesariamente tienen que ser estaciones de trabajo sino el uso del control de versiones, pero claramente es algo Vale la pena pensar.

— Murph

Cuando dice liberación, ¿quiere decir liberación para la compilación o liberación para los usuarios?

— JeffO

2

@Murph: si los cambios se confirman en algún lugar cada X días, la cantidad máxima de trabajo que puede extraviarse vale X días, y eso es cierto sin importar cuánto tiempo esté inevitablemente fuera el desarrollador. Lo correcto es tener políticas sobre el registro con la frecuencia suficiente para que la cantidad de trabajo perdido se encuentre dentro de los límites aceptables.

— David Thornley

1

@David mi comentario fue una respuesta a la de @ S.Lott - en términos del argumento sobre "perdido". Especie de. Quiero que los compromisos sean atómicos en el sentido de un conjunto completo de cambios (estoy empezando a entender por qué rebase es una noción tan atractiva), por lo que veo "comprometerse a salvar" como problemático (en la instancia general y en ausencia de un rebase equivalente). Y, en cualquier caso, debería haber copias de seguridad automáticas diarias de la estación de trabajo bastante distintas del control de versiones.

— Murph

22

En lugar de aplicar un estándar sobre cómo los desarrolladores organizan sus estaciones de trabajo, aplique un estándar en el que todo el trabajo se registre al final de cada día . Los registros pueden ser a sucursales si aún están incompletos.

De esta manera, nadie debería necesitar acceder a la estación de trabajo de otro desarrollador.

Me imagino que esta política se enfrentaría con cierta oposición, pero nada comparado con lo que esperaría si aplicara reglas sobre la organización de las estaciones de trabajo.

— Kris
fuente

1

¿Con qué frecuencia fusionarías la rama? ¿Cada vez que sentiste que era estable?

— Jon Hopkins el

2

@ Jon Hopkins: "Liberable" es más fácil de administrar que "Estable". Liberable incluye estable y el propietario del producto está listo para ello. Y harás mucho procesamiento de rama a versión. Branch-to-stable tiene demasiado potencial para la subjetividad y la discusión "funcionó para mí".

— S.Lott

2

-1 No estoy de acuerdo con esto sin una gran cantidad de calificación, los registros deben ocurrir en un punto lógico, y no arbitrariamente al final del día. (Sí, debemos tratar de no irnos hasta que lleguemos a un punto crítico sensible pero la vida no siempre coopera). Las copias de seguridad deben ser distintas. Y todos debemos ser un poco menos valiosos sobre el acceso a nuestras cajas (no cambios a, acceso a)

— Murph

1

-1 porque esto no aborda escenarios como "Me siento realmente enfermo, me voy a casa en este momento. Hmm, mejor solo haga otros 30 minutos de preparación para no romper la construcción cuando me comprometo".

— Gary Rowe

2

Los registros de @Murph en 'trunk' o mainline (como quiera llamarlo) solo deben ocurrir como usted describe. Sin embargo, no hay nada de malo en que los desarrolladores 'guarden su trabajo al final del día' al comprometerse con una rama personal (aunque esto es mucho más fácil con git o mercurial que con SVN). Y en comparación con hacer cumplir las pautas sobre cómo se configuran las estaciones de trabajo de los desarrolladores (que fue nuestro punto de partida), es una solución francamente sensata.

— Kris

6

Te diré la verdad. Me siento incómodo con la idea de que alguien inicie sesión en mi máquina y explore mis cosas. De acuerdo, es el equipo y la propiedad de la compañía, pero es simplemente algo malo.

La última vez que me fui un fin de semana, los chicos reconfiguraron los servidores con la base de datos y el control de fuente y, por alguna razón, consideraron necesario iniciar sesión en mi máquina y reconfigurar el sistema para la nueva configuración.

Lástima que no tenían idea de lo que estaban haciendo y borraron un prototipo en el que había estado trabajando durante los últimos dos meses.

No habría sucedido si la comunicación adecuada estuviera en su lugar. Eso es lo que necesitas también. Acude a ese desarrollador y descubre el estado de las cosas. Aún mejor, solicite un informe a las personas antes de que se vayan de vacaciones para que tome una decisión informada sobre si necesita algo de ellos o no.

Pero no te metas con las estaciones de trabajo de las personas.

PD: Tenemos una convención para una estructura de directorio, pero su razón principal de existencia es una mezcla de historia / configuración: colóquela en otro lugar y no se compilará.

3

@Murph: Salir "enfermo" acompañado de una necesidad urgente de obtener algo de su sistema es una situación realmente rara. Puede no valer la pena ningún esfuerzo de estandarización.

1

Puedo entender por qué alguien debería leer su correo y no debería cambiar nada en su máquina, pero ¿qué tal si fuera estándar compartir (solo lectura) sus directorios de códigos? Eso evitaría la mayoría de lo que percibo como sus objeciones, pero aún así le da a la gente la posibilidad de llegar a su trabajo en caso de emergencia.

— Jon Hopkins el

3

¿No hay respaldo en ese prototipo?

— JeffO

2

@Developer art, ¿por qué no trabajaste en una rama del sistema de versiones?

1

@DeveoperArt, ¿qué quieres decir con "no usar esa opción"? ¿Quiere decir que no había forma de crear una rama por su cuenta? ¿Deshabilitaron de alguna manera la ramificación? Nunca he oído hablar de esa posibilidad. Aun así, podría haber creado su propio repositorio "git" (o incluso "svn") en su propia máquina local (tal vez respaldado en Dropbox o una unidad de red) sin involucrar a nadie más. Simplemente no puedo relacionarme personalmente con trabajar en algo durante 2 meses (o incluso 2 horas , realmente) ya sea "importante" o no, y tener solo 1 copia.

— JoelFan

6

Hace unos meses, estaba trabajando en un proyecto bastante grande y tuve que dejar el trabajo abruptamente cuando descubrí que estaba ingresado en el hospital. No tuve tiempo de revisar mi último código para el proyecto.

Afortunadamente, es una convención aquí (aunque no "necesaria") almacenar código /var/www/ourdomain.compara imitar la producción. Con una convención tan lógica y fácil de seguir, fue fácil para un compañero de trabajo iniciar sesión en mi máquina y recuperar mis últimos cambios.

Creo que algunas convenciones son buenas. Aunque estoy de acuerdo con Bobby cuando dice

"Si no está en el control de la fuente, no existe".

Además, una adición útil al espacio de trabajo de cualquier programador podría ser una unidad SATA de intercambio directo en el frente para almacenar todos los proyectos de origen y desarrollo. De esta manera, si surge un problema de este tipo, un empleado puede recuperar fácilmente los nuevos cambios de origen al proyecto sin la necesidad de iniciar sesión en la estación de trabajo de los desarrolladores.

— Craige
fuente

"... no existe". Para otros, eso es.

4

La primera parte de su pregunta identifica claramente los problemas de comunicación dentro de su equipo. ¿Has probado las standups diarias ?

Estoy de acuerdo con usted cuando dice que las normas probablemente conducirán a la ineficiencia si son demasiado estrictas. Los estándares deben ser definidos por el equipo , involucrando a todos.

En su caso, esperaría unos días después de que el desarrollador en cuestión regrese al trabajo. Luego organice una reunión para hablar sobre esos estándares.

Para evitar bloqueos psicológicos y resistencia, no nombre a personas o cosas específicas que vio. Manténgalo en general, el objetivo aquí es obtener la opinión de todos, incluido el desarrollador que cree que debería mejorar su forma de trabajar. El tipo también puede considerar su organización como un desastre.

Durante la reunión presente el problema y pregunte claramente cómo el equipo podría mejorar la situación.

El (conjunto) equipo de decidir qué hacer.

2

Ese usuario probablemente sufría de una falta de herramientas adecuadas. En particular, el uso de un sistema de control de versiones distribuido le habría eliminado la necesidad de tener diferentes directorios de código en diferentes estados. Podría haberlo guardado todo en ramas y haber sido mucho más feliz.

Sin embargo, al punto principal, no, no quiero que se me impongan estándares sobre cómo organizo mi propia estación de trabajo. Actualmente estoy retrasando la estandarización de mi departamento en un IDE (mi jefe REALMENTE nos quiere a todos en Eclipse porque es lo que usa y conoce bien, aunque IMO no es la mejor herramienta para mi trabajo).

Deje que los desarrolladores hagan lo que los haga sentir cómodos. Un desarrollador cómodo es más productivo que uno incómodo. Y si alguien NO es productivo, y sospecha que está buscando a tientas localmente con las herramientas, es una oportunidad de capacitación, no un buen momento para establecer nuevas reglas.

— Dan Ray
fuente

1

¿Cómo ayudaría eso? La pregunta aún existiría, solo estaríamos hablando de qué rama dentro de su repositorio DVCS local en lugar de qué espacio de trabajo.

— Jon Hopkins el

No asumas que son las herramientas, también es una apreciación de la mejor manera de hacer uso de las herramientas que pueden faltar. Lo que es obvio para algunos debe mostrarse a otros. El antipatrón de muchas copias del árbol de origen es uno que he visto varias veces. Sí, DVCS puede ayudar, pero en este contexto todavía tendríamos un problema para identificar la rama correcta y, si queremos ir más allá, hacer que esas ramas de Work In Progress estén disponibles. @Jon el DVCS local debería empujar automáticamente a la "copia de seguridad" de ese usuario de su repositorio. Por lo menos si mueve el problema de su caja.

— Murph

@ Jon - Supongo que el punto es que sus diversas ramas estarían en algo que tendría funciones de fusión incorporadas, en lugar de solo directorios dispersos de archivos divergentes. Además, levantarlo e ingresar al DVCS habría sido una oportunidad de capacitación.

— Dan Ray

1

@Dan - Pero algunas de esas ramas son callejones sin salida: pruebas de concepto, cosas con código de depuración variado en el que no desea fusionarse, versiones anteriores. El hecho de que tenga la funcionalidad de fusión no ayuda cuando no sabe qué debería fusionar.

— Jon Hopkins el

@ Jon - Supongo que es verdad. Tal vez simplemente no hay recuperación de alguien realmente comprometido a hacer un desastre.

— Dan Ray

2

En mi antiguo lugar de trabajo, teníamos un sistema por el cual cada tarea en nuestro seguimiento de errores tenía su propia rama en el control de la fuente. Se entendió que la mayoría de las veces, un desarrollador elimina un error / tarea, por lo que se permitió que el código roto se verificara en el control de origen.

Una vez que el código estaba en un estado estable en la rama de desarrollo, se realizó una nueva modificación arrastrando el código desde la rama con la que se iba a integrar. Una vez que haya probado esa fusión, sería simplemente un caso de confirmar el código en la rama de integración; no requeriría fusión ya que ya había hecho la fusión en su rama.

De esta manera, evita el problema de que los desarrolladores se preocupen por cometer código que está roto, y puede comenzar a aplicar la política social de hacer que sea súper aceptable registrar el código antes de salir de la oficina por la noche, de manera agradable y segura.

— Spedge
fuente

2

En esta situación particular, llame a la persona a su casa, deje muy en claro que no duda de que esté enfermo, sino que necesita que alguien más continúe con su trabajo y pregunte dónde están las últimas cosas y en qué estado.

Entonces debes considerar qué hacer desde aquí. Si el problema es que las personas rara vez se registran, considere usar un sistema de control de fuente distribuido que permita a las personas trabajar en sucursales sin molestarse entre sí.

Si el problema es que no le gustan los desarrolladores que tienen múltiples espacios de trabajo en su máquina, entonces supérelo. El estilo de trabajo es individual y básicamente debe mantenerse alejado de sus sistemas siempre que funcionen bien con las reglas para el repositorio de origen. Personalmente, reviso una nueva copia con mucha frecuencia para diferentes proyectos y solo la limpio de vez en cuando.

Si el problema es que no sabe lo que está haciendo su desarrollador, el problema es político, no técnico, y necesita cambiar su estilo de gestión. Recuerde que los desarrolladores son personal altamente calificado que rara vez le gusta la microgestión y usted tiene que delegar. De lo contrario, alejará a las personas más capacitadas.

Por lo tanto, recomendaría alentar una mejor manera de trabajar con el repositorio fuente común: digamos que está bien que las personas trabajen en sucursales y que se comprometan con frecuencia siempre que sincronicen diariamente su copia local en el repositorio maestro (ya que siempre hará trabajo de desarrollo en una rama, esto no influirá en otros).

1

Dije específicamente en la pregunta que suponía que no se podía contactar a la persona.

— Jon Hopkins

@Jon, en ese caso considere perdido su trabajo inacabado, asígnelo a otro programador y luego comience a reflexionar sobre por qué sucedió esto en primer lugar.

Hay una inconsistencia lógica allí: "no sabes lo que está haciendo tu desarrollador" frente a "tienes que delegar", lo que significa que sabes qué que está haciendo pero posiblemente no cómo , lo que a su vez es la razón por la que necesitas acceder al código ... (sí, la comunicación puede ayudar a resolver esto, pero si confía en sus desarrolladores para resolver un problema y es un problema pequeño, para un desarrollador dado, entonces "¡vaya a solucionar esto, adiós!" puede ser tan administrativo como es posible) necesario).

— Murph

@Murph, luego imponga una regla de "comprometerse a menudo - en una rama" y presione al centro al menos diariamente.

1

Entonces, ¿cómo manejas situaciones como esta?

Puede resolver este problema con un sistema de control de fuente que admita ramas personales inestables y manteniendo compromisos frecuentes. Una confirmación no tiene que venir cuando se resuelve un problema completo. Debería venir siempre que se beneficie del control de fuente. El final del día es uno de los muchos puntos en los que se debe realizar una confirmación para que pueda ver dónde se realizaron los cambios, respaldarlos y explicarlos a su futuro yo u otros.

¿O le pide a los desarrolladores que se adhieran a los estándares en esta área: uso de directorios específicos, nombres de estándares, notas en una wiki o lo que sea?

Tenemos un documento de configuración de entorno inmenso que denota convenciones, pero no un estándar. Los estándares son para código de producción y entornos. Sin embargo, muchas de nuestras herramientas de desarrollo están configuradas para admitir las convenciones y la mayoría de los desarrolladores no gastan esfuerzos en contrarrestar la tendencia.

— Thomas Langston
fuente