원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
Lorsqu'on développe seul du front-end sans mentor, on est constamment poursuivi par une anxiété technique. On garde le livre Clean Code ouvert à côté de soi, on réfléchit à l'abstraction parfaite et l'on finit par traverser un épuisement professionnel juste avant la date limite du sprint. Ce dont on a besoin, ce n'est pas d'une architecture irréprochable, mais de critères réalistes pour livrer un produit fonctionnel à temps.
Sandi Metz, experte en conception logicielle, souligne que le coût d'élimination d'une mauvaise abstraction est bien supérieur à celui du maintien de code dupliqué. De même, Dan Abramov a mis en garde contre le fait qu'une suppression excessive de duplications nuit à la flexibilité des composants.
Les problèmes causés par une simple copie de code peuvent être résolus dans le fichier concerné en une cinquantaine de minutes. En revanche, un hook partagé ou une structure d'héritage créés trop hâtivement génèrent d'innombrables branches if-else au moindre changement de spécification. Au final, cela prend plus de deux semaines rien que pour trouver les bugs.
La décision d'effectuer ou non un refactoring se base sur les quadrants de la dette technique de Martin Fowler et sur l'analyse des points chauds (hotspots) d'Adam Tornhill.
| Zone | Critère (Complexité et Fréquence de modification) | Mode de réponse |
|---|---|---|
| Modification immédiate | Impact métier élevé × Fréquence de modification élevée | Rédaction de tests et nettoyage des interfaces juste après l'implémentation de la fonctionnalité, puis déploiement |
| Modification sélective | Impact métier élevé × Fréquence de modification faible | Enregistrement sous forme de ticket de dette dans le backlog |
| Déploiement direct | Impact métier faible × Fréquence de modification élevée | Validation du fonctionnement minimal et déploiement, interdiction d'abstraire |
| Report des travaux | Impact métier faible × Fréquence de modification faible | Omission des corrections même si le code est désordonné |
En appliquant ces critères, vous réduisez le temps consacré aux tâches de mutualisation inutiles et augmentez la vitesse globale de développement.
Les remarques de style telles que le nommage des variables, les sauts de ligne ou les violations de règles de lint doivent être filtrées par des outils.
Selon une étude menée par SmartBear sur 2 500 revues de code chez Cisco Systems, 70 % à 90 % des défauts sont détectés lorsque la quantité de code examinée en une seule fois est inférieure à 200 lignes. Si l'auteur laisse directement en commentaire la raison des modifications dans sa PR, la densité des défauts diminue en moyenne de 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" },
},
}
);
`
Appliquer cette configuration au dépôt permet de réduire les retours de style et de se concentrer sur la vérification de la logique réelle.
Modifier la structure en même temps que l'on développe des fonctionnalités perturbe le contexte de travail. D'après des recherches en ingénierie de Google, lorsque la taille des PR est réduite et que l'intention du travail est explicitée, le temps d'attente pour la revue de code passe de 48 heures à 4 heures.
Le temps de travail quotidien est contrôlé en le divisant en sessions :
`markdown
`
Cela incite les relecteurs à concentrer leurs retours sur la logique centrale plutôt que sur des styles secondaires, réduisant ainsi le temps d'approbation.
Réécrire l'intégralité du code existant d'un seul coup augmente le risque de pannes en production. Michael Feathers conseille de rédiger d'abord des tests de caractérisation qui figent le comportement actuel des entrées/sorties plutôt que de modifier toute la structure lors de la correction du code legacy.
Pour empêcher que l'écran entier ne se fige en blanc lors d'une erreur d'exécution, des limites d'erreur (ErrorBoundary) sont configurées.
`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;
}
public 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
`
Diviser les unités de travail et créer un environnement permettant de revenir en arrière en cas d'échec permet de maîtriser l'anxiété liée à la modification du code. Livrer à temps un système qui fonctionne, plutôt qu'une structure parfaite, constitue la base de l'ingénierie pratique.
