Pregunta ¿Cómo es que un buen desarrollador evita crear código con un bajo factor de impacto en el bus? [cerrado]


texto alternativo http://www.metrocouncil.org/Directions/transit/images_transit/GoToBus.jpg

Mira la foto de arriba. Podría ser un programador golpeado por un autobús. De acuerdo con la Wikipedia, en el desarrollo de software, un "factor de bus" de proyecto de software (o "factor de éxito de bus") es

una medida irreverente de   concentración de información en una   una sola persona, o muy pocas personas. los   factor de bus es el número total de clave   desarrolladores que si fueran incapacitados,   como al ser golpeado por un autobús, envíe el   proyecto en tal desorden que   no podría continuar.

Ser golpeado por un autobús podría llevar a muchos   diferentes formas. Esto podría ser un   persona tomando un nuevo trabajo, teniendo un   bebé, cambiando su estilo de vida o vida   estado, el impacto tendría el mismo   efecto.

O en otras palabras: si el desarrollador original de una pieza de código alguna vez es golpeado por un bus, estás jodido.

Entonces, mi pregunta es: ¿Cómo es que un buen desarrollador evita crear código con un bajo factor de impacto en el bus?

Y, ¿quién es responsable de asegurar que los desarrolladores, traídos para mantener un poco de código, puedan entenderlo?


75
2017-12-30 14:27


origen


Respuestas:


Perder a un miembro clave del equipo sucede a menudo, ya sea temporal o permanentemente. Ya sea que alguien esté tomando un almuerzo largo, o que la gripe vaya por la oficina, o un programador quiera cambiar roles dentro de la misma compañía, o atraviese un doloroso divorcio, o se dé a la vuelta al mundo, o se lastime trágicamente, el la perspectiva de un cambio repentino e inesperado en el equipo es inevitable.

Uno de los atributos de un buen desarrollador es que se esfuerzan por reducir el "factor de bus" de su equipo haciéndolos ellos mismos Menos esencial. Eso es difícil de hacer cuando te sientes inseguro sobre tu trabajo. UN un buen gerente crea la seguridad la gente necesita relajarse sobre este tipo de cosas.

Prácticas, aproximadamente en orden de prioridad:

  1. Código bien factorizado significa que su intención está escrita en el código y elimina los secretos.

  2. Completo Pruebas unitarias servir como un tipo de documentación y como una red de seguridad cuando un titular secreto no está disponible. (Es decir, son verifiable documentación.)

  3. Programación de pares, especialmente Emparejamiento Promiscuo, difundirá el conocimiento sobre el equipo de desarrollo y expone secretos.

  4. Envío a menudo significa que incluso si sucede algo, sus clientes ya tienen un producto reciente y funcional, y usted tiene una cantidad conocida a la que recurrir si las cosas se vuelven locas.

  5. Documentación, tanto en los comentarios como en otros lugares, almacena ideas e intenciones que no se pueden expresar en el código. Sin embargo, la documentación es cara de crear, costosa de consumir, costosa de mantener y, a menudo, ignorada, por lo que se prefieren los demás artículos.


74
2017-12-30 15:42



Yo diría código que tiene buenas pruebas unitarias. Para el desarrollador de reemplazo unirse al proyecto sabiendo que sus cambios no están rompiendo otras partes del sistema es importante.


17
2017-12-30 14:37



La parte más difícil de la OMI de mantenimiento es no saber qué hace el software o cómo lo hace: es saber qué se supone que debe hacer el software.

Si supiera ...

  • Qué se supone que debe ser el software (es decir, la especificación funcional ... No necesariamente necesito la especificación de diseño)

  • Cómo construir, cómo ejecutar y (siguiendo la especificación funcional) cómo probar el software existente

... entonces eso es lo más importante. Otra documentación (por ejemplo, "diseño": que describe cómo el software implementa la especificación funcional) podría ser útil, pero es comparativamente opcional y menos importante que la anterior.

La mayoría de los desarrolladores responderán a su pregunta diciendo "comentarios en el código, identificadores bien nombrados, control de fuente, etc." ... pero creo que es más importante "como desarrollador, si está escribiendo un software que no tiene una especificación funcional escrita, escriba un poco de especificación funcional para que coincida con su software". Un FS será útil incluso antes de que alguien intente mantener el software: será útil para QA que quiera saber cómo probar el software.

Y, ¿quién es responsable de asegurar que los desarrolladores, traídos para mantener un poco de código, puedan entenderlo?

Normalmente, ese es el líder del equipo del nuevo desarrollador (es decir, el programador principal que ya conoce el código existente); pero en su defecto (si no hay tal líder de equipo) podría ser un gerente (gerente de producto o proyecto, o "ingeniero de lanzamiento") si ese gerente sabe dónde encontrar las especificaciones funcionales del software y las instrucciones de compilación.


14
2017-12-30 14:47



Las revisiones regulares de códigos de pares ayudan. Esto significa que al menos otra persona debe haber examinado cada línea de código y debería haber solicitado que se modifique para mayor claridad cuando sea necesario.

Constantemente me esfuerzo por la claridad del código en lugar de la brevedad, lo que debería ayudar a los futuros desarrolladores. Sin embargo, hay ocasiones en las que no puedes evitar escribir un código que es un poco obtuso. En este caso, reúno al equipo durante 30 minutos para analizar una idea de alto nivel de cómo funciona el código, si no una explicación completa.

