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 llegan de la mano de nuestro Ruby and React ingenieros.

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 and inspired by the MVVM architecture, he shows the advantages of its solution very accurately. Going from basic configuration, he goes through each folder while explaining on a case-by-case basis why he considers this approach appropriate. The approach itself seems quite complicated and probably unnecessary at first when the project is at the early stage but let’s remember that introducing the appropriate rules from the start will help us avoid time-consuming re-structures while expanding the project with new components and functionalities. A properly selected project structure will also allow new members of the project to easily acquire components and services.  Let’s not forget that not every way to structurize will perfectly fit in every project.
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.