원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
Ao desenvolver frontend sozinho sem um mentor, você é perseguido pela ansiedade técnica. O padrão de manter um livro de Clean Code ao lado, ponderar sobre abstrações perfeitas e acabar sofrendo de esgotamento (burnout) logo antes do prazo da sprint se repete. O que é necessário não é uma arquitetura imaculada, mas critérios realistas para entregar um produto funcional no prazo.
Sandy Metz, especialista em design de software, aponta que o custo de remover abstrações incorretas é muito maior do que o custo de manter código duplicado. Na verdade, Dan Abramov também alertou que a remoção excessiva de duplicações arruína a flexibilidade dos componentes.
Problemas causados por simples cópia de código podem ser corrigidos dentro do próprio arquivo em cerca de 50 minutos. Por outro lado, hooks comuns ou estruturas de herança criadas precipitadamente geram inúmeras ramificações if-else mesmo com a menor alteração nos requisitos. No fim das contas, leva mais de duas semanas apenas para encontrar bugs.
A decisão de refatorar é tomada com base no Quadrante de Dívida Técnica de Martin Fowler e na Análise de Hotspots de Adam Tornhill.
| Área | Critério (Complexidade e Frequência de Alteração) | Forma de Resposta |
|---|---|---|
| Correção Imediata | Alto impacto no negócio × Alta frequência de alteração | Escrever testes e organizar a interface logo após a implementação do recurso e implantar |
| Correção Opcional | Alto impacto no negócio × Baixa frequência de alteração | Registrar como tíquete de dívida no backlog |
| Implantar por Enquanto | Baixo impacto no negócio × Alta frequência de alteração | Verificar apenas o funcionamento mínimo e implantar, proibida a abstração |
| Tarefa em Espera | Baixo impacto no negócio × Baixa frequência de alteração | Omitir correções mesmo que o código esteja sujo |
Aplicando este critério, você pode reduzir o tempo gasto em trabalhos de generalização desnecessários e aumentar a velocidade geral de desenvolvimento.
Apontamentos de estilo, como nomes de variáveis, quebras de linha e violações de regras de linter, devem ser filtrados por ferramentas.
De acordo com um estudo da SmartBear analisando 2.500 revisões de código na Cisco Systems, 70% a 90% dos defeitos são descobertos quando a quantidade de código revisada de uma só vez é inferior a 200 linhas. Quando o autor deixa o motivo da alteração diretamente em um comentário no PR, a densidade de defeitos diminui em média 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" },
},
}
);
`
Aplicando esta configuração ao repositório, você pode reduzir o feedback de revisão relacionado ao estilo e se concentrar na verificação da lógica real.
Modificar a estrutura enquanto desenvolve um recurso distorce o contexto do trabalho. De acordo com pesquisas de engenharia do Google, quando as unidades de PR são divididas em partes menores e a intenção do trabalho é especificada, o tempo de espera para revisão de código cai de 48 horas para 4 horas.
Divida e controle o tempo de trabalho diário em sessões.
`markdown
`
Incentive os revisores a concentrarem o feedback apenas na lógica principal, em vez de estilos secundários, encurtando o tempo de aprovação.
Reescrever o código existente por completo aumenta o risco de falhas no ambiente de produção. Michael Feathers aconselha que, ao modificar código legado, em vez de alterar toda a estrutura, deve-se primeiro escrever testes de caracterização que fixem o comportamento atual de entrada e saída.
Configure um limite de erro (ErrorBoundary) para evitar que a tela inteira pare com uma tela branca quando ocorrerem erros em tempo de execução.
`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 || (
Por favor, atualize a página ou tente novamente mais tarde.
`
`bash
git revert HEAD --no-edit
git push origin main
`
Ao dividir as unidades de trabalho em partes menores e criar um ambiente para o qual se possa retornar em caso de falha, você pode controlar a ansiedade em relação às modificações de código. Entregar um sistema funcional no prazo, em vez de uma estrutura perfeita, é o básico da engenharia prática.
