Langsung ke konten

Cara saya membangun situs ini: satu task, satu pull request

Situs ini dibangun satu task kecil demi satu task kecil. Setiap task punya branch sendiri, test sendiri, dan pull request sendiri, dan tidak ada yang sampai ke situs live sebelum direview dan semua pengecekannya lolos. Begini cara kerjanya, dan kenapa saya bekerja seperti ini.

Sebagian besar pembangunan dan review dikerjakan oleh AI agent di Claude Code, yang bekerja di dalam aturan yang tertulis di repository. Merekalah yang mengerjakan; setiap keputusan tentang apa yang dibangun tetap ada di tangan saya.

Mulai dari apa yang akan dibangun

Sebelum ada kode, proyek ini punya tiga dokumen: requirement (apa yang harus dilakukan situs, dan untuk siapa), arsitektur (bagaimana situs disusun, dan kenapa), dan desain (bagaimana tampilan dan rasanya). Setiap keputusan di dalamnya adalah keputusan saya. Kalau sesuatu masih tebakan, ia ditandai provisional sampai saya setujui, jadi tebakan tidak pernah diam-diam berubah jadi requirement.

Dari dokumen-dokumen itu lahir sebuah rencana, dipecah menjadi task yang cukup kecil untuk direview sekali duduk. Setiap task menyebut requirement yang dilayaninya dan hasil yang membuktikan task itu selesai.

Satu task, satu branch

Setiap task dimulai di branch baru, di foldernya sendiri, dari branch staging. Dua task tidak pernah berbagi branch, jadi masing-masing bisa direview, dites, dan dibatalkan sendiri-sendiri.

Task yang besar tidak pernah dipecah jadi task kedua di tengah jalan. Bug yang ditemukan sambil jalan diperbaiki di branch yang sama, sebagai bagian dari pekerjaan yang sama.

Test lebih dulu

Setiap perubahan dimulai dengan test yang gagal, karena perilaku yang digambarkannya memang belum ada. Lalu kode ditulis sampai test itu lolos. Test yang belum pernah gagal tidak membuktikan apa-apa: bisa jadi ia lolos karena alasan yang salah.

Sebelum apa pun di-push, semua pengecekan dijalankan di mesin saya: unit test, lint, dan pengecekan tipe untuk aplikasi web, API, dan skrip deployment.

Review sampai bersih

Setelah task dibangun, agent reviewer yang terpisah membaca perubahannya terhadap requirement dan aturan proyek. Reviewer hanya bisa melapor, tidak bisa mengedit, jadi ia tidak punya alasan untuk lunak pada hasil kerjanya sendiri.

Setiap temuan diperbaiki, termasuk yang kecil, lalu perubahannya direview lagi. Task baru dianggap bersih saat review kembali dengan nol temuan. Ada yang cukup satu putaran; pemangkasan Resume dari empat halaman menjadi tiga butuh empat putaran.

Baru pull request

Hanya branch yang bersih yang di-push. Pull request-nya menjelaskan apa yang berubah dan kenapa, requirement mana yang dilayani, setiap pengecekan yang dijalankan, dan setiap keputusan yang saya ambil di sepanjang jalan.

Continuous integration menjalankan pengecekan itu sekali lagi di mesin yang bersih, termasuk test browser dan pemindaian aksesibilitas di setiap halaman. Kalau semuanya hijau, perubahan masuk ke staging. Production adalah langkah terpisah yang saya ambil sendiri, saat saya memutuskan untuk rilis.

Kenapa repot-repot

Cara kerja ini lebih lambat per task, tapi ia menghilangkan kejutan yang mahal. Setiap perubahan di situs ini bisa ditelusuri dari requirement yang memintanya sampai pull request yang mengirimkannya. Itu disiplin yang sama yang saya bawa ke pekerjaan klien: langkah kecil, bukti di setiap langkah, dan tidak ada yang dikirim hanya berbekal harapan.

Semua artikel

Bantuan