Un conjunto de pruebas unitarias también ayuda a otros desarrolladores a confiar en la alteración del código, ya que sabrán cuándo realizan un cambio que rompe parte del sistema. Si están bien redactados, también pueden explicar cómo se pretende que las partes del sistema funcionen a través del nombre en lugar de simplemente a través del código.


12
2017-12-30 14:32



Mientras trabajaba como programador estudiantil en mi Universidad durante mi licenciatura, mi Bus Hit Factor tuvo que ser administrado de cerca. Estaba trabajando en proyectos importantes, pero mi empleo allí solo fue hasta el día en que me gradué. En este punto, otros programadores del departamento tendrían que retomar mi proyecto y administrarlo desde allí. Logré esto con cubos de documentación. 

Desde el día en que comencé en ese trabajo, hice todo lo posible para mantener mis especificaciones, códigos y demás documentación lo más actualizada y limpia posible, de modo que cualquier compañero de trabajo competente pudiera adquirir una sólida comprensión de mi trabajo en cuestión de días. (con o sin mi ayuda). Cada proyecto mío tendría una Wiki de Confluencia correspondiente en la que mantendría toda la documentación, diagramas, especificaciones y pequeños detalles para que otros desarrolladores puedan saber.

También ayuda si tiene un buen estilo de codificación limpia. Si su código tiene sentido y es fácil para los ojos, otros programadores deberían poder recogerlo después de su desafortunado accidente de autobús.


10
2017-12-30 14:38



Siempre debe haber duplicación de conocimiento en una organización.

Al igual que siempre haría una copia de seguridad de su disco duro (¿verdad?), No desea que una persona sea el único poseedor de información importante. Una forma de mitigar esto es hacer que los programadores trabajen juntos.

Lo que mencionas como el problema del "autobús" es, más prácticamente, el "¿Qué pasa si Joe se va / decide dejarlo?" factor. En general, el empleo es a voluntad, y cualquiera puede irse en cualquier momento.

Una organización resistente no puede depender de un único desarrollador que posea todos los conocimientos importantes.


7
2017-12-30 14:33



El control de la fuente y el código bien pensado y comentado son la clave.

Las personas responsables de garantizar que esto no suceda realmente son todas las personas involucradas con el código. Los gerentes de Dev y los PM son las personas que deben vigilarlo de cerca, pero la gerencia ejecutiva tiene que implementar políticas para apoyarlos y tener recursos disponibles para garantizar que varias personas tengan áreas de conocimiento superpuestas.


4
2017-12-30 14:34



La programación de pares mitiga este riesgo en un grado bastante alto. Si no puede hacer eso (muchos de nosotros no tenemos el lujo de formar parejas en cada proyecto), siempre puede programar revisiones regulares entre pares y documentar su código a medida que avanza, en lugar de documentar al final.


3
2017-12-30 14:52



La depuración es difícil. Por lo tanto, si eres   codificando tan hábilmente como sea posible, eres   va a ser demasiado estúpido para depurar el código.

  • El código simple mejora la capacidad de mantenimiento
  • El código revisa el control por simplicidad
  • Los gerentes de proyecto llevan la responsabilidad

3
2017-12-30 14:33



La wiki c2 solía tener un artículo con un nombre en la línea de "No confíes en un desarrollador en una sala por un mes". La referencia era proyectar planes con líneas de pedido como "Implementar sistema, Fred, seis semanas", donde la gestión del proyecto consiste en conversaciones como "¿Cómo va Fred? ¿Todavía estamos bien por seis semanas?" y Fred diciendo "Sí, creo que estamos 80% allí".

Un número de autobús saludable es un efecto secundario de una cultura que evita el síndrome de "desarrollador en una habitación por un mes". Creo que es un problema más cultural que técnico: un número de autobús es un atributo de una organización en lugar de una base de código, y los estándares deben establecerse de arriba hacia abajo. Las características de esta cultura incluyen:

  • Objetivos de la organización comúnmente entendidos y los procesos comerciales, de modo que los desarrolladores tengan algo más que una perspectiva estrechamente técnica para la toma de decisiones, y que tengan un marco para discutir los pros y los contras con las partes interesadas no técnicas.
  • Establecimiento de objetivos concretos y indicadores verificables de progreso, evitando los sustantivos abstractos como "el sistema" al que cada uno atribuye su propio significado, los informes verbales de "casi terminado" o "80% hecho" significan que no se hacen de manera visible, las alarmas se disparan si pasan unos días sin un progreso objetivo por parte de un desarrollador (aprobación de nuevas pruebas, nueva versión de prueba, etc.).
  • Auditoría y rendición de cuentas: no solo eres responsable de hacer tu trabajo, sino que eres responsable de rendir cuenta de ello a tus colegas. El hecho de que se le pida que presente una cuenta no es en modo alguno una crítica, sino un medio de apoyo y una forma de "verificar" sus conocimientos en la organización.
  • Curiosidad, voluntad de apoyar a los colegas. Los problemas con el número de autobús a menudo se ven agravados por la reticencia de otros desarrolladores para ayudar a su colega vulnerable al accidente de autobús en caso de que se infecten con las extensas responsabilidades de ese colega y las tareas de mantenimiento heredadas.
  • Informal canales para plantear problemas y dudas (por ejemplo, colegas almuerzan juntos) y procesos formales para registrar y escalar problemas.

3
2018-01-13 02:52