project-management - sueldo - trabajar de programador

¿Cómo es que un buen desarrollador evita crear código con un bajo factor de impacto en el bus? (23)

La depuración es difícil. Por lo tanto, si está codificando tan inteligentemente como sea posible, 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

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. Según Wikipedia , en el desarrollo de software, el "factor de bus" de un proyecto de software (o "factor de éxito de bus") es

una medición irreverente de la concentración de información en una sola persona, o muy pocas personas. El factor de autobús es el número total de desarrolladores clave que si no estuvieran capacitados, como al ser atropellados por un autobús, enviarían el proyecto a tal desorden que no podría continuar.
Ser golpeado por un autobús podría tomar diferentes formas. Esto podría ser una persona que toma un nuevo trabajo, tiene un bebé, cambia su estilo de vida o su estado de vida, 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 un buen desarrollador evita crear código con un bajo factor de éxito de bus?

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

Al no codificar de forma aislada. Habla con otros en tu equipo sobre el código que estás escribiendo. Tener revisiones de código. Implementar estrategias comunes para resolver problemas. Si está en la misma página que todos los demás en el equipo, su factor de golpe de autobús será bajo.

Sin embargo, si usted es un desarrollador solitario, varias de las otras publicaciones aquí ya cubren las ideas de estándares de codificación, documentación, etc.

Al seguir los procesos de desarrollo ágiles que promueven la "propiedad" de toda la base de código por parte de todo el equipo.

Como buen desarrollador, no deberías preocuparte por tu factor de éxito en el autobús. Lo importante es que decidas cuándo correr frente al autobús y no tu empleador.

Creo que esto debería ser reformulado. Un buen desarrollador SINGLE no debería preocuparse por un factor de bus. Si su proyecto muere, bueno. Un buen EQUIPO, por otro lado, debería tener un factor de bus muy bajo.

El código bien escrito es probablemente la solución óptima. Por bien escrito, quiero decir que las declaraciones son concisas, los nombres de las variables y los métodos son significativos y el sistema está bien diseñado. Y muy importante: hacer esto no debería perjudicar los procesos actuales del desarrollador.

La documentación voluminosa será un obstáculo, tanto para el codificador actual como para el codificador futuro.

Los procesos formalizados (como las pruebas unitarias) son un obstáculo para la velocidad de desarrollo actual (a menos que, por supuesto, el codificador interno sea un defensor del proceso).

Un ejército marcha al ritmo de su marcador más lento. Emparejar a otro programador con alguien que sea muy productivo los retrasará. Muy rara vez una tienda tiene más de 1 codificador súper productivo.

El control de la fuente con los registros de cambios comentados es probablemente un componente clave.

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.

El proyecto debería ser fácil de verificar y configurar. En nuestra compañía, todos los proyectos son CVS y Eclipse y Maven, por lo tanto, al realizar el proceso de compra, usted hace un "eclipse maven" y ya está todo listo.

A partir de ahí, necesita un buen manual para desarrolladores (no un documento de 500 páginas, solo los elementos esenciales para que funcione). El manual del desarrollador apunta a diferentes documentos, donde los desarrolladores pueden encontrar información sobre el diseño y otras cosas.

Un sistema de seguimiento de errores es imprescindible, y las buenas descripciones en los errores son obligatorias.

Intenta comentar tu código y mantener javadoc actualizado.

Las buenas pruebas unitarias también ayudan. Intente que las pruebas unitarias sean simples, donde puede ejecutarlas sin tener que configurar todo tipo de cosas.

Espero que esto ayude.

