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.
Respuestas:
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.
¡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.
fuente
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.
fuente
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.
fuente
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
fuente
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:
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
fuente