JH Rainwater "Cómo pastar gatos": en el otro lado del desarrollo

Continuamos compartiendo extractos del manual para aquellos que se están preparando para dirigir el equipo de desarrollo. En la parte anterior, hablamos de todo lo ajeno, que está al acecho del líder técnico en la nueva posición, pero ahora volvemos a las cosas familiares y amigos, en realidad la programación. Aquí, el desarrollador de ayer puede sentir su elemento, pero no tiene que relajarse: el área de responsabilidad está creciendo y cambiando. En Cat, presentamos una breve descripción de todas las nuevas responsabilidades y consejos de adaptación que Rainwater trae en su libro.

La diferencia fundamental radica en dos matices. En primer lugar, el plomo entra mucho antes en el proceso y no se cierra hasta el final victorioso. En segundo lugar, mientras el desarrollador se enfoca en la tarea estrecha que se le asigna, su jefe revisa el producto en su totalidad, sin olvidar entrar en detalles cuando la situación lo requiere. Vayamos juntos con el autor en orden y tratemos de describir el papel del líder del equipo en cada etapa de la creación de la aplicación.

Definición de requisitos y especificaciones.

Un buen techlide comienza a funcionar con el producto incluso cuando está en estado perinatal, es decir, en forma de una idea general, solicitud o lista de funciones. Sin embargo, aquí debe aclarar de inmediato: Rainwater cree firmemente que el desarrollador no debe participar en el trabajo de un comercializador o gerente de producto, o más bien, debe evitar este escenario con todas sus fuerzas. No es que fuera imposible o reprensible para el "técnico" comprender las realidades del mercado y los requisitos comerciales, pero combinar estos dos roles es muy difícil. Entre otras cosas, existe un mayor riesgo de que el desarrollador interno gane y las características del producto se adaptarán a los intereses del equipo programador, en lugar del usuario final. Es mucho más fácil y seguro trabajar cuando la visión general del producto en términos de su funcionalidad ya está preparada y probada para su viabilidad por personas conocedoras.

Para la combinación de los dos roles, los desarrolladores que en nuestra clasificación a menudo pertenecen a la raza de los vaqueros a menudo abogan: anhelan los tiempos de "garaje" cuando pequeños equipos fabricaban todo el producto desde y hacia y no había necesidad de interacción externa. El autor tiene prisa por disipar todas las ilusiones sobre este puntaje: en condiciones modernas, la interacción entre grupos técnicos y no técnicos debería ocurrir regularmente, durante todo el ciclo de vida de la aplicación. Las primeras reuniones se llevan a cabo para la preparación conjunta de especificaciones. El gerente de desarrollo (o uno de los principales desarrolladores) se familiariza con la descripción del producto, excluye todo lo que le parece injustificado o poco realista desde un punto de vista técnico y toma el plan final para traducirlo al lenguaje de la tecnología. Luego, los grupos se reúnen de vez en cuando para "verificar el reloj" y asegurarse de que la implementación no se desvíe demasiado del plan original.

La frecuencia recomendada de tales reuniones es aproximadamente una vez a la semana, aunque, por supuesto, debe realizar ajustes en el ritmo general de desarrollo y las características de la organización de procesos para una empresa en particular.

También se necesitarán reuniones regulares por otra razón: es probable que los intentos de desviarse del curso original provengan no solo del lado del desarrollo. La mayoría de las aplicaciones, para seguir siendo competitivas, están en constante crecimiento con herramientas y capacidades adicionales. Por lo tanto, el proceso de considerar, evaluar y abandonar las ideas puede repetirse hasta el infinito, solo en una escala menor que para las especificaciones primarias. Es extremadamente importante para Tehlid mantenerse al tanto de los planes para el desarrollo del producto; esto no solo le da margen de maniobra desde el punto de vista organizacional (asignación de responsabilidades, determinación de términos), sino que también le permite calcular de antemano las consecuencias para el sistema en general, su armonía y sostenibilidad

Antes de aceptar que una nueva función funcione, debe hacerse una serie de preguntas:

• ¿Qué impacto tendrá el cambio propuesto en la arquitectura del sistema a corto y largo plazo?
• ¿Cómo afectará el cambio propuesto a la infraestructura de red en la que se llevará a cabo?
• ¿Cómo afectará el cambio propuesto la capacidad del usuario para interactuar de manera efectiva y productiva con este producto?
• ¿Qué impacto tendrá el cambio propuesto en las acciones de los empleados que tienen que trabajar estrechamente con él, para implementar, para acompañar?

Tales reflexiones ayudarán a identificar las trampas y establecer direcciones generales para el diálogo con otros grupos.

Diseño

Cuando los requisitos son aprobados y bendecidos por todos los participantes en el proceso, llega el momento de lo que Rainwater llama coordinación de las decisiones arquitectónicas y de diseño. En otras palabras, la guía técnica necesita describir el sistema que realizará las funciones especificadas en la etapa de especificaciones, y reflexionar sobre los componentes responsables de los procedimientos específicos. Es crítico actuar en este orden:

Arquitectura primero, luego componentes.

El autor enfatiza esto muchas veces, porque muchos desarrolladores que no están familiarizados con el arte del diseño del producto caen en esta trampa. Parece lógico tomar una lista de requisitos, prescribir los componentes necesarios para cada uno y considerar el producto como una combinación simple de ellos. Pero en realidad, este enfoque mecanicista da lugar a monstruos rígidos y aleatoriamente organizados que absorben todos los jugos de los desarrolladores involucrados en el apoyo al proyecto. Para evitar esto, debe ir hacia otro lado, de lo general a lo particular. Ya tiene una visión funcional común del producto con una perspectiva de desarrollo: debe "reflejarlo" en su visión técnica general con una perspectiva de desarrollo, es decir, arquitectura.

Arquitectura del edificio

Si recurrimos a una metáfora trillada, la arquitectura es el esqueleto del producto, sobre el cual se construye la carne de las decisiones privadas sobre la implementación de los procedimientos. Revivimos un poco esta metáfora, agregando una aclaración: el esqueleto debe afilarse para que crezcan nuevas extremidades. Los dos requisitos principales para la arquitectura son una organización lógica clara de componentes y flexibilidad que agregará nuevos a medida que el proyecto crezca.

Quizás esta etapa en el desarrollo pueda llamarse la más responsable: los expertos dicen que es precisamente el descuido de los problemas de arquitectura lo que a menudo conduce al colapso de los proyectos. Entre las causas comunes de falla, nombran:

• Falta de pensamiento, organización descuidada (o su completa ausencia).
• Excesiva rigidez y sencillez del sistema, evitando su expansión de acuerdo con las necesidades comerciales.
• Excesiva interconectividad de componentes, falta de flexibilidad en la configuración.
• Complejidad excesiva en los niveles superiores, lo que dificulta la modificación de los componentes básicos.

En consecuencia, la tarea de construir arquitectura debe abordarse con toda seriedad, sin ahorrar recursos. Recuerde que está sentando las bases con las que tiene que trabajar hasta el final: debe resistir todos los cambios que esperan el proyecto en el futuro. Este proceso es en gran parte creativo y visionario, pero los métodos estándar de estructuración son útiles para equilibrar el sistema. Por ejemplo, dibuje un diagrama de bloques con un conjunto completo de conexiones o incluso implemente un diseño simple (un conjunto de componentes de bajo nivel con apéndices y valores de retorno) para asegurarse de que la arquitectura funcione en una proyección vertical. Es muy conveniente hacer esto último antes de comenzar el desarrollo de componentes reales de pleno derecho: eliminar errores con elementos de "juguete" es mucho más fácil e indoloro.

Al final del trabajo en esta etapa, debe estar listo para responder las siguientes preguntas:

• ¿Cómo interactuará el usuario con el sistema?
• ¿Qué componentes deben ensamblarse para garantizar el funcionamiento del sistema?
• ¿Cuál será el mecanismo para la interacción de componentes que asegure el funcionamiento del sistema?
• ¿Qué tecnologías son las más adecuadas para crear esta aplicación?
• ¿Cómo se supone que debe entregar el sistema al cliente?

Planificación de componentes

Cuando se desarrolla el marco general, es hora de profundizar en particular e implantar los componentes actualmente relevantes en la estructura orgánica. La principal dificultad aquí es resistir la medida necesaria de conexión. Por un lado, los componentes no deben considerarse como contenedores estrictamente aislados para conjuntos específicos de operaciones, sino como un sistema de órganos, cada uno de los cuales se comunica con los demás, pero realiza sus funciones. Al mismo tiempo, se debe evitar una fuerte interdependencia entre las regiones, como resultado de lo cual la modificación de un componente conducirá a una cadena completa de cambios, o incluso mal funcionamiento, en todo el sistema.

La pila de tecnología se describió en la última etapa, ahora debe comprenderla en detalle. En la elección del idioma, las bibliotecas y, además, tiene sentido ser guiado no solo por motivos profesionales, sino también estrictamente pragmáticos. Digamos, ¿tendrá suficiente personal competente para soportar sistemas construidos sobre la base de tecnologías avanzadas, raras o complejas? Y viceversa, si da preferencia a las tecnologías más antiguas, ¿qué tan prometedor es? ¿Permanecerán funcionando durante todo el ciclo de vida, comenzarán a surgir problemas de compatibilidad? Todos los problemas relacionados con las soluciones de hardware, la creación, la configuración y el mantenimiento de la infraestructura deben considerarse con el mismo cuidado.

Desarrollo y control de calidad.