El wiki c2 solía tener un artículo con un nombre como "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 y procesos de negocio comúnmente entendidos , para 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 los interesados no técnicos.
Establecimiento de objetivos concretos e indicadores verificables de progreso , evitando los sustantivos abstractos como "el sistema" al que cada uno atribuye su propio significado, informes verbales de "casi terminado" o "80% hecho" que se entiende que no se hacen de manera visible, las alarmas van apagado si pasan unos días sin un progreso objetivo por parte de un desarrollador (nueva aprobación de pruebas, nueva versión de demostración, etc.).
Auditoría y responsabilidad : usted no solo es responsable de hacer su trabajo, sino que también es responsable de rendir cuentas de ello a sus 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, disposición para 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.
Canales informales para plantear problemas y dudas (por ejemplo, colegas almuerzan juntos) y procesos formales para registrar y escalar problemas.

Encontré esta entrada de blog , que contiene algunos puntos interesantes:

Mantenga las cosas simples: mantenga los procesos lo más simple posible (¡pero no más simple!). Esto asegura que los procesos sean fáciles de mantener y, por lo tanto, fáciles de enseñar a los demás. La simplicidad generalmente se reduce a dos cosas: a) usar la herramienta correcta para el trabajo correcto, yb) usar la manera más directa de lograr lo que se necesita. He visto varios procesos innecesariamente complicados por tecnologías inapropiadas o el uso de tecnologías. Para profundizar en esto último, los procesos se diseñan a menudo con la única finalidad de demostrar la astucia del creador del proceso. Evite crear tales procesos de Rube Goldberg a toda costa. Un factor importante relacionado con la simplicidad (desde el punto de vista del autobús) es utilizar tecnologías que son familiares para más de una persona en el equipo. Esto se basa en un alto factor de bus desde el principio.
Documento, documento, documento: esto es obvio, pero la gente todavía piensa que puede salirse con la suya "hacerlo primero y documentarlo más tarde". La documentación hecha después del hecho a menudo es menos útil porque el autor olvida incluir algunos ( ¿Cuántos?) pequeños detalles que, por supuesto, resultan ser críticos en tiempos de problemas. ¿Qué debe contener un documento de proceso? Suficiente para ayudar a alguien a descubrir qué, cómo, dónde, cuándo y qué hace; cómo se ejecuta; donde se encuentra (servidores, etc.); y cuándo y con qué frecuencia se ejecuta. La documentación también debe incluir información básica de resolución de problemas y referencias a secciones relevantes de los manuales. Otro punto importante es mantener la documentación sincronizada con el proceso, es decir, actualizar todos los documentos relevantes cada vez que se modifique el proceso. Esto es esencial porque la documentación del proceso es su única guía cuando el propietario de un proceso con el factor de autobús 1 pasa por debajo del autobús en lugar de subirse al mismo.
Una pequeña palabra sobre el estilo quizás esté en orden : la documentación del proceso debe adherirse a las 3Cs de claridad, concisión e inteligibilidad. Sí, es posible escribir de una manera que logre los tres, aunque esto no es evidente en mis escritos. Aliente a las personas a adquirir habilidades secundarias: los primeros dos puntos se refieren al proceso y la documentación. Sin embargo, al final, son las personas quienes hacen que las cosas sucedan. A pesar de los procesos bien diseñados y documentados, todavía se puede tener un bajo factor de bus si el equipo no tiene redundancia de habilidades. ¿Quién se ocupará de las bases de datos cuando el DBA pasa por debajo (o es atropellado por) un bus? Esta pregunta no debería hacerse si alguien hubiera sido entrenado en tareas básicas de DBA. En la medida de lo posible, todos los miembros del equipo deberían tener al menos una habilidad secundaria que les permita cubrir a otra persona.

Estoy teniendo este problema ahora mismo. Básicamente, la fecha límite es una locura y no hay tiempo de aceleración para otros desarrolladores.

Creo que la solución es tener más de 1 desarrollador diseñar un sistema desde el inicio. SIEMPRE. Tres desarrolladores son mejores (sé que es el tamaño de equipo favorito de Google). De esta manera, más de una persona entiende ese sistema desde su núcleo y hasta, íntimamente, sabiendo cómo funciona y POR QUÉ fue diseñado de esa manera.

Puedes decir "¿pero qué pasa con los recursos en una empresa pequeña?" Lástima, si tiene dos desarrolladores y tres proyectos simultáneos, ambos desarrolladores deberían intercambiar entre los tres, intercambiar ideas y compartir la carga de trabajo, a pesar de que es muy costoso e ineficiente tener ese tipo de transporte. Pero a largo plazo, todo el equipo será una entidad experta en todas las partes del código.

De lo contrario, en algún momento alguien que no esté familiarizado con el código lo incorporará y lo vandalizará , con las mejores intenciones, por supuesto. Y aquí tienes, un sistema perfectamente bueno, tal vez incluso la joya de la corona de una empresa, bajando la colina. Maricón.

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 ...

A qué se supone que debe estar 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) también 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.

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 asociarnos en cada proyecto), siempre puede programar revisiones periódicas entre pares y documentar su código sobre la marcha, en lugar de documentar al final.

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.

Mientras trabajaba como programador estudiantil en mi Universidad durante mis estudios universitarios, 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.

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 factor "¿Qué pasa si Joe se aleja / decide salir?" . 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.

Siguiendo un patrón de diseño que rige el estilo de codificación, las convenciones y la arquitectura técnica general de bajo nivel. De esta forma, todos codifican "de la misma manera", por lo que si alguien nuevo tiene que unirse, podrían seguir el patrón de diseño.

Esto puede ser molesto para las mentes creativas (ya que la flexibilidad se ve comprometida), pero asegura una base de código consistente y también promueve pruebas unitarias alineadas y consistentes.

Para resumir:

Patrón (s) de diseño que garantiza que cada desarrollador cumple con el patrón (incluso podría usar reglas de política de código en la base del equipo visual studio para hacer cumplir estas reglas)
Pruebas unitarias que cubren más del 80% de cobertura de código (lo que también allana el camino para el desarrollo basado en pruebas)

Simplemente por tener más de un buen desarrollador ...

Todos en la empresa son parte de la solución o parte del problema.

Si alguien es atropellado por un autobús, y usted no está jodido, significa que esta persona fue parte de un problema. No desea extender el área del problema en su empresa solo para evitar que el factor de éxito del autobús crezca.

Y viceversa: si alguien útil es atropellado por un autobús, siempre estás jodido, pase lo que pase. Cuanto más contribuía la persona fallecida a la empresa, más te atormentaban.

El factor de éxito del autobús no es algo especial que exista solo en el desarrollo de software, sino más bien un riesgo comercial general.

Entonces, la respuesta es: no esperen que un riesgo comercial puro se pueda resolver mágicamente con alguna tecnología, herramienta o metodología. Piense en el negocio de wanilla 101. Estime el riesgo, calcule el costo de mitigarlo, compare las cifras y actúe en consecuencia.

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.

En orden de importancia (obviamente esta es mi propia opinión):

Objetos, variables y nombres de funciones claramente nombrados
Comentarios claros
Fuente de control
Revisiones de código
Software de seguimiento de errores razonable, con notas reales sobre lo que sucedió.
Documentación cuando sea necesario (pero solo cuando sea necesario; demasiado solo hace que sea difícil encontrar lo que necesita)

Y la persona responsable de eso? Tu, por supuesto.

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 autobús" de su equipo haciéndolos menos esenciales . Eso es difícil de hacer cuando te sientes inseguro sobre tu trabajo. Un buen gerente crea la seguridad que las personas necesitan para relajarse sobre este tipo de cosas.

Prácticas , aproximadamente en orden de prioridad:

El código bien factorizado significa que su intención está escrita en el código y elimina los secretos.
Las Pruebas unitarias exhaustivas sirven como una especie de documentación y como una red de seguridad cuando un titular secreto no está disponible. (Es decir, son documentos verificables ).
La programación de pares , especialmente Promiscuous Pairing , difundirá el conocimiento sobre el equipo de desarrollo y expondrá los secretos.
El 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.
La 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.