VOLVER
Estaba previsto que este episodio se publicara en diciembre, antes de las vacaciones de Navidad, así que parece que el culpable del retraso soy yo. He ido retrasando la publicación semana tras semana a medida que se interponían algunas tareas de alta prioridad, pero hoy es EL día.
En el último episodio he bromeado con comentar el artículo sobre la importancia del humor en el lugar de trabajo, pero mientras tanto me he dado cuenta de que merece mucho más crédito, así que voy a escribir una entrada entera en el blog sobre ello pronto(ish).
Cosas que me mantuvieron ocupado en las últimas semanas:
a) Antes de Navidad me estrené con un episodio de "Serie de seminarios web "A prueba de balas CTO (permanezca atento al segundo episodio de febrero sobre SaaS) CTOs(próximamente más detalles en mi LinkedIn).
b) Puesta a punto de nuestro plan de crecimiento para 2021 con el objetivo de ir más allá de nuestro negocio principal de Ruby y JS y hacer crecer un negocio de Magento y Producto Competencia en diseño en la empresa.
Basta de autopromoción, permítanme invitarles al 5º episodio de nuestra serie #TheCodestReview.
Temas equipo ha preparado para este momento:
Los comentarios sobre la aplicación frontend y los commits convencionales son entregados esta semana por nuestros ingenieros de React, mientras que Ruby 3.0.0 por nuestro dream team Ruby.
Hoy en día muchos desarrolladores para ahorrar tiempo están utilizando bibliotecas de interfaz de usuario ya hechas y componentes reutilizables. Es una buena práctica y nos ayuda a ahorrar mucho tiempo pero cuando nuestro proyecto se hace más grande - comprenderá que no basta con manejar con código.
Hay dos buenos patrones de desarrollo back-end - Domain Driven Development (DDD) y Separation of Concerns (SoC). También podemos utilizarlos en la arquitectura front-end.
En DDD intentamos agrupar características similares y desacoplarlas en la medida de lo posible de otros grupos (módulos).
Mientras que con SoC, por ejemplo, separamos la lógica, las vistas y los modelos de datos (por ejemplo, utilizando el patrón de diseño MVC o MVVM).
Hay un montón de buenas prácticas y patrones a utilizar, pero esta forma es la preferida para mí.
Cuando utilicemos este patrón obtendremos esta imagen:
Al principio, el enrutamiento de la aplicación redirige al usuario al módulo correcto. Cada módulo está completamente contenido. Pero, como un usuario espera utilizar una aplicación, no varias pequeñas, existirá cierto acoplamiento. Este acoplamiento existe en características específicas o lógica de negocio.
Y tenemos esta estructura:
carpeta app - capa de aplicación
assets - carpeta para imágenes, fuentes, iconos, etc.
componentes - aquí deberían estar los componentes para reutilizar que no tienen una lógica complicada
config - aquí almacenaremos el estado global
lib - carpeta para funciones complicadas y cálculo lógico
módulos - aquí están nuestros módulos
pubsub - lugar para almacenar esquemas para describir la estructura de datos.
styles - para nuestro código css/scss
Esta estructura nos ayudará a manejar nuestra aplicación en crecimiento y a tener menos bugs. También ayudará a hacer más cómodas las partes de trabajo con módulos separados, a probarlos y a hacer más fácil la refactorización y la depuración (debido a los módulos separados).
Si profundizamos en la arquitectura de los módulos y sus conexiones con la API, obtendremos algo parecido:
Si carpeta 'app' vamos a crear otra carpeta 'api' con el código para las llamadas a la API y los datos que vamos a guardar en 'config/store'. Aquí guardaremos los datos estáticos e inmutables que utilizaremos en toda la aplicación.
También en la carpeta 'pubsub/schema' describiremos tipos de datos específicos para JavaScript objetos.
Todos los módulos contienen datos en su interior que necesitamos utilizar (usuarios, rutas, tablas, acciones, etc.). Cada módulo está conectado con la capa de aplicación y toma todos los datos necesarios.
El front-end es el primer punto de entrada para nuestros usuarios. Con nuestros proyectos front-end creciendo en características, también introduciremos más errores. Pero nuestros usuarios esperan que no haya errores y que las nuevas funciones sean rápidas. Esto es imposible. Sin embargo, utilizando una buena arquitectura podemos intentar conseguirlo en la medida de lo posible.
Imagina que estás en el punto de partida de una empresa en la que te acaban de contratar. Toda la gente es amable contigo y todo parece ir bien hasta el momento en que te introducen en una base de código de antes de que JavaScript fuera un lenguaje y Netscape cargara una página durante lo que parecería una eternidad.
La herencia del código parece ser un gran problema cuando se introduce a nuevos desarrolladores en un proyecto. Leer el código es una cosa, pero entender cómo se desarrolló la aplicación no es exactamente lo mismo. A menudo los commits demuestran ser útiles y dan contexto a por qué estos console.logs no fueron capturados por linter o por qué ese desagradable // TODO está ahí para los hijos del desarrollador que inicialmente hizo la anotación.
Empecemos con por qué los commits convencionales son mejores que las reglas de commit no estandarizadas.
Si contratamos nuevos desarrolladores para un proyecto en el que la mayoría de los commits consisten en mensajes del tipo esto debería funcionar o Sleepy fix for footer ASAP ¿qué se te pasa por la cabeza?
Yo diría que las banderas rojas porque:
Debido a que su equipo puede tener reglas personalizadas aplicadas a cuando uno se compromete cambios hay menos margen para el error como su confirmación debe ser sólida. Ya no es sólo una forma de hacer check-out. Es una firma que indica a otras personas que conocías el contenido del commit. No hace falta mencionar que si el trabajo que has hecho no está correctamente firmado lo más probable es que se produzca un error y te aparezca un mensaje
Existe la posibilidad de que tu equipo quiera establecer una regla que no permita ciertas palabras clave, por lo que ASAP o cualquier palabrota pueden estar en la lista negra.
Lo que resulta realmente útil al inicio del proyecto es presentar a todo el mundo cómo su equipo de desarrollo les gustaría que los nuevos desarrolladores confirmaran sus cambios. A continuación, establezca una herramienta que les ayude a mantenerse al día con lo que todos acordaron.
Una de las herramientas con las que he tenido la oportunidad de trabajar ha sido commitlint e hizo de los commits convencionales mi práctica habitual cuando llego a nuevos proyectos que no tienen reglas y el equipo está abierto a la idea de introducirlas.
Cuando se trata de la configuración y su difusión a través de su equipo puede simplemente crear un paquete npm y sólo mpn i -D en cada proyecto. Esto sin duda ayudará a todos en el proyecto para estar en la misma página en todo momento y si es necesario caminar de un proyecto a otro la comprensión de lo que eran los últimos cambios sobre (y por qué se hicieron).
Así que ahora, después de configurarlo todo y entender por qué podría ser una buena idea empezar a usar CC, ¡la mejor parte sería programar alrededor de las reglas que acabas de aplicar! Estamos utilizando una forma estandarizada de cómo nos comprometemos, prestamos más atención a lo que el commit realmente se trataba así que ¿por qué no configurar ganchos que le permiten una prueba rápida en la puesta en escena cuando una bandera está presente? No queremos sobrecargar los servicios y reducir los costes cuando sea necesario y hay algunas razones para probar en el servidor de producción en lugar de localhost.
Supongamos que estás trabajando en PWA y SSL es necesario para que puedas probar todo el potencial y tienes un SSL en tu plataforma de pruebas. Todo lo que necesitas ahora es un buen commit. Algo en la línea de feat(PWA): manifest icons workbox setup upload activaría toda la maquinaria de pruebas y de mover ruedas dentadas. No necesitamos eso cuando sólo subimos algunos datos estáticos como manifest.json así que añadimos una bandera [TEST_SKIP] como postfix a nuestro commit. Esto permite a nuestro CI simplemente subir nuevos activos al entorno de pruebas y saltarse las pruebas. Puedes leer más sobre esto aquí
Después de un tiempo podrás ver otros beneficios, como la facilidad para generar CHANGELOG y un mejor versionado con versionado semántico. Si eso no es suficiente para convencerte de que cambies tu forma de escribir mensajes de compromiso, tal vez sumergir los dedos de los pies en agua fresca y fría e intentar usarlos en tu repositorio privado durante un tiempo te haga cambiar de opinión.
¡Feliz compromiso convencional!
Una versión de Ruby 3.0.0 muy esperada por la comunidad ha visto la luz en Navidad para que todos los desarrolladores de Ruby puedan encontrarla bajo el árbol de Navidad al levantarse por la mañana. En The Codest cultivamos la cultura del intercambio de conocimientos organizando reuniones de desarrollo semanales en las que nuestros ingenieros debaten las tendencias tecnológicas y los nuevos descubrimientos que merecen nuestra atención. A continuación puedes encontrar un enlace a las diapositivas de la jornada de demostración en la que nuestro ingeniero senior de Ruby habló de un par de cambios importantes en Ruby 3.0.0 desde su punto de vista subjetivo:
https://drive.google.com/file/d/1rboAusV1UTWXYMVGuLHx6O90lXrgkmnO/view?usp=sharing
Además, nuestro mentor Ruby ha contribuido a la nueva versión con su pull request que ha sido fusionado con éxito. Más información sobre el tema de los métodos de control de la privacidad en el breve artículo de nuestro Jefe de Desarrollo.
https://thecodest.co/blog/ruby-3-0-ruby-and-lesser-known-privacy-control-methods
Muchas gracias por leer y si has llegado hasta aquí, agradezco tu tiempo y cualquier comentario es más que bienvenido en LinkedIn o a mi correo electrónico.
Volvemos con el próximo episodio a finales de febrero con la revisión de un podcast entrevistando a CTO de Shopify, ¡el hombre detrás de un equipo de ingeniería que trabaja en la magnífica aplicación monolito Ruby!
Nos vemos.
Más información:
TheCodestReview #4 - zumo semanal de ingeniería de software
Spanish 
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
French 
Polish 
Arabic 
Italian 
Japanese 
Korean 
Dutch 
Estonian 
Greek