Desde esta perspectiva, quizá documentos como los ADR (Architecture Decision Records) o los CIR (Change Intent Records) podrían llegar a ser tratados como algo incluso más valioso que el propio código.
En comparación con el desarrollo, se necesita un ciclo de retroalimentación muchísimo más rápido y frecuente.
Como el desarrollador está al final del ciclo de trabajo, creo que también hay un aspecto en el que su rol dentro del equipo tiende a sobredimensionarse.
He oído que ahora hasta dicen que los desarrolladores también tienen que encargarse del diseño usando Claude Code, pero ¿el diseño no necesita revisión/validación?
Desde antes he estado usando el conjunto de rolldown, oxlint y oxfmt, y tanto la velocidad como el resultado me han dejado muy satisfecho.
oxc-minify de oxc sigue en alfa, pero igual lo estoy usando con toda confianza.
Me gustó que el Bloc de notas tuviera soporte para pestañas y que Paint agregara transparencia y capas, pero sí que cada vez le están metiendo más cosas.
Pero depende del área: hay casos donde el código de pruebas casi no tiene cobertura, así que sí da para pensarlo. También da la impresión de que en ese lado todavía no logran hacer buen código tan bien como en otros campos.
Yo también comento mucho esto con la gente de mi entorno, pero al final, como más adelante será difícil revisar todo el código, creo que si no se prueba sí o sí la lógica realmente importante, puede terminar muy mal.
También se agregó al final del texto, y se comentó que tldraw también ejecuta sus pruebas en privado (aunque dicen que era una broma). https://github.com/tldraw/tldraw/issues/8082
Si ven Cómo se prueba SQLite,
SQLite es completamente abierto, pero tiene código de pruebas 590 veces más grande que el código fuente, y eso es totalmente privado.
Tiene 100% de cobertura de ramas, cientos de miles de casos de prueba y ejecuta más de mil millones de pruebas de mutación.
Creo que la idea central de "las pruebas por encima del código fuente" realmente tiene mucho sentido. Pero no estoy seguro de que funcione una estrategia de abrir solo el código fuente sin abrir también las pruebas. También parece probable que se les dé bien extraer casos de prueba a partir del código fuente...
Desde esta perspectiva, quizá documentos como los ADR (Architecture Decision Records) o los CIR (Change Intent Records) podrían llegar a ser tratados como algo incluso más valioso que el propio código.
Vaya, de verdad toma muy buenas fotos...
¿No sería mejor llevar una configuración explícita como
skillsen lugar de dejarlo en memoria?En comparación con el desarrollo, se necesita un ciclo de retroalimentación muchísimo más rápido y frecuente.
Como el desarrollador está al final del ciclo de trabajo, creo que también hay un aspecto en el que su rol dentro del equipo tiende a sobredimensionarse.
Es demasiado conveniente encubrir superficialmente los despidos diciendo que son por la IA.
Parece que la transición desde un rol similar al de un técnico tradicional hacia el de experto en dominio se está acelerando aún más.
Biome también era rapidísimo, pero que esto sea 3 veces más rápido que eso es impresionante.
Wow, gracias. Seguiremos mejorándolo.
Es una buena frase para personas como yo, a quienes se les dificulta ejecutar bien las cosas.
He oído que ahora hasta dicen que los desarrolladores también tienen que encargarse del diseño usando Claude Code, pero ¿el diseño no necesita revisión/validación?
Creo que los artículos recomendados para ver juntos están muy buenos.
Desde antes he estado usando el conjunto de rolldown, oxlint y oxfmt, y tanto la velocidad como el resultado me han dejado muy satisfecho.
oxc-minify de oxc sigue en alfa, pero igual lo estoy usando con toda confianza.
Me gustó que el Bloc de notas tuviera soporte para pestañas y que Paint agregara transparencia y capas, pero sí que cada vez le están metiendo más cosas.
Vaya, ya veo. Solo vi la parte de arriba jaja
Entré al tema y lo leí, y dicen que "es broma".
Pero depende del área: hay casos donde el código de pruebas casi no tiene cobertura, así que sí da para pensarlo. También da la impresión de que en ese lado todavía no logran hacer buen código tan bien como en otros campos.
Yo también comento mucho esto con la gente de mi entorno, pero al final, como más adelante será difícil revisar todo el código, creo que si no se prueba sí o sí la lógica realmente importante, puede terminar muy mal.
También se agregó al final del texto, y se comentó que
tldrawtambién ejecuta sus pruebas en privado (aunque dicen que era una broma).https://github.com/tldraw/tldraw/issues/8082
Si ven Cómo se prueba SQLite,
SQLite es completamente abierto, pero tiene código de pruebas 590 veces más grande que el código fuente, y eso es totalmente privado.
Tiene 100% de cobertura de ramas, cientos de miles de casos de prueba y ejecuta más de mil millones de pruebas de mutación.
¡Ánimo!
Creo que la idea central de "las pruebas por encima del código fuente" realmente tiene mucho sentido. Pero no estoy seguro de que funcione una estrategia de abrir solo el código fuente sin abrir también las pruebas. También parece probable que se les dé bien extraer casos de prueba a partir del código fuente...