TecNoticias, tu portal de información

Trabajar en equipos pequeños e independientes puede ser complicado para los ingenieros. En mi experiencia como ingeniero en Curve, un rápido crecimiento en el sector fintech, a menudo he encontrado que diferentes equipos tienden a usar enfoques completamente diferentes. Esto puede hacer que los equipos en movimiento y las comunicaciones entre equipos sean un desafío.
En Curve, usamos Golang (o Go para abreviar) para la programación. Go es un lenguaje de programación de código abierto que facilita la creación de software simple, confiable y eficiente.
Trabajar con lenguaje de código abierto en múltiples equipos puede presentar su propio conjunto único de desafíos. Por ejemplo, pueden surgir muchos problemas por diferencias en la estructura y la conformidad con diferentes estándares. Intentar mantener altos estándares de calidad de código y, al mismo tiempo, garantizar que cada proyecto siga las mejores prácticas puede ser difícil.
Compartir una estructura de proyecto definida con el equipo puede ayudar a superar tales desafíos. También puede aumentar la productividad cuando se trabaja con lenguajes de código abierto como Go.
Cuando esto sucede, todos los proyectos comienzan a parecerse más, lo que facilita mucho la transición entre equipos. También es más fácil que los miembros del proyecto contribuyan porque los Gophers experimentados (eso es lo que llamamos nuestros ingenieros de Go) pueden aprender lo que está sucediendo simplemente mirando el archivo o directorio relevante.
Una estructura de proyecto claramente definida también puede ayudar a los nuevos desarrolladores de Go, ya que es más fácil seguir los estándares establecidos. Los nuevos miembros del equipo pueden hacer cambios y replicarlos en otros proyectos sin necesidad de aprender cómo se comporta un servicio.
La pregunta es, ¿cómo hace para lograr esto en su organización?
Hay dos opciones a su disposición. El primero implica el uso de un marco como go-kit o go-micro para sugerir una estructura y enfoques.
Las ventajas de usar este tipo de marco incluyen la disponibilidad de utilidades listas para usar (registro, rastreo) y estándares que ya se han acordado de antemano y se han compartido abiertamente con la comunidad. Sin embargo, hay algunas desventajas en este método. ¿La baja? Tales marcos vienen con muchas repeticiones y puede ser difícil hacer cambios en los componentes principales. El hecho de que sean administrados por la comunidad también significa que los archivos binarios tendrán tamaños más grandes debido a que esperan demasiado los cambios.
La segunda opción es simplemente acordar una estructura de proyecto a nivel de empresa. Al hacer esto, tiene la libertad de usar cualquier enfoque o biblioteca, puede hacer cambios rápidos, tener binarios más pequeños y un Go idiomático fácil de seguir. Una desventaja potencial de esto es que la cultura de ingeniería de la empresa debe ser lo suficientemente madura como para promover un proceso de acuerdo y aplicación de estos cambios. Un proceso tan largo y tedioso podría hacer que otros ingenieros se pregunten si vale la pena, pero algunos estándares ocurren naturalmente y evolucionan con el tiempo, y no hay nada de malo en revisar los estándares acordados después de descubrir más.
En Curve, elegimos este segundo enfoque, que no estuvo exento de desafíos. Por ejemplo, el proceso del acuerdo tomó varios meses, debido a múltiples reuniones y largas discusiones. En una empresa de rápido crecimiento, esto puede afectar enormemente los niveles de productividad. No contar con un marco claro también ha significado que el equipo ha tenido que implementar manualmente elementos que normalmente serían utilizables "listos para usar" y, en ocasiones, ha habido casos de código replicado accidentalmente en múltiples servicios.
A menudo se trataba de aprender sobre la marcha y la mayoría de las decisiones se tomaron después de recibir comentarios de los ingenieros en función de su experiencia diaria, vigilar a la comunidad e investigar qué hacen otras empresas exitosas basadas en Go.
La adopción de este método ha llevado a importantes mejoras a lo largo del tiempo. Ahora hemos configurado un "Capítulo Go" para tomar decisiones relacionadas con Go, formadas por un equipo central de ingenieros. Se reúnen cada dos semanas para discutir temas relevantes y votar sobre la adopción de nuevas normas propuestas. Cada equipo lo adopta para todos los nuevos servicios y asigna tiempo de forma autónoma para refactorizar su proyecto para seguirlo también.
Cuando se trata de la estructura del proyecto, discutimos todos los temas varias veces antes de adoptarlos. También revisamos y modificamos el proceso tantas veces como sea necesario para asegurar que cumplan con los objetivos comerciales.
Hasta ahora, este nuevo enfoque está funcionando bien para nosotros. Significa que podemos enviar servicios estables y de alta calidad con mayor frecuencia, y nos permite simplificar la transferencia. Esto facilita que todos los ingenieros sepan qué hacer y cómo resolver problemas y encontrar errores.
Sin embargo, también hemos identificado dos inconvenientes:
la refactorización de servicios heredados
replicar cambios en los servicios existentes.
Con respecto a esto último, recientemente revisamos nuestra estrategia de registro y monitoreo y tuvimos que "tocar" todos nuestros servicios para seguirla.
Mantener este enfoque ha sido relativamente sencillo hasta ahora. Un ingeniero puede encontrar una nueva y mejor manera de resolver un problema de servicio relacionado con la estructura y la reutilización de código. Después de la experimentación y la retroalimentación de los compañeros de equipo, el ingeniero puede proponerlo durante el "Capítulo Ir".
Un ejemplo reciente de esto es que decidimos dividir nuestros niveles de transporte en función de la necesidad de un servicio para usar http en lugar de grpc o potencialmente ambos. Descubrimos una excelente manera de facilitar esto y fue aprobado.
Esta estructura de proyecto también podría funcionar para usted si su equipo o empresa son lo suficientemente maduros y están dispuestos a cometer errores para aprender y mejorar sus servicios. Requiere una comunicación clara y un trabajo duro, pero finalmente vale la pena el esfuerzo para un proceso simplificado.
¿Está interesado en escuchar a los líderes de la industria discutir temas como este y compartir sus casos de uso? Asista a la 5G Expo, IoT Tech Expo, Blockchain Expo, AI & Big Data Expo y Cyber ​​Security & Cloud Expo World Series con eventos próximos en Silicon Valley, Londres y Amsterdam.
Historias relacionadas