¿Cómo mantener la coherencia en la arquitectura de la aplicación a medida que un equipo crece?


49

Como único desarrollador en una startup, tuve el lujo de poder tomar muchas decisiones en la arquitectura y los marcos de nuestra aplicación.

Avance rápido 4 años y una adquisición más tarde, tengo un equipo de 5 y muchas veces se siente como el salvaje oeste. Las personas que toman cualquier decisión de diseño les agrada: números enteros y enumeraciones para tipos de bases de datos en un lugar y cadenas en otro, este marco para un problema y luego un marco diferente para el mismo problema en otro lugar, etc.

¿Cómo hago para hacer cumplir la consistencia? Me parece importante, pero los miembros de mi equipo parecen suscribirse a la metodología "si funciona, funciona".

Supongo que una gran parte de mi pregunta es: ¿no es realista de mi parte esperar estándares como este? Lucho con la idea de parecer un dictador que sofoca la creatividad, pero hacer lo que quieran parece no ser escalable.


8
¿Puede contarnos todo lo que pueda sobre su proceso SDLC existente? ¿Eres cascada, ágil, etc.? ¿Utiliza TFS o gestión de tareas? ¿Realiza revisiones de código o utiliza FxCop u otras formas de validación de código? ¿Producen documentación de diseño? ¿Tiene un rol de arquitecto designado?
John Wu


1
@gnat: No es un gran duplicado, si las respuestas son alguna indicación.
Robert Harvey

2
Para ser justos, estos estándares deberían haberse establecido desde el principio y estar basados ​​en un documento de "mejores prácticas" ampliamente aceptado para que nadie pueda quejarse de favoritismo o elitismo. Si está recibiendo un fuerte retroceso de un individuo, tendrá que considerar si un vaquero vale la pena el ambiente saludable para el resto del equipo y reemplazarlo, de todos modos lo dejarán en su lugar, siempre lo hacen. Luego, creo que todos los consejos que se dan a continuación para usar una revisión estricta del código antes de registrarse y agregar un componente de arquitectura funcionarán de maravilla.
Patrick Hughes

1
Ese es el santo grial de la ingeniería de software (aparte del otro santo grial, que es la obtención precisa de requisitos).
pmf

Respuestas:


55

Que te Hace tan Especial?

Mi CPU dice que funciona y quiero irme a casa. ¿Por qué me molestas?

Puede lidiar con esta actitud obligando a todos a emitir solicitudes de extracción. Pero ahora los plazos se avecinan. El código incorrecto presiona las puertas de tu castillo prístino y finalmente cedes a la presión. O ganas solo para encontrar que todos se van y nadie usa tu castillo prístino.

Hay muchas herramientas que ayudan con este problema. El control de la fuente, las revisiones de código, los estándares de codificación, etc., pero el corazón y el alma del problema son sus opiniones subjetivas sobre lo que es mejor tener que ver como relevante. Para eso hay que ganarse y mantener su respeto. Haz eso y esto es mucho más fácil. Si no lo haces, ninguna herramienta o práctica te salvará.

La mejor manera de hacerlo es comunicarse temprano. No me diga "no usamos cadenas para nuestros tipos de bases de datos en esta tienda" 6 meses después de que decidí la idea. Decirme que ha estado enterrado en la documentación durante 2 años no es justificación para dejarme hacer eso.

Por alguna razón tienes cosas que te importan. Si se preocupa por ellos y tiene un punto, comunique esas cosas claramente antes, durante e inmediatamente después de la codificación de cada módulo.

El acecho de código es una práctica maravillosa. Invierta en las herramientas y prácticas que necesite para poder revisar el código en cuestión de minutos después de que se haya escrito. El programa de pares y la herramienta es simplemente una silla de invitados.

¿Por qué? Cada segundo que pasa después de que escribo código aumenta exponencialmente el costo de cambiarlo. Eso es porque mi memoria del código tiene una vida media. Empiezo a olvidarlo en el momento en que mi vejiga exige un descanso.

Reduce las cosas que te importan a sus principios subyacentes. En lugar de golpearme con una lista de 101 reglas a seguir, dame los 10 principios que violan para que pueda descubrir qué regla 102 debería ser por mi cuenta.

Dame el poder para imponer mi propia visión ayudándome a ver la tuya y nos llevaremos muy bien.

¿Es poco realista de mi parte esperar estándares como este? Lucho con la idea de parecer un dictador que sofoca la creatividad, pero hacer lo que quieran parece no ser escalable.

¡Entonces no dictes! Haz de esto una experiencia positiva. Esto no es una tontería hippy de la nueva era. Es psicología básica. Estás intentando modificar el comportamiento humano. Aleatorio y positivo es el más reforzador (solo pregunte a Las Vegas). Si te vuelves negativo tienes que ser consistente con tu refuerzo. Ese es un dolor inalcanzable. Sea positivo al difundir la sabiduría y puede ser casual al respecto.

