Pemilihan proyek

Seluruh topik pada jalur ini membangun perangkat untuk satu tujuan, yaitu menuntaskan satu proyek nyata secara utuh. Keputusan pertama dan yang paling menentukan bukanlah kode, melainkan pilihan proyeknya, karena lingkup yang salah membuat proyek mati di tengah jalan tanpa ada satu pun konsep yang dikuatkan. Topik ini membahas tiga bentuk proyek yang sesuai dengan skala jalur ini beserta kriteria memilih di antaranya.

Konsep#

Tiga bentuk berikut cocok karena ketiganya dapat dituntaskan sendiri, dapat diuji dengan blok test, dan dapat dikompilasi silang sebagai bukti portabilitas.

1. Alat CLI memproses argumen atau berkas teks lalu mencetak hasil, misalnya penghitung statistik berkas log atau pengonversi format angka. Latihannya menguatkan slice, error union, dan pemuatan berkas melalui std.Io.
2. Basis data kecil menyimpan dan mencari kumpulan rekaman pada satu berkas biner, misalnya penyimpan nilai kunci dengan indeks sederhana. Latihannya menguatkan allocator, ArrayList, dan tata letak biner melalui extern struct.
3. Pembungkus pustaka C menyediakan antarmuka Zig idiomatik di atas pustaka C yang sudah ada. Latihannya menguatkan translate-c, extern struct, dan penyembunyian detail [*c] di balik tipe Zig yang aman.

Ketiganya berbagi satu ukuran keberhasilan yang sama, yaitu alat berjalan dari baris perintah, pemeriksaannya lulus, dan binernya dihasilkan untuk minimal satu target silang. Kriteria lingkup yang dapat dipertanggungjawabkan berbunyi sederhana, yaitu inti fungsinya dapat didemonstrasikan dalam satu program di bawah seribu baris, dan sisa pekerjaannya berupa perapian, bukan fitur baru.

Target distribusi diputuskan pada saat pemilihan proyek, bukan setelah proyek jadi. Alat CLI untuk pengguna Linux berbeda keputusannya dengan alat yang berbagi pakai lintas sistem, karena pilihan itu menetapkan ABI, format biner, dan pemeriksaan kompilasi silangnya. Keputusan awal yang sama berlaku untuk bentuk basis data kecil, yaitu memutuskan format berkas penyimpanannya sejak awal agar pembaruan versi tidak memaksa konversi data mendesak.

Contoh pada topik ini memakai bentuk pertama, yaitu alat CLI penghitung rata-rata, karena bentuk tersebut memperlihatkan seluruh lapisan keputusan dengan kode paling sedikit.

Rencana memori ikut diputuskan pada tahap pemilihan, sebelum baris pertama ditulis. Alat CLI pada contoh tidak membutuhkan alokasi tumpukan sama sekali karena argumennya diproses satu per satu, dan keputusan tersebut menghilangkan satu kelas kebocoran sejak awal. Basis data kecil justru menuntut keputusan sebaliknya, yaitu memilih arena untuk pembacaan berkas dan GPA untuk rekaman yang hidup lintas permintaan. Bentuk proyek menentukan rencananya, dan rencana yang cocok membuat pengerjaannya berjalan tanpa revisi strategi di tengah jalan.

Contoh Lengkap#

Alat rata-rata menerima serangkaian angka pada argumen baris perintah, lalu mencetak banyaknya nilai, jumlah, dan rata-ratanya. Argumen yang bukan angka ditolak dengan pesan yang jelas, dan ketiadaan argumen mencetak cara pemakaiannya.

const std = @import("std");

pub fn main(init: std.process.Init) !void {
    var it = std.process.Args.Iterator.init(init.minimal.args);
    _ = it.skip();

    var jumlah: u64 = 0;
    var banyak: usize = 0;
    while (it.next()) |arg| {
        const nilai = std.fmt.parseInt(u64, arg, 10) catch {
            std.debug.print("argumen `{s}` bukan bilangan bulat\n", .{arg});
            return;
        };
        jumlah += nilai;
        banyak += 1;
    }
    if (banyak == 0) {
        std.debug.print("pemakaian: rata-rata <angka> ...\n", .{});
        return;
    }
    std.debug.print("banyak nilai: {d}\n", .{banyak});
    std.debug.print("jumlah: {d}\n", .{jumlah});
    std.debug.print("rata-rata: {d}.{d:0>2}\n", .{ jumlah / banyak, (jumlah * 100 / banyak) % 100 });
}

Pemisahan argumen diambil dari init.minimal.args dengan std.process.Args.Iterator, dan elemen pertama dilewati karena berisi nama program. Perhitungan rata-rata dikerjakan dengan perkalian seratus terlebih dahulu agar dua angka di belakang koma tetap presisi tanpa pecahan mengapung. Tiga skenario pemakaian berikut menutup perilakunya satu per satu.

zig run rata-rata.zig -- 12 17 9 20

banyak nilai: 4
jumlah: 58
rata-rata: 14.50

zig run rata-rata.zig -- 7 delapan 9

argumen `delapan` bukan bilangan bulat

zig run rata-rata.zig

pemakaian: rata-rata <angka> ...

Skenario pertama memuat empat angka yang menjumlah menjadi 58 dengan rata-rata 14,50. Skenario kedua berhenti pada argumen pertama yang gagal dikonversi, dan skenario ketiga mencetak cara pemakaian karena tidak ada masukan. Ketiganya bersifat kontrak, sehingga versi proyek yang diperluas wajib mempertahankannya.

Kesalahan umum#

Kesalahan kedua berupa memilih proyek yang intinya tidak dapat diuji. Program yang seluruh logikanya berada di dalam main bersama pembacaan argumen dan pencetakan tidak menyediakan titik masuk bagi blok test, sehingga modul Pengujian tidak terpakai pada proyek. Pemisahan logika dan lapisan masukan-keluaran ditegakkan sejak berkas pertama.

Kesalahan ketiga berupa mencampur pemilihan proyek dengan pemilihan teknologi. Keputusan berupa alat CLI atau basis data kecil menetapkan perangkat yang diperlukan, sedangkan sebaliknya, yaitu memulai dari fitur bahasa yang ingin dipakai, menghasilkan proyek tanpa pengguna nyata. Urutan yang benar adalah tujuan dahulu, lalu perangkat mengikutinya.

Ringkasan#

• Tiga bentuk proyek yang sesuai skala jalur ini adalah alat CLI, basis data kecil, dan pembungkus pustaka C.
• Ukuran lingkup yang sehat berarti inti fungsinya dapat didemonstrasikan di bawah seribu baris.
• Kontrak perilaku, seperti pesan pemakaian dan penolakan argumen yang salah, ditetapkan sejak contoh pertama.
• Inti logika dipisahkan dari lapisan CLI agar pemeriksaannya dapat berjalan tanpa proses.

Topik berikutnya menyusun rencana memori proyek sebelum baris pertama kode ditulis.

Referensi#

• Zig Learn, Overview — ziglang.org — Peta kemampuan bahasa yang menjadi bahan penilaian kesesuaian proyek.