Written with AI assistance from the source video. The video is the authority.
43:49Dr. Arthur Brooks
Log in to leave a comment
No posts yet
When developing frontend alone without a senior mentor, you are constantly chased by technical anxiety. You keep a Clean Code book by your side, agonize over perfect abstraction, and repeatedly burn out right before the sprint deadline. What you actually need is not flawless architecture, but a realistic standard for shipping a working product on time.
Software design expert Sandi Metz points out that the cost of removing a bad abstraction is far greater than the cost of maintaining duplicated code. In fact, Dan Abramov also warned that forced removal of duplication ruins component flexibility.
Problems caused by simple code copying can be fixed within about 50 minutes in the corresponding file. On the other hand, hastily created shared hooks or inheritance structures create countless if-else branches even with minor requirement changes. In the end, it takes over two weeks just to find bugs.
Decide whether to refactor based on Martin Fowler's Technical Debt Quadrant and Adam Tornhill's Hotspot Analysis.
| Area | Criteria (Complexity & Change Frequency) | Response Strategy |
|---|---|---|
| Immediate Fix | High Business Impact × High Change Frequency | Write tests and organize interfaces immediately after feature implementation, then deploy |
| Selective Fix | High Business Impact × Low Change Frequency | Register as a debt ticket in the backlog |
| Deploy As-Is | Low Business Impact × High Change Frequency | Verify minimal operation only and deploy, no abstraction |
| Postpone | Low Business Impact × Low Change Frequency | Skip modifications even if the code is messy |
Applying these criteria can reduce the time spent on unnecessary commonization tasks and boost overall development speed.
Style comments like variable names, line breaks, and lint rule violations should be caught by tools.
According to a SmartBear study analyzing 2,500 Cisco Systems code reviews, 70% to 90% of defects are found when the code volume reviewed at once is under 200 lines. When authors leave comments directly in the PR explaining their reasons for changes, defect density drops by an average of 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" },
},
}
);
`
Applying this configuration to the repository reduces style-related review feedback and allows you to focus on actual logic verification.
Refactoring the structure while developing features disrupts your workflow context. According to Google's engineering research, breaking PR units into smaller pieces and explicitly stating work intentions reduces code review wait times from 48 hours to 4 hours.
Divide and control your daily working hours into sessions:
`markdown
Encourage reviewers to focus their feedback on core logic rather than secondary styles, shortening approval times.
Rewriting existing code entirely increases the risk of production incidents. Michael Feathers advises that when modifying legacy code, you should first write characterization tests that lock down current input-output behaviors rather than changing the overall structure.
Set up an ErrorBoundary to prevent the entire screen from freezing into a white screen when runtime errors occur.
`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 || (
Please refresh or try again in a moment.
bash git revert HEAD --no-edit git push origin main
Breaking work units into small pieces and creating an environment where you can revert upon failure helps control anxiety about code modifications. Delivering a working system on time instead of a perfect structure is the fundamental rule of practical engineering.