SWC se enfoca en generar código JavaScript compatible, como Babel, e incluso en el bundling; esto, en cambio, se enfoca en convertir código TypeScript a JavaScript o en revisar errores.
Al escribir código sencillo pero difícil de memorizar (manejo de entrada/salida de archivos, manejo de contenedores, etc.)
Cuando aparecen errores de compilación o de ejecución, para saber qué error es y qué parte del código lo está causando
Cuando quiero reescribir una función parecida a una que ya tenía hecha, pero con una funcionalidad un poco distinta
Cuando quiero reemplazar código que depende de cierta librería por otra librería o sustituirlo por una función propia
Cuando necesito una guía sobre cómo desarrollar para implementar cierta función o trabajar en un entorno específico
En casos como estos, sí me ahorró bastante tiempo. Muchas veces tampoco se encuentra bien con la combinación de Google + Stack Overflow, y en Stack Overflow en particular, aunque haya una respuesta, siempre hay muchos comentarios objetándola o diciendo que es una forma de implementación de una versión antigua y que ya no debería usarse, así que eso me resultaba bastante molesto...
Si se divide en períodos de 1 a 2 semanas, parece natural que solo unas pocas personas conozcan la visión de una sola funcionalidad, como ocurre con la diferencia entre proceso y thread. La idea es aumentar la productividad limitando el foco.
Incluso si se comparte la visión, eso parte de la premisa de que surgirán dudas sobre ella, pero creo que también asumí de forma natural que no se logra alinear cómo se va siguiendo la visión general según la dirección que va cambiando un poco en cada sprint planning.
Si se divide de esta manera en tareas pequeñas, el líder que tiene la visión completa termina teniendo un gran poder. Los ingenieros que trabajan junto a él más bien se desmotivan y quedan pensando: "¿hacia dónde se supone que vamos?". Una desventaja representativa del ágil basado en sprints.
Parece que está escrito demasiado solo desde la perspectiva del líder, tal como dice el título.
El impulso de los ingenieros también se ve muy influido por la dirección hacia la que el líder esté levantando la bandera. Parece que también hace falta pensar un poco más en cómo presentar cuál es el valor que se quiere dar al cliente, y cuál es el output de cada sprint y el outcome de entrega. Por supuesto, son habilidades blandas difíciles, así que es raro ver líderes que lo hagan bien y tampoco hay muchos textos sobre eso.
Entiendo lo de .NET, pero me parece que Rust está en una posición similar a la de Go; supongo que los proyectos y bibliotecas de JS relacionados con Go que ya existían también influyeron en la decisión.
> Si el código de TypeScript deja de escribirse en TypeScript, el equipo podría dejar de usar TypeScript directamente, lo que a largo plazo puede afectar la experiencia de desarrollo.
Dicen que hay que "comer tu propia comida para perros": usar directamente lo que uno mismo creó. Pero en el caso de un lenguaje, sí da un poco para pensarlo.
Sin embargo, para adoptar tecnología moderna (?), JUnit4 a menudo termina siendo un obstáculo, así que personalmente tengo el pequeño deseo de que se migre a JUnit5. https://docs.gradle.com/develocity/test-distribution/
Si usas junit-vintage-engine, puedes ejecutar las pruebas de junit4 en junit5 sin cambios grandes, pero la sobrecarga es considerable. (aproximadamente un 20% más lento)
Como alguien que por azares de la vida terminó asentándose como ingeniero de build de apps Android, si dejara una opinión...
> Build: gradle
Aunque sea muy grande o muy complejo, hay que usar gradle... (mirando al horizonte)
Como se están llevando adelante los siguientes proyectos para mejorar el rendimiento de build de gradle en proyectos muy grandes o complejos, si usan gradle en un proyecto grande conviene ir preparando la migración con anticipación.
> Configuración de módulos: separación por feature
Personalmente, no veo razón para exponer innecesariamente las capas de arquitectura al sistema de build.
En el caso de la app que administro, hacemos que el sistema de build exponga los módulos como feature-api / feature-impl.
feature-app :
Modelo de datos, o interfaces vinculadas con otros módulos
feature-impl:
Implementación real de la feature
Si se configura así, los cambios de código en feature-impl no afectan a otros módulos que referencian feature-api (aislamiento de dependencias), así que ayuda mucho a mejorar el incremental build y la tasa de aciertos del build cache.
> Pruebas unitarias - junit 4
Creo que aquí la decisión de Google tuvo un papel importante.
Parece que la polémica está bastante candente, porque Anders Hejlsberg dejó un comentario personalmente.
https://github.com/microsoft/typescript-go/…
Sí, ¡esa misma!
Alguien que quisiera que al compilar con TypeScript, el resultado saliera directamente como binario
Gracias por compartir este buen material.
SWC se enfoca en generar código JavaScript compatible, como Babel, e incluso en el bundling; esto, en cambio, se enfoca en convertir código TypeScript a JavaScript o en revisar errores.
Se parece mucho a mi propia experiencia.
En casos como estos, sí me ahorró bastante tiempo. Muchas veces tampoco se encuentra bien con la combinación de Google + Stack Overflow, y en Stack Overflow en particular, aunque haya una respuesta, siempre hay muchos comentarios objetándola o diciendo que es una forma de implementación de una versión antigua y que ya no debería usarse, así que eso me resultaba bastante molesto...
Si se divide en períodos de 1 a 2 semanas, parece natural que solo unas pocas personas conozcan la visión de una sola funcionalidad, como ocurre con la diferencia entre proceso y thread. La idea es aumentar la productividad limitando el foco.
Incluso si se comparte la visión, eso parte de la premisa de que surgirán dudas sobre ella, pero creo que también asumí de forma natural que no se logra alinear cómo se va siguiendo la visión general según la dirección que va cambiando un poco en cada sprint planning.
¿No será que se trata de compartir la visión general y, una vez que todos la entienden, dividir el trabajo en tareas pequeñas?
Gracias por el buen artículo.
Si se divide de esta manera en tareas pequeñas, el líder que tiene la visión completa termina teniendo un gran poder. Los ingenieros que trabajan junto a él más bien se desmotivan y quedan pensando: "¿hacia dónde se supone que vamos?". Una desventaja representativa del ágil basado en sprints.
Parece que está escrito demasiado solo desde la perspectiva del líder, tal como dice el título.
El impulso de los ingenieros también se ve muy influido por la dirección hacia la que el líder esté levantando la bandera. Parece que también hace falta pensar un poco más en cómo presentar cuál es el valor que se quiere dar al cliente, y cuál es el output de cada sprint y el outcome de entrega. Por supuesto, son habilidades blandas difíciles, así que es raro ver líderes que lo hagan bien y tampoco hay muchos textos sobre eso.
No sé mucho de frontend... ¿es diferente de
swc?Ahora mismo son las 8:40 de la mañana y, por casualidad, veo que son exactamente las 7:40:28 PM EST... qué curioso
Visitar McDonald's parece que será fácil. Parece que será una experiencia divertida.
Entiendo lo de .NET, pero me parece que Rust está en una posición similar a la de Go; supongo que los proyectos y bibliotecas de JS relacionados con Go que ya existían también influyeron en la decisión.
La idea es realmente muy novedosa, pero como en otros comentarios también me pregunto cómo van a resolver que se concentre tanto tráfico.
Parece que te refieres a un runtime como Node, pero aquí se está hablando del compilador del propio lenguaje TS.
> Si el código de TypeScript deja de escribirse en TypeScript, el equipo podría dejar de usar TypeScript directamente, lo que a largo plazo puede afectar la experiencia de desarrollo.
Dicen que hay que "comer tu propia comida para perros": usar directamente lo que uno mismo creó. Pero en el caso de un lenguaje, sí da un poco para pensarlo.
Sin embargo, para adoptar tecnología moderna (?), JUnit4 a menudo termina siendo un obstáculo, así que personalmente tengo el pequeño deseo de que se migre a JUnit5.
https://docs.gradle.com/develocity/test-distribution/
Si usas
junit-vintage-engine, puedes ejecutar las pruebas de junit4 en junit5 sin cambios grandes, pero la sobrecarga es considerable. (aproximadamente un 20% más lento)Como alguien que por azares de la vida terminó asentándose como ingeniero de build de apps Android, si dejara una opinión...
> Build: gradle
Aunque sea muy grande o muy complejo, hay que usar gradle... (mirando al horizonte)
Como se están llevando adelante los siguientes proyectos para mejorar el rendimiento de build de gradle en proyectos muy grandes o complejos, si usan gradle en un proyecto grande conviene ir preparando la migración con anticipación.
> Configuración de módulos: separación por feature
Personalmente, no veo razón para exponer innecesariamente las capas de arquitectura al sistema de build.
En el caso de la app que administro, hacemos que el sistema de build exponga los módulos como feature-api / feature-impl.
Si se configura así, los cambios de código en feature-impl no afectan a otros módulos que referencian feature-api (aislamiento de dependencias), así que ayuda mucho a mejorar el incremental build y la tasa de aciertos del build cache.
> Pruebas unitarias - junit 4
Creo que aquí la decisión de Google tuvo un papel importante.
Sin embargo, el plugin de screenshot testing lanzado recientemente está basado en JUnit5.
Parece Clubhouse; de hecho, eso mismo fue lo primero que se me vino a la mente.