Sé de dónde vienes porque he estado allí. Tenías el control y ahora se ha ido. Lo quieres de vuelta. Bueno, supéralo. Ahora tienes un equipo. No necesitan ser controlados. Lo que necesitan es liderazgo. Lo que necesitas no es control. Es influencia. Funciona mejor y es mucho menos trabajo. Domina eso y relájate. Esto debería ser divertido.

Hazlo bien y podrás irte de vacaciones y esto seguirá funcionando. ¿Cómo? No solo por ser un líder, sino también por lograr que los demás sean líderes. Una vez que haya inculcado su visión en el equipo, pueden trabajar mientras usted no está, simplemente imitando lo que ha estado haciendo. Guíe a los novatos y aliéntelos a intensificar e influir en los demás también.

Sé que es duro. No entramos en esta profesión porque somos buenos para tratar con personas. Nos comunicamos mejor con el código. Esta bien. Solo hazlo rápido y con frecuencia. Muéstrame por qué el tuyo es mejor. Escucha si digo que no lo es. Haz esto mientras todavía estoy pensando en ello. Me encanta codificar. Hay pocas personas en el planeta con las que puedo hablar al respecto. Se uno de ellos.


44
Es bastante evidente lo que quiere decir con "acecho de código" ... Pero Google no me da más que leyes de delitos de todo el mundo.
Jeremy

3
agregue "estándares de codificación" a la lista
BЈовић

55
Como parece que estoy introduciendo el término, daré la etimología de 'acecho de código'. Había registrado un código que usaba una fábrica abstracta para obtener sus marcas de tiempo. Un desarrollador de pares estaba tratando de fusionarse (ingresar el código) y se estaba desplazando a través de los cambios de código desde su salida. Ella notó mi fábrica y pensó que era curiosa. No estaba segura de por qué estaba haciendo esto. Entonces ella se acercó y me preguntó. Cuando la miré confundida, ella dijo: "Oh, solo era un código que te acechaba". Facebook está cambiando nuestro vocabulario.
candied_orange

1
¡Cierto! " Dame el poder para imponer mi propia visión ayudándome a ver la tuya y nos llevaremos muy bien " . ¡Me encanta cuando se mezclan poesía, código y filosofía!
Pedro Lobito

@candied_orange: estoy un poco desconcertado por todo el asunto del "acecho de código". ¿La estabas golpeando? En el contexto de tu respuesta, parece que ella sería un código que te acosa.
Robert Harvey

23

Primero, haga que las personas mantengan cosas que no escribieron. Es muy fácil para un desarrollador adquirir hábitos de usar marcos y técnicas a las que está acostumbrado. Es discordante tener que cambiar entre marcos y metodologías. Si alguien se ve obligado a moverse fuera de su propio rincón del código y experimentar eso a menudo, provocará quejas y, con suerte, alguna discusión productiva que pueda llevar a las personas a querer estandarizar algo.

A continuación, extraiga solicitudes y revisiones de código. Nunca permita que el código se fusione con sus sucursales principales sin una revisión de código primero. Cualquiera lo puede hacer. Una vez más, cuando alguien ve algo diferente de lo que hubiera hecho, puede generar discusión y trabajo en equipo para llegar a una mejor solución. También hace que todos cuiden la base del código, lo que (con suerte) hace que las personas se preocupen por él y el estado del código que se incluye.

Finalmente, tenga discusiones de diseño. Pueden ser formales o informales, pero los tienen. Deja que los que quieran participar lo hagan. Discuta qué marcos quiere usar, los pros y los contras de las enumeraciones frente a las entradas, etc. Luego tome una decisión y documente en algún lugar (como un documento estándar). Entonces tienes algo que señalar cuando surgen problemas. Además, no tenga miedo de revisar una decisión estándar. La tecnología cambia (rápidamente) y también sus necesidades como equipo y empresa.

Ayuda a las personas a ver lo que ves y sentir que tienen interés en la calidad del código. Luego empuje suavemente las discusiones para encontrar un estándar cuando surjan diferencias de opinión.


Lo bueno de este método es que el gerente no solo está imponiendo sus preferencias, sino que está dando al equipo la oportunidad de decidir y dándoles el poder para hacer que se cumpla.
Robin Bennett

6

Realice revisiones de código cada vez que alguien quiera fusionar código en la rama / troncal principal y mantener a las personas con esos estándares cuando revise el código.

Y no me refiero a que solo usted deba realizar las revisiones de código. Todos deberían revisar el código de todos los demás. Esto difunde el conocimiento sobre el sistema en todo el equipo, pero también crea una situación en la que Carol revisa el código de Bob y dice: "Veo que usaste un número entero allí. Siempre uso una enumeración". Descubren las discrepancias que has visto y, suponiendo que les importe, se darán cuenta de que todos deben estar en la misma página.

