Apoyados en referencias
Convenciones de la comunidad, opiniones de expertos reconocidos, libros y artículos que podemos citar. No preferencias personales disfrazadas de hecho.
A veces lo más útil es una mirada lúcida desde afuera del equipo. Heredaste un sistema que no escribiste. La dirección está evaluando si reescribir, refactorizar o dejarlo como está. Algo no termina de cerrar y nadie en el equipo logra ponerle nombre. Una revisión técnica es un trabajo acotado, con tiempos definidos, que termina en un informe real sobre el estado de tu código: no una presentación, no una devolución verbal, sino un documento que tu equipo puede leer, discutir y usar después de que nos vayamos.
Qué incluye el informe
La extensión y la profundidad varían según el alcance. Solemos abrir con una vista general del sistema, incluyendo cómo un equipo de ingeniería externo lee tu aplicación y, cuando el acceso lo permite, la arquitectura más amplia. De ahí pasamos al análisis estático, con nuestra lectura de qué señalan las mejores herramientas de tu ecosistema y qué es ruido, y a las dependencias: qué estás incorporando, qué tan actualizado está, dónde está el riesgo y dónde estás arrastrando cosas que no necesitás.
La revisión manual del código suele ser la sección más extensa. Analizamos el uso idiomático del lenguaje y del framework, la organización del código y su acoplamiento, las partes más difíciles de entender y la deuda técnica que podemos nombrar y describir. Revisamos secciones representativas en profundidad y, a partir de ahí, generalizamos al resto del código.
La suite de tests, la ergonomía de desarrollo y las observaciones sobre performance y seguridad completan el cuerpo del informe. Según el acceso que tengamos y lo que más te interese responder, también podemos opinar sobre el modelado de la base de datos, la infrastructure-as-code o el sistema en producción. Las reflexiones finales cierran con un resumen de fortalezas, debilidades y lo que priorizaríamos.
Cómo encaramos el trabajo
Una revisión técnica suele llevar entre dos y tres semanas. Empezamos poniéndonos de acuerdo sobre las preguntas que más te interesa responder: reescribir o refactorizar, la preocupación por escalar, orientar a un CTO recién llegado, la verificación previa a una inversión. El alcance es finito, así que acordamos de antemano qué entra y qué queda afuera.
Profundizamos en partes representativas del código y a partir de ahí generalizamos. Nos apoyamos en el tooling que tu ecosistema ya tiene y sumamos el nuestro cuando ayuda, incluida la IA para detectar patrones y observaciones más rápido en un código grande. Nada de eso reemplaza el juicio humano, y es sobre ese juicio que se apoya el informe. Trabajamos junto a tu equipo, no por encima. El objetivo no es agarrar a nadie en falta, sino mostrar lo que vería un ingeniero externo, alguien que mira de afuera, y dejarlo por escrito de una forma útil para quienes están adentro.
Dónde hacemos estas revisiones
Hacemos revisiones técnicas en las tecnologías que conocemos a fondo: Ruby on Rails, Elixir/Phoenix, Rust y el stack moderno de JavaScript/TypeScript con el que trabajamos todos los días. El valor de una mirada externa depende de que quien revisa sea realmente experto en el lenguaje y el framework, así que no tomamos revisiones de stacks que no dominamos.
Si tu código está en un terreno donde no podemos aportar valor real, te lo decimos de entrada en lugar de aprender a tu costa.
Dónde nos movemos con fluidez
- Rails
- Phoenix
- Rust
- TypeScript / JS
Cómo escribimos estos informes
Honestos cuando es opinión
Cuando hablamos desde la experiencia o el gusto, lo decimos sin vueltas y lo planteamos como una posibilidad entre otras.
Alternativas, no veredictos
Cuando nosotros haríamos algo distinto, contamos qué haríamos y por qué, y dejamos que quien lee saque su propia conclusión.
Clientes que nos pidieron una revisión técnica
Argos
WyeWorks renovó la plataforma educativa de Argos, mejorando el codebase de Elixir y LiveView e incorporando SSO y pagos.
ElixirDesarrollo frontend
Flavorpill
WyeWorks ayudó a Flavorpill a lograr un aumento de 18x en usuarios concurrentes y reducir drásticamente los tiempos de respuesta.
Desarrollo backendConsultoría de procesos
Construyamos juntos.
¿Listo para una lectura lúcida de tu código sobre la que vos y tu equipo realmente puedan actuar?
A veces lo más útil es una mirada lúcida desde afuera del equipo. Heredaste un sistema que no escribiste. La dirección está evaluando si reescribir, refactorizar o dejarlo como está. Algo no termina de cerrar y nadie en el equipo logra ponerle nombre. Una revisión técnica es un trabajo acotado, con tiempos definidos, que termina en un informe real sobre el estado de tu código: no una presentación, no una devolución verbal, sino un documento que tu equipo puede leer, discutir y usar después de que nos vayamos.
Qué incluye el informe
La extensión y la profundidad varían según el alcance. Solemos abrir con una vista general del sistema, incluyendo cómo un equipo de ingeniería externo lee tu aplicación y, cuando el acceso lo permite, la arquitectura más amplia. De ahí pasamos al análisis estático, con nuestra lectura de qué señalan las mejores herramientas de tu ecosistema y qué es ruido, y a las dependencias: qué estás incorporando, qué tan actualizado está, dónde está el riesgo y dónde estás arrastrando cosas que no necesitás.
La revisión manual del código suele ser la sección más extensa. Analizamos el uso idiomático del lenguaje y del framework, la organización del código y su acoplamiento, las partes más difíciles de entender y la deuda técnica que podemos nombrar y describir. Revisamos secciones representativas en profundidad y, a partir de ahí, generalizamos al resto del código.
La suite de tests, la ergonomía de desarrollo y las observaciones sobre performance y seguridad completan el cuerpo del informe. Según el acceso que tengamos y lo que más te interese responder, también podemos opinar sobre el modelado de la base de datos, la infrastructure-as-code o el sistema en producción. Las reflexiones finales cierran con un resumen de fortalezas, debilidades y lo que priorizaríamos.
Cómo encaramos el trabajo
Una revisión técnica suele llevar entre dos y tres semanas. Empezamos poniéndonos de acuerdo sobre las preguntas que más te interesa responder: reescribir o refactorizar, la preocupación por escalar, orientar a un CTO recién llegado, la verificación previa a una inversión. El alcance es finito, así que acordamos de antemano qué entra y qué queda afuera.
Profundizamos en partes representativas del código y a partir de ahí generalizamos. Nos apoyamos en el tooling que tu ecosistema ya tiene y sumamos el nuestro cuando ayuda, incluida la IA para detectar patrones y observaciones más rápido en un código grande. Nada de eso reemplaza el juicio humano, y es sobre ese juicio que se apoya el informe. Trabajamos junto a tu equipo, no por encima. El objetivo no es agarrar a nadie en falta, sino mostrar lo que vería un ingeniero externo, alguien que mira de afuera, y dejarlo por escrito de una forma útil para quienes están adentro.
Dónde hacemos estas revisiones
Hacemos revisiones técnicas en las tecnologías que conocemos a fondo: Ruby on Rails, Elixir/Phoenix, Rust y el stack moderno de JavaScript/TypeScript con el que trabajamos todos los días. El valor de una mirada externa depende de que quien revisa sea realmente experto en el lenguaje y el framework, así que no tomamos revisiones de stacks que no dominamos.
Si tu código está en un terreno donde no podemos aportar valor real, te lo decimos de entrada en lugar de aprender a tu costa.
Dónde nos movemos con fluidez
- Rails
- Phoenix
- Rust
- TypeScript / JS
Cómo escribimos estos informes
Apoyados en referencias
Convenciones de la comunidad, opiniones de expertos reconocidos, libros y artículos que podemos citar. No preferencias personales disfrazadas de hecho.
Honestos cuando es opinión
Cuando hablamos desde la experiencia o el gusto, lo decimos sin vueltas y lo planteamos como una posibilidad entre otras.
Alternativas, no veredictos
Cuando nosotros haríamos algo distinto, contamos qué haríamos y por qué, y dejamos que quien lee saque su propia conclusión.
Clientes que nos pidieron una revisión técnica
Argos
WyeWorks renovó la plataforma educativa de Argos, mejorando el codebase de Elixir y LiveView e incorporando SSO y pagos.
ElixirDesarrollo frontend
Construyamos juntos.
¿Listo para una lectura lúcida de tu código sobre la que vos y tu equipo realmente puedan actuar?