원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
Al desarrollar frontend solo, sin un mentor, uno se siente perseguido por la incertidumbre técnica. Se repite un patrón en el que se tiene el libro de Clean Code al lado, se piensa en una abstracción perfecta y, al final, se sufre un desgaste (burnout) justo antes de la fecha límite del sprint. Lo que se necesita no es una arquitectura impecable, sino criterios realistas para entregar un producto que funcione a tiempo.
Sandy Metz, experta en diseño de software, señala que el costo de eliminar una abstracción incorrecta es mucho mayor que el costo de mantener código duplicado. De hecho, Dan Abramov también advirtió que la eliminación excesiva de duplicación arruina la flexibilidad de los componentes.
Los problemas causados por una simple copia de código se pueden corregir dentro del archivo correspondiente en unos 50 minutos. Por el contrario, un hook común creado prematuramente o una estructura de herencia genera numerosas ramificaciones if-else con el más mínimo cambio en los requisitos. Al final, encontrar los errores lleva más de dos semanas.
La decisión de refactorizar se toma basándose en el cuadrante de deuda técnica de Martin Fowler y en el análisis de puntos críticos (hotspots) de Adam Tornhill.
| Área | Criterio (Complejidad y Frecuencia de cambio) | Forma de respuesta |
|---|---|---|
| Modificación inmediata | Alto impacto en el negocio × Alta frecuencia de cambio | Escribir pruebas y organizar interfaces inmediatamente después de implementar la función, luego desplegar |
| Modificación opcional | Alto impacto en el negocio × Baja frecuencia de cambio | Registrar como ticket de deuda en el backlog |
| Desplegar por ahora | Bajo impacto en el negocio × Alta frecuencia de cambio | Verificar solo el funcionamiento mínimo y desplegar, prohibida la abstracción |
| Posponer trabajo | Bajo impacto en el negocio × Baja frecuencia de cambio | Omitir la modificación aunque el código esté desordenado |
Al aplicar este criterio, puedes reducir el tiempo dedicado a trabajos de generalización innecesarios y acelerar la velocidad general de desarrollo.
Las observaciones de estilo como nombres de variables, saltos de línea o violaciones de reglas de lint deben filtrarse con herramientas.
Según un estudio de SmartBear que analizó 2,500 revisiones de código en Cisco Systems, entre el 70% y el 90% de los defectos se descubren cuando el volumen de código revisado a la vez es inferior a 200 líneas. Si el autor deja un comentario explicando el motivo del cambio directamente en el PR, la densidad de defectos se reduce en promedio un 30%.
`javascript
// eslint.config.js
import js from "@eslint/js";
import globals from "globals";
import tseslint from "typescript-eslint";
import pluginReact from "eslint-plugin-react";
import pluginReactHooks from "eslint-plugin-react-hooks";
import eslintConfigPrettier from "eslint-config-prettier/flat";
export default tseslint.config(
{ ignores: ["dist/", "node_modules/", "build/"] },
js.configs.recommended,
...tseslint.configs.recommended,
pluginReact.configs.flat.recommended,
eslintConfigPrettier,
{
files: ["**/*.{js,jsx,ts,tsx}"],
languageOptions: {
ecmaVersion: "latest",
sourceType: "module",
globals: globals.browser,
},
plugins: {
"react-hooks": pluginReactHooks,
},
rules: {
"react/react-in-jsx-scope": "off",
"react/prop-types": "off",
"react-hooks/rules-of-hooks": "error",
"react-hooks/exhaustive-deps": "warn",
"@typescript-eslint/no-unused-vars": ["error", { argsIgnorePattern: "^_" }],
"@typescript-eslint/no-explicit-any": "warn",
},
settings: {
react: { version: "detect" },
},
}
);
`
Aplicar esta configuración al repositorio te permite reducir los comentarios de revisión relacionados con el estilo y concentrarte en la validación de la lógica real.
Modificar la estructura mientras se desarrolla una funcionalidad desorganiza el contexto del trabajo. Según investigaciones de ingeniería de Google, cuando los PR se dividen en unidades pequeñas y se especifica la intención del trabajo, el tiempo de espera para la revisión del código se reduce de 48 horas a 4 horas.
El tiempo de trabajo diario se controla dividiéndolo en sesiones.
`markdown
`
Esto induce a los revisores a centrar sus comentarios en la lógica central en lugar de en estilos secundarios, acortando el tiempo de aprobación.
Reescribir por completo el código existente aumenta el riesgo de que ocurran fallos en el entorno de producción. Michael Feathers aconseja que al modificar código legacy, en lugar de cambiar toda la estructura, primero se deben escribir pruebas de caracterización que fijen el comportamiento actual de entrada y salida.
Para evitar que toda la pantalla se quede en blanco cuando ocurre un error en tiempo de ejecución, se configura un límite de errores (ErrorBoundary).
`typescript
// components/ErrorBoundary.tsx
import React, { Component, ErrorInfo, ReactNode } from "react";
import * as Sentry from "@sentry/react";
interface Props {
children: ReactNode;
fallbackUI?: ReactNode;
}
interface State {
hasError: boolean;
}
export class GlobalErrorBoundary extends Component<Props, State> {
public state: State = { hasError: false };
public static getDerivedStateFromError(_: Error): State {
return { hasError: true };
}
public componentDidCatch(error: Error, errorInfo: ErrorInfo) {
Sentry.captureException(error, { extra: { componentStack: errorInfo.componentStack } });
}
public render() {
if (this.state.hasError) {
return (
this.props.fallbackUI || (
새로고침을 하거나 잠시 후 다시 시도해 주세요.
`
`bash
git revert HEAD --no-edit
git push origin main
`
Dividir las unidades de trabajo en partes pequeñas y crear un entorno al que se pueda volver en caso de fallo permite controlar la ansiedad ante la modificación de código. Entregar a tiempo un sistema que funciona, en lugar de una estructura perfecta, es la base de la ingeniería práctica.