Surgirán los estándares aceptados y acordados, en ese momento los documentará y se asegurará de que las personas los sigan. Esto incluiría cosas como "enumeraciones en la base de datos para ...", etc. También puede incluir documentar qué marcos usar, etc.


Supongo que una gran parte de mi pregunta es si no es realista de mi parte esperar estándares como este. Lucho con la idea de parecer un dictador que sofoca la creatividad, pero hacer lo que quieran no parece escalable
Deekor

3
@Matthew, aunque generalmente estoy de acuerdo con usted, lo haría en orden inverso. Las revisiones de diseño primero, y las pautas surgen de / durante las revisiones de diseño. Si coloca la carga de escribir todo por adelantado en el arquitecto / líder, eso está transfiriendo la carga al interventor .
Nick Alexeev

@Deekor: tienes que elegir tus batallas. Averigua en qué tienes que pisar y documenta eso. No tienes que dictar todo.
Robert Harvey

2
@Deekor, puede aplicar estándares y prácticas de codificación comunes sin "sofocar la creatividad". Ese es un argumento espurio de todos modos. Los estándares de codificación comunes conducen a un software fácil de mantener. La codificación gratuita para todos lleva a pesadillas.
Matthew

1
@Nick Alexeev, estoy de acuerdo; editará
Matthew

1

Siempre que sea posible, puede escribir herramientas / scripts para analizar automáticamente sus proyectos y determinar qué estándares, herramientas y enfoques está utilizando el proyecto. Puede hacerlo ejecutando una herramienta personalizada como parte de una compilación de CI.

Haga que el resultado de las herramientas se escriba en un documento de 'cuadro de mandos', por ejemplo, una hoja de Google con una fila por unidad (por ejemplo, por 'aplicación' o proyecto o api o lo que sea), con columnas para las diferentes métricas / estándares seguidos. Esto le dará a la gente visibilidad sobre qué estándares hay, qué tan bien adoptados están, etc. y proporcionará un cierto orden al caos.

También puede tener columnas actualizadas manualmente, pero buena suerte para mantenerlas actualizadas: D


0

Además de las respuestas proporcionadas, le digo que debe educar a su equipo sobre lo que espera de ellos como profesionales de desarrollo de software, comenzando desde el momento en que se entrevistan para unirse a la empresa.

1 - Crear y seguir convenciones de código base

Esta es una de las medidas más básicas pero beneficiosas que puede adoptar para mejorar la calidad del código. Como resultado de las siguientes convenciones, el código fuente será uniforme en toda la base de código, reduciendo el esfuerzo cognitivo para buscar y leer archivos de código.

2 - Implemente arquitecturas de software claras

La base de código de un proyecto de software que no sigue un estilo arquitectónico claro, sea lo que sea, se deteriora gradualmente a medida que se le agrega un código nuevo y desestructurado, y se vuelve más difícil de modificar. De ahí la importancia de dedicar horas para el diseño y la conservación de una arquitectura de software adecuada.

3 - Menos es mejor: idiomas, marcos y herramientas

Con cada lenguaje, marco y herramienta adicionales que introduce en su sistema, se genera un costo adicional de desarrollo y operación. Siempre debe evaluar los costos a largo plazo de una decisión tecnológica antes de resolver un problema a corto plazo. Evite las tecnologías redundantes y aproveche al máximo su pila actual.

4 - Involucre a su equipo en las decisiones de diseño del sistema

La forma más efectiva de crear un entorno de conocimiento compartido es involucrar al equipo en todas las decisiones de diseño del sistema. Los beneficios son muchos:

  • Las personas se sienten valoradas y parte del equipo.
  • Las decisiones importantes son cuestionadas por todo el equipo antes de tomarlas
  • Las fortalezas y debilidades del diseño del sistema son más claras para todos
  • Crea un sentido de responsabilidad colectiva y confianza

5 - La regla del todo incluido

Considero que los esfuerzos para refactorizar un diseño de sistema deben realizarse hasta su finalización (todo incluido), en lugar de concluirse parcialmente. Existe un gran riesgo de erosionar el diseño de su sistema si los desarrolladores se sienten libres de aplicar diferentes estilos de codificación y patrones arquitectónicos localmente cuando lo consideren conveniente.

En este punto, si ha implementado con éxito las sugerencias anteriores, su equipo probablemente evaluará este comportamiento deshonesto del desarrollador como poco profesional e irresponsable.


Recientemente escribí una publicación de blog sobre este tema, puede encontrar información detallada sobre estos temas allí: https://thomasvilhena.com/2019/11/system-design-coherence

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.