Banyak orang membayangkan pekerjaan software engineer sebagai "menulis kode seharian". Kenyataannya, menulis kode hanya salah satu bagian. Sebelum kode ditulis ada kebutuhan yang harus dipahami, dan sesudahnya ada review, pengujian, serta proses merge dan rilis.

Artikel ini memberikan gambaran software engineer workflow — alur kerja engineer di tim produk — dari membaca dokumen kebutuhan sampai kode masuk ke branch utama.

Gambaran besar alur kerja

Alur kerja setiap perusahaan berbeda, tetapi pola umumnya mirip:

Memahami kebutuhan — dari PRD, tiket, atau diskusi dengan tim produk.
Merencanakan — memecah pekerjaan dan menentukan pendekatan teknis.
Membuat branch — bekerja terpisah dari kode utama.
Menulis kode dan commit bertahap.
Menguji — memastikan perubahan bekerja dan tidak merusak yang lain.
Membuka Pull Request.
Pengecekan otomatis (CI).
Code review — menerima masukan dan memperbaiki.
Merge — perubahan masuk ke branch utama.
Rilis dan pemantauan.

Mari bahas satu per satu.

1. Memahami kebutuhan: membaca PRD

Pekerjaan biasanya berangkat dari PRD (Product Requirements Document) atau tiket. Dokumen ini menjelaskan masalah yang ingin diselesaikan, siapa penggunanya, dan kriteria keberhasilannya.

Contoh bagian PRD sederhana:

User story: Sebagai admin, saya ingin memfilter pesanan berdasarkan status, agar bisa langsung melihat pesanan yang belum dikirim.

Kriteria penerimaan:

Filter tersedia untuk status menunggu, dibayar, dan dikirim.

Filter bisa dikosongkan untuk menampilkan semua pesanan.

Halaman tetap responsif untuk ribuan pesanan.

Tugas engineer di tahap ini adalah bertanya kalau ada yang ambigu. Misalnya: apakah filter bisa memilih lebih dari satu status? Apakah hasilnya perlu paginasi? Pertanyaan yang diajukan di awal jauh lebih murah daripada kode yang harus ditulis ulang.

2. Merencanakan pendekatan teknis

Sebelum menulis kode, engineer memikirkan:

bagian codebase mana yang akan berubah,
apakah perlu perubahan skema database,
bagaimana menjaga performa saat datanya banyak,
bagaimana cara mengujinya.

Untuk pekerjaan besar, rencana ini bisa ditulis sebagai dokumen desain singkat dan didiskusikan dulu. Untuk pekerjaan kecil, cukup dipikirkan atau dicatat di tiket.

3. Membuat branch

Setiap pekerjaan dikerjakan di branch terpisah supaya branch utama tetap stabil:

git switch main
git pull
git switch -c feature/filter-status-pesanan

Konvensi nama branch berbeda-beda per tim, misalnya feature/..., fix/..., atau menyertakan nomor tiket. Kalau perintah Git belum familiar, lihat Belajar Git untuk Pemula.

4. Menulis kode dan commit bertahap

Engineer yang berpengalaman jarang menulis semuanya sekaligus lalu commit satu kali. Mereka bekerja dalam langkah kecil: satu perubahan logis, satu commit dengan pesan yang jelas.

git commit -m "Tambah parameter status di query daftar pesanan"
git commit -m "Tambah komponen dropdown filter status"
git commit -m "Hubungkan filter ke URL agar bisa dibagikan"

Commit kecil memudahkan review dan memudahkan mencari penyebab kalau ada masalah di kemudian hari.

5. Menguji perubahan

Sebelum meminta review, engineer memastikan perubahannya bekerja:

menjalankan aplikasi dan mencoba skenario utama,
mencoba kasus tepi — data kosong, input aneh,
menjalankan test yang ada dan menambahkan test baru bila perlu.

6. Membuka Pull Request

Setelah branch di-push, engineer membuka Pull Request dengan judul dan deskripsi yang menjelaskan apa yang berubah, kenapa, dan cara mengujinya. Detailnya dibahas di Apa Itu Pull Request?.

7. Pengecekan otomatis (CI)

Di banyak tim, membuka atau memperbarui PR memicu Continuous Integration (CI) — pipeline otomatis yang menjalankan build, test, linter, dan pengecekan lainnya. PR dengan CI yang gagal biasanya diperbaiki dulu sebelum di-review.

8. Code review

Rekan tim membaca perubahan dan memberi masukan: pertanyaan, saran, atau permintaan perubahan. Engineer menanggapi setiap komentar, memperbaiki kode, lalu push ulang ke branch yang sama. Siklus ini bisa berulang beberapa kali.

Hal yang biasanya diperiksa reviewer dan cara menanggapinya dibahas di Code Review untuk Pemula.

9. Merge

Setelah disetujui dan CI lulus, PR di-merge ke branch utama. Tim biasanya punya aturan, misalnya minimal satu approval dan semua pengecekan hijau.

10. Rilis dan pemantauan

Tergantung prosesnya, perubahan bisa langsung dirilis otomatis atau dikumpulkan untuk rilis berikutnya. Setelah rilis, engineer memantau apakah ada error atau keluhan, dan siap memperbaiki kalau ada masalah.

Skill non-teknis yang ikut terlatih

Alur kerja ini menuntut lebih dari kemampuan menulis kode:

Komunikasi tertulis — di tiket, deskripsi PR, dan komentar review.
Bertanya dengan tepat — memperjelas kebutuhan sebelum membangun.
Menerima feedback — memperbaiki tanpa defensif.
Estimasi dan prioritas — memecah pekerjaan besar menjadi langkah yang bisa diselesaikan.

Kenapa alur ini jarang diajarkan?

Kebanyakan materi belajar coding berfokus pada bagaimana menulis kode: sintaks, framework, dan contoh aplikasi. Alur kerja tim sulit diajarkan lewat video karena membutuhkan spesifikasi, codebase, reviewer, dan proses yang berjalan. Akibatnya, banyak developer baru pertama kali mengalaminya di pekerjaan pertama.

Cara mempelajarinya lebih awal adalah mempraktikkannya: mengerjakan real project dengan spesifikasi, bekerja lewat branch dan Pull Request, serta mencari review atas kodemu.

Kesimpulan

Software engineer workflow mencakup jauh lebih banyak dari sekadar menulis kode: memahami kebutuhan dari PRD, merencanakan, bekerja lewat branch dan commit bertahap, menguji, membuka Pull Request, melewati CI dan code review, lalu merge dan memantau rilis.

Di simulasi kerja software engineer KodingCamp, kamu menjalani alur ini secara langsung: menerima PRD, mengerjakan misi di repository GitHub privat, membuka Pull Request, dan melewati review Tech Lead AI sampai kode layak di-merge.

Software Engineer Workflow: Dari PRD sampai Merge ke Main