Entonces, la planificación finalmente se completa y el proyecto comienza a funcionar: comienza el desarrollo real de la aplicación. El papel del líder técnico en este proceso consiste principalmente en el monitoreo, para que todo vaya de acuerdo con los términos y estándares; él está directamente involucrado en la creación de código, por regla general, solo en situaciones de fuerza mayor. En su mayor parte, el jefe realiza las funciones de un código policial, es decir, realiza revisiones críticas periódicas del código para asegurarse de que no contradicen el marco arquitectónico y los principios básicos de programación.

Durante las inspecciones, un líder técnico puede encontrar diferentes tipos de errores. El agua de lluvia enfoca al lector en dos variedades:

• Violación de normas . Esto incluye estilo, nombres, comentarios: en general, todo lo que ayuda a un tercero a comprender lo que está sucediendo en el código, así como la negligencia en el espíritu de varios puntos de salida u operadores de GoTo odiados. Es necesario asegurarse de que todos los participantes en el proceso de desarrollo hablen el mismo idioma; esto hace que el código sea transparente y le permite desentrañar rápidamente movimientos erróneos. Los nombres de parámetros y variables deben indicar claramente su contenido, los comentarios deben ayudar a rastrear el código de los pensamientos de un desarrollador, justificar sus decisiones. Por cierto, si alguien del equipo se niega obstinadamente a comentar sobre el código, vale la pena considerar por qué. A menudo, esto es solo pereza o una peculiaridad de pensamiento, pero en algunos casos puede ser un síntoma de que el empleado mismo no comprende realmente lo que está haciendo: confundido o simplemente copiando partes del código de otra persona por una buena razón. También es necesario monitorear cuidadosamente a aquellos que regularmente descuidan el manejo de errores: la incapacidad para identificar las fuentes de errores es una falla grave para el desarrollador.
• La conectividad débil y la fuerte interdependencia son dos áreas de perturbación que pueden considerarse juntas, ya que la presencia de una implica la presencia de la otra. Aquí, de hecho, todo depende del grado de ramificación y su tipo. Con un alto grado de ramificación en términos de salida, el funcionamiento del procedimiento implica el acceso a muchos otros procedimientos, lo que, por supuesto, no es deseable. La ramificación en la entrada, por el contrario, tiene un efecto positivo, ya que indica una encapsulación estricta. Si tiene dudas al analizar el código para estos parámetros, sería bueno dibujar un diagrama de bloques con una jerarquía marcada de objetos. Revela de inmediato todo lo que necesita saber: ¿es posible rastrear el pedigrí del objeto, hay lógica en la disposición de las flechas o todo parece desordenado?

Si la policía del código detectó violaciones en estas y otras áreas, el procedimiento de arresto se ve así: el código se envía de regreso al desarrollador con los comentarios necesarios, el trabajo en el componente correspondiente se suspende hasta que se arreglen los defectos. Es altamente deseable que el desarrollador maneje esto él mismo, aunque con consejos: si hace todo por él, el componente de tutoría de la inspección del código se pierde.

No posponga la revisión hasta mejores tiempos. En primer lugar, puede volver con fuerza en el futuro y requerir muchos más recursos para solucionar toda la bola de nieve de los problemas. En segundo lugar, la teoría de las ventanas rotas también funciona en la programación: el código desordenado y confuso genera aún más código desordenado y confuso, simplemente porque parece válido.

Finalmente, hablando del control de calidad, uno no puede dejar de referirse al problema del notorio factor humano. Rainwater recomienda que el gerente tome una posición intermedia. Algún grado de resistencia a la interferencia con el código es natural y benigno. Una completa disposición a seguir las instrucciones de otra persona y aceptar la opinión de otra persona debería incluso alertarlo; a menudo esto significa que al desarrollador, de hecho, no le importa lo que publica. Pero, por otro lado, la incapacidad de percibir críticas sólidas dificulta tanto el crecimiento profesional como el trabajo en equipo. En consecuencia, el deslizamiento tecnológico tendrá que crecer la piel más gruesa y no tener miedo de insistir en sí misma, sin tener una reacción negativa a su corazón.

Prueba

Aquí, es importante que el líder tenga en cuenta dos reglas básicas: se deben realizar pruebas y organizar su conducta es su responsabilidad. Si la compañía tiene un departamento de pruebas que está naturalmente involucrado en los procesos, entonces no habrá problemas con esto. Si no, tendrá que asignar un recurso de sus propias reservas para este asunto.
En el segundo escenario, según el autor, hay ciertas ventajas: la prueba es una habilidad útil para el desarrollador. Es especialmente útil atraer a los recién llegados a estas tareas, para que puedan adquirir calificaciones rápidamente. Al principio, puede realizar tareas de prueba hasta la mitad de su tiempo de trabajo.

De lo contrario, para garantizar una buena calidad de inspección, es necesario asegurarse de que el producto no se cocine todo el tiempo en el mismo grupo; idealmente, debe probarse "al costado". Si una empresa tiene varios equipos de desarrollo, puede tener sentido acordar con otros líderes para crear un grupo mixto.