Hal yang Berubah dari Cara Gue Ngoding Setelah Masuk Dunia ERP

Intro

Dulu waktu masih sering bikin personal project atau freelance kecil-kecilan, cara gue ngoding bisa dibilang cukup bebas

Kalau mau ambil data ya tinggal query.

Kalau mau join table ya tinggal bikin query sendiri.

Kalau mau langsung hit database dari controller juga… ya tinggal gas aja selama jalan.

Contohnya kurang lebih seperti ini:

public function index()
{
    $users = DB::table('users')
        ->select('users.*', 'roles.name as role_name')
        ->join('roles', 'roles.id', '=', 'users.role_id')
        ->where('users.status', 'ACTIVE')
        ->get();

    return response()->json($users);
}

Dan jujur aja, waktu itu gue ngerasa:

“ya udah bener kan? hasilnya keluar.”

Sampai akhirnya gue masuk ke dunia ERP.

Dan di situlah gue mulai sadar:

ngoding di enterprise environment ternyata beda mindset.

Saat Pertama Ketemu Base Framework Internal

Waktu awal masuk project ERP, gue cukup kaget.

Karena mereka punya base framework sendiri.

Kadang:

• ditulis native,
• kadang framework di atas framework,
• atau abstraction tambahan di atas Laravel / Spring Boot.

Awalnya gue bingung:

“lah ini kenapa jadi ribet banget?”

Untuk ambil data aja kadang harus lewat:

• BaseService,
• repository tertentu,
• helper internal,
• bahkan query builder custom.

Padahal menurut gue waktu itu:

“kan ujung-ujungnya select juga”

Dulu Tinggal Query, Sekarang Harus Lewat Layer

Kalau dulu gue biasa langsung query seperti ini:

$users = User::where('status', 'ACTIVE')->get();

Atau kadang:

$users = DB::select("
    SELECT u.*, r.name as role_name
    FROM users u
    JOIN roles r ON r.id = u.role_id
    WHERE u.status = 'ACTIVE'
");

Tapi di project ERP, approach-nya jadi lebih seperti ini:

public function getActiveUsers(array $filters = [])
{
    return $this->baseService->fetchData(
        table: 'users',
        select: ['users.*', 'roles.name as role_name'],
        joins: [
            [
                'table' => 'roles',
                'first' => 'roles.id',
                'operator' => '=',
                'second' => 'users.role_id'
            ]
        ],
        where: [
            ['users.status', '=', 'ACTIVE']
        ]
    );
}

Secara hasil?

Ya sama aja

Tetap query select.

Tetap join table.

Tetap ambil data.

Tapi lama-lama gue mulai ngerti kalau tujuan utamanya bukan sekadar “mengambil data”.

Ternyata Ini Soal Consistency

Semakin lama gue kerja di enterprise project, semakin gue sadar bahwa project besar itu bukan cuma soal:

• code jalan,
• feature selesai,
• atau query paling cepat ditulis.

Tapi juga soal:

• consistency,
• maintainability,
• readability,
• dan standardisasi antar developer.

Bayangin kalau:

• semua developer bikin query dengan style berbeda,
• naming beda-beda,
• structure beda,
• validation beda,
• response format beda.

Project bakal cepat jadi chaos.

Dan ketika system sudah dipakai bertahun-tahun, chaos kecil bisa jadi technical debt besar.

Enterprise Development Itu Tentang Tim, Bukan Individu

Ini salah satu mindset yang paling berubah buat gue.

Dulu gue sering mikir:

“yang penting code gue jalan.”

Sekarang gue mulai sadar:

“yang penting code ini bisa dipahami tim lain 2 tahun lagi.”

Karena di enterprise environment:

• developer bisa keluar masuk,
• project berjalan bertahun-tahun,
• dan system dipakai banyak divisi.

Kadang abstraction tambahan memang terasa lebih ribet di awal.

Tapi ternyata itu membantu menjaga consistency project dalam jangka panjang.

Tidak Semua Hal Harus “Paling Fleksibel”

Dulu gue merasa ngoding yang bagus itu:

• bebas,
• cepat,
• fleksibel,
• dan bisa bikin solusi sesuka kita.

Tapi setelah masuk dunia ERP, gue mulai ngerti bahwa kadang engineering bukan tentang:

“cara paling bebas”

melainkan:

“cara paling aman dan paling mudah dipelihara bersama-sama.”

Dan menurut gue, itu salah satu perbedaan terbesar antara personal project dan enterprise development.

Penutup

Masuk ke dunia ERP bikin gue sadar bahwa software engineering bukan cuma soal syntax atau framework.

Tapi juga soal:

• bagaimana sebuah system dijaga,
• bagaimana tim bekerja,
• dan bagaimana code bisa tetap stabil dalam jangka panjang.

Kadang hal-hal yang awalnya terasa “ribet” ternyata dibuat karena project sudah melewati banyak fase, banyak developer, dan banyak masalah sebelumnya.

Dan dari situ gue mulai belajar:

code yang bagus bukan selalu code yang paling bebas ditulis, tapi code yang paling mudah dipahami dan dijaga bersama.