Kriteria bagi Junior Developer yang Bekerja Sendiri di Startup untuk Menyelesaikan Sprint Tanpa Lembur
TuBrief 편집팀
2026년 8월 22일
0
Mental Health원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
커뮤니티의 다른 글
댓글 (0)
Log in to leave a comment
아직 작성된 글이 없습니다
원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
Saat mengembangkan frontend sendirian tanpa seorang mentor, Anda akan dikejar oleh kecemasan teknis. Pola di mana Anda meletakkan buku Clean Code di samping Anda, memikirkan abstraksi yang sempurna, dan akhirnya mengalami burnout tepat sebelum batas waktu sprint akan terus berulang. Yang Anda butuhkan bukanlah arsitektur yang sempurna, melainkan kriteria realistis untuk merilis produk yang berfungsi tepat waktu.
Pakar desain perangkat lunak Sandi Metz menunjukkan bahwa biaya untuk menghilangkan abstraksi yang salah jauh lebih besar daripada biaya mempertahankan kode duplikat. Faktanya, Dan Abramov juga memperingatkan bahwa penghapusan duplikasi secara paksa dapat merusak fleksibilitas komponen.
Masalah yang disebabkan oleh penyalinan kode sederhana biasanya dapat diperbaiki dalam waktu sekitar 50 menit di dalam file yang bersangkutan. Di sisi lain, hook bersama atau struktur pewarisan yang dibuat secara terburu-buru akan menghasilkan banyak percabangan if-else bahkan ketika persyaratan berubah sedikit saja. Pada akhirnya, menemukan bug saja bisa memakan waktu lebih dari 2 minggu.
Keputusan untuk melakukan refaktorisasi ditentukan berdasarkan Kuadran Utang Teknis Martin Fowler dan Analisis Hotspot Adam Tornhill.
| Area | Kriteria (Kompleksitas & Frekuensi Perubahan) | Cara Penanganan |
|---|---|---|
| Perbaikan Segera | Dampak bisnis tinggi × Frekuensi perubahan tinggi | Tulis pengujian dan rapikan antarmuka segera setelah implementasi fitur, lalu sebarkan |
| Perbaikan Opsional | Dampak bisnis tinggi × Frekuensi perubahan rendah | Daftarkan sebagai tiket utang di backlog |
| Sebarkan Saja | Dampak bisnis rendah × Frekuensi perubahan tinggi | Verifikasi fungsionalitas minimum dan sebarkan, dilarang melakukan abstraksi |
| Tunda Pekerjaan | Dampak bisnis rendah × Frekuensi perubahan rendah | Lewati perbaikan meskipun kodenya berantakan |
Dengan menerapkan kriteria ini, Anda dapat mengurangi waktu yang dihabiskan untuk tugas generalisasi yang tidak perlu dan meningkatkan kecepatan pengembangan secara keseluruhan.
Kritik gaya seperti nama variabel, pemenggalan baris, atau pelanggaran aturan lint harus disaring menggunakan alat bantu.
Menurut penelitian oleh SmartBear yang menganalisis 2.500 ulasan kode di Cisco Systems, 70% hingga 90% cacat ditemukan ketika jumlah kode yang ditinjau pada satu waktu kurang dari 200 baris. Ketika pembuat meninggalkan komentar di PR yang menjelaskan alasan perubahan secara langsung, kepadatan cacat berkurang rata-rata 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" },
},
}
);
`
Menerapkan pengaturan ini ke repositori Anda akan mengurangi umpan balik ulasan terkait gaya dan memungkinkan Anda untuk fokus pada verifikasi logika yang sebenarnya.
Jika Anda mengembangkan fitur sambil merombak struktur secara bersamaan, konteks kerja Anda akan terganggu. Menurut penelitian teknik Google, ketika unit PR dipecah menjadi bagian kecil dan niat kerja dinyatakan secara jelas, waktu tunggu ulasan kode berkurang dari 48 jam menjadi 4 jam.
Bagilah waktu kerja sehari ke dalam sesi-sesi untuk mengendalikannya.
`markdown
`
Hal ini mendorong peninjau untuk memfokuskan umpan balik pada logika inti daripada gaya sekunder, sehingga mempersingkat waktu persetujuan.
Menulis ulang seluruh kode yang ada dari awal meningkatkan risiko gangguan yang terjadi di lingkungan produksi. Michael Feathers menyarankan agar saat memodifikasi kode lama, Anda harus terlebih dahulu menulis pengujian karakterisasi yang memperbaiki perilaku input-output saat ini daripada mengubah seluruh strukturnya.
Untuk mencegah layar membeku sepenuhnya menjadi putih saat terjadi kesalahan runtime, atur batas kesalahan (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
`
Dengan membagi unit kerja menjadi bagian-bagian kecil dan menciptakan lingkungan di mana Anda dapat kembali jika gagal, Anda dapat mengontrol kecemasan tentang modifikasi kode. Menyampaikan sistem yang berfungsi tepat waktu alih-alih struktur yang sempurna adalah dasar dari teknik praktis.