TheCodestReview #2 - zumo semanal de ingeniería de software

Glosario de aspectos que abordamos:

1. Consejos de refactorización en aras de una mejora de la calidad.

2. ¿Por qué es importante la arquitectura del frontend y cómo hacerla escalable y mantenible?

3. Transición de CTO a Director de Operaciones en una organización tecnológica.

Si le interesa el tema de pasar de ser un líder tecnológico a desempeñar una función operativa, puede profundizar en los recursos adicionales enlazados al final de la entrada.

Los comentarios sobre refactorización y arquitectura de esta semana corren a cargo de nuestros ingenieros de Ruby y React.

Stephen Bigelow, de Search Software Quality

Refactorización código siempre ha sido tremendamente popular, pero no todo el mundo sabe cómo hacerlo bien y cuándo es un buen momento para hacerlo. He visto muchos intentos de refactorización que han acabado en fracaso (especialmente en producción, lo cual no es algo de lo que estar orgulloso). Aprender consejos del artículo mencionado podría ayudar a muchos programadores a mejorar sus habilidades cruciales de refactorización.

El consejo número uno del artículo es "entender el código", que es siempre la primera cosa en mi lista antes de refactorizar. No crearás un código mejor si no sabes lo que hace el código actual. Entender el código desordenado puede suponer un esfuerzo, pero es el precio que hay que pagar para mejorar la base de código. Aun así, la rentabilidad de esta inversión es alta y merecerá la pena.

El siguiente consejo que vale la pena mencionar es "probar pronto y a menudo", que podría aplicarse no sólo en el contexto de la refactorización, sino también en el trabajo diario de los desarrolladores. El tema de las pruebas es enorme. No se trata sólo de aprender la sintaxis sobre cómo escribir pruebas, sino que también hay que distinguir los tipos de pruebas. Para aprender más sobre las pruebas, te recomiendo que te familiarices con la pirámide de pruebas y, a continuación, conozcas las diferencias entre las escuelas clásica y londinense.

En resumen, el artículo se centra en la refactorización local, que es buena y podría mejorar la felicidad de los programadores con su trabajo. Aunque para crear una aplicación de primer nivel a nivel de arquitectura, tienes que ir más allá del alcance de este artículo y aprender sobre temas relacionados con la arquitectura de aplicaciones. Esto puede ayudarte a empezar a salir de un viaje sin fin y eso es lo que os deseo a todos, yo incluido.

Michael McShinsky de dev.to

¿Cómo conseguir una arquitectura más escalable y mantenible?

¿Modo adecuado de estructurar su aplicación basándose en la arquitectura MVVM?

¿Cómo evitar el trabajo extra a medida que crece tu aplicación?

Probablemente todo el mundo se ha encontrado en su carrera con un caso en el que una mala arquitectura ha alargado considerablemente el tiempo necesario para completar una tarea. El desorden en las carpetas, la incoherencia en la nomenclatura de archivos o catálogos pueden sabotear el proyecto desde el principio.

El autor del artículo muestra claramente las ventajas de elegir el enfoque adecuado para la estructura del proyecto. Empezando por el crear-react-app e inspirado en la arquitectura MVVM, muestra las ventajas de su solución de forma muy precisa. Partiendo de una configuración básica, recorre cada carpeta explicando caso por caso por qué considera adecuado este enfoque. El enfoque en sí parece bastante complicado y probablemente innecesario al principio, cuando el proyecto se encuentra en una fase inicial, pero recordemos que introducir las reglas adecuadas desde el principio nos ayudará a evitar reestructuraciones que nos llevarán mucho tiempo mientras ampliamos el proyecto con nuevos componentes y funcionalidades. Una estructura de proyecto correctamente seleccionada también permitirá a los nuevos miembros del proyecto adquirir fácilmente componentes y servicios. No olvidemos que no todas las formas de estructurar encajarán perfectamente en todos los proyectos.
Por mi parte, me gustaría añadir la regla básica de que elegir la arquitectura óptima para el proyecto será inútil si no todos los miembros del equipo siguen las normas establecidas.

Más información: ¿Cómo mejorar las aplicaciones Vue.js? Algunos consejos prácticos

Guillaume Clement de Dailymotion

La transición de CTO a COO.

Trabajar en un entorno totalmente remoto. Cómo mantener la equipo energizados e implicados.

Confiar en los datos frente a la intuición.

En el episodio 236 de Modern CTO, Joel habla con Guillaume Clement, Director de Operaciones de Dailymotion. Dailymotion tiene la misión de ser una plataforma de contenidos de vídeo significativa y nutritiva entre una serie de plataformas que están puramente orientadas al entretenimiento y sirven al propósito de "comida rápida de vídeo". Para lograrlo, en un negocio que se rige en gran medida por algoritmos e ingeniería de ciencia de datos, hay que tomar decisiones difíciles basadas en la intuición y no en los datos.

La métrica típicamente precisa para plataformas de vídeo, medios de comunicación y Adtech negocios como el "tiempo invertido" no es el KPI obvio en el que trabajar si realmente te esfuerzas por ofrecer a tus usuarios contenidos significativos, no sólo quieres mantener su atención frente a la pantalla el mayor tiempo posible. La referencia al documental "The Social Dilemma" de Netflix es inevitable. Guillaume también ha pasado recientemente de CTO a COO en la empresa, lo que supone nuevos retos en operaciones y gestión de personal. El reto es aún más exigente durante la pandemia, cuando la instalación remota es una prueba para los líderes a la hora de mantener a los equipos implicados y las mentalidades a alto nivel. Atender a las necesidades individuales de los empleados más sociables o más introvertidos es clave, con una cantidad limitada de tiempo en la oficina para aquellos que necesitan un estímulo regular para ponerse en marcha.