80 poin oleh GN⁺ 2025-08-26 | Belum ada komentar. | Bagikan ke WhatsApp
  • Saya sedang berusaha meningkatkan kemampuan desain perangkat lunak, dan mendapat saran untuk mempelajari codebase yang sudah ada dan dirancang dengan baik
  • Saya penasaran codebase apa saja yang dapat diakses publik yang dianggap sebagai gold standard dalam desain perangkat lunak

1. Rekomendasi codebase

  • Proyek besar/perwakilan
    • Git, Postgres, CPython
    • "lieutenants model" dari Linux Kernel
    • UNIX v6, BSDs
  • Framework/library
  • Sistem/server
  • Game/kasus khusus
  • Materi pendidikan/pembelajaran
  • Lainnya
    • Monocypher (library kriptografi)
    • Implementasi bahasa Tcl

2. Membaca kode vs mempelajari dokumen/desain

  • Keterbatasan hanya dari kode
    • Codebase menunjukkan implementasi, tetapi menyembunyikan niat desain dan trade-off
  • Pentingnya dokumen desain
    • Catatan keputusan seperti ADR (Architectural Decision Records), RFC Rust, dan PEP Python jauh lebih bermanfaat untuk mempelajari desain
    • Menulis dokumen desain itu sendiri juga bisa menjadi latihan
  • Rekomendasi buku/literatur

3. Teori pembelajaran yang berpusat pada praktik

  • Pengalaman dan trial-and-error
    • Desain dipelajari dengan berulang kali menghadapi masalah dan belajar cara menghindarinya
    • Hanya membaca kode tidak cukup; pembelajaran terjadi saat menulis sendiri dan menyelesaikan kegagalan
  • Pembelajaran berbasis minat
    • Anda akan belajar lebih dalam jika membuat proyek yang benar-benar Anda minati
  • Biaya kegagalan yang rendah
    • Perangkat lunak memiliki biaya kegagalan lebih rendah daripada rekayasa fisik, sehingga belajar lewat mencoba dan gagal efektif

4. Perdebatan tentang sifat software engineering

  • Pandangan rekayasa yang belum matang
    • Jika lima engineer berkumpul lalu menghasilkan lima solusi berbeda, itu dianggap bukti ketidakmatangan sebagai disiplin rekayasa
  • Pandangan sifat yang ramah eksperimen
    • Perangkat lunak memiliki sedikit batasan sehingga banyak solusi bisa ada, dan tidak punya satu jawaban tetap seperti rekayasa fisik
  • Batas antara seni dan rekayasa
    • Desain juga merupakan tindakan artistik yang memiliki unsur estetika, tetapi dari sisi memenuhi kebutuhan fungsional tetap merupakan rekayasa
    • Perangkat lunak berada di antara fleksibilitas artistik dan ketelitian engineering

5. Metode belajar alternatif

  • Menganalisis kode yang buruk
    • Bukan hanya kode yang dirancang baik, memperbaiki codebase yang buruk juga memberi efek belajar yang besar
  • Belajar dari codebase sendiri
    • Codebase internal tim sering disebut sebagai bahan yang paling banyak memberi pelajaran
    • Namun, jika kode tim buruk, perlu dibarengi dengan contoh eksternal
  • Pembelajaran yang disesuaikan dengan domain
    • Membaca codebase yang mirip dengan masalah yang ingin Anda pecahkan adalah pendekatan paling efektif

Insight utama

  • Codebase yang dirancang baik memang membantu, tetapi pembelajaran harus berjalan beriringan dengan memahami niat desain dan mengalami trial-and-error
  • Dibanding hanya membaca kode, dokumen desain dan catatan keputusan adalah materi belajar yang paling penting
  • Proyek-proyek berkualitas tinggi yang representatif (Git, Postgres, CPython, Rust std, dll.) punya nilai belajar tinggi
  • Bukan hanya kode yang bagus, kode yang buruk dan kode milik sendiri justru sering lebih praktis untuk pembelajaran jangka panjang

Ringkasan komentar utama

Rekomendasi codebase yang representatif (CraigJPerry)

  • Postfix mail server
    • Dengan arsitektur yang berpusat pada keamanan, ia sudah menunjukkan struktur mirip microservices bahkan sebelum konsep itu populer
    • Jika microservices modern menekankan distribusi pada organisasi besar, Postfix dirancang untuk keamanan dan kesederhanaan
  • Spring Framework
    • Mencerminkan budaya yang sangat mempertimbangkan kebutuhan developer Java di lingkungan enterprise
    • Bisa dipelajari sebagai pendekatan desain yang berpusat pada pengguna
  • Git
    • Jika memahami konsep object database (blob, tree, commit) dan reference, sisanya adalah perluasan bertahap
    • Perluasan yang konsisten dari konsep inti ditunjukkan sebagai contoh desain yang baik
  • Varnish
    • Sebagai reverse proxy berperforma tinggi, codebase-nya tersusun sangat baik hingga layak dipakai sebagai bahan belajar
  • Linux Kernel Lieutenants Model
    • Ini bukan codebase, tetapi layak dijadikan referensi sebagai model pengelolaan perangkat lunak berskala besar
  • Bukan sekadar "kode yang dirancang baik", melainkan contoh-contoh di mana keputusan desainnya meninggalkan kesan yang kuat

Menekankan pembelajaran dari codebase kerja nyata (crystal_revenge)

  • Nilai belajar terbesar bisa didapat dari codebase tim Anda sendiri
  • Dalam proses hubungan yang rumit antara kebutuhan nyata dan implementasi, Anda akan mengalami pilihan baik dan buruk sekaligus
  • Batasan paling besar di dunia nyata adalah tekanan waktu, dan inti pembelajaran adalah memahami keseimbangan antara desain ideal dan kenyataan
  • Software yang baik adalah yang menyelesaikan kebutuhan pengguna, dan lewat pengalaman berulang Anda belajar merancang dengan peluang sukses lebih tinggi

Tautan ke diskusi dan materi sebelumnya (sprobertson)

Kode vs dokumen desain (alphazard)

  • Codebase hanyalah hasil implementasi, bukan desain itu sendiri
  • Untuk mempelajari desain, menulis dokumen desain lebih efektif
    • Dokumen harus cukup jelas sehingga orang lain bisa mengimplementasikannya secara langsung
    • Jika alternatif dicantumkan beserta alasan penolakannya, itu menjadi bukti pertimbangan desain
  • Desainer yang baik adalah orang yang mempertimbangkan ruang desain yang lebih luas lalu memilih titik yang tepat

Menekankan pemahaman sistem secara menyeluruh (RossBencina)

  • Proses memahami keseluruhan codebase sangat bernilai
    • Bukan hanya kode yang dirancang baik, tetapi juga latihan melihat gambaran besar sistem
    • Memvisualisasikan relasi lewat diagram seperti UML sangat membantu
  • Pendekatan belajar:
    • Efektif membaca kode perangkat lunak yang mirip dengan yang sedang Anda kembangkan
    • Disarankan memulai dari kode di domain yang sudah akrab (web framework, web server, library standar Python, VSCode, dll.)
    • Pada awalnya lebih baik mendekati program kecil dan domain yang familiar

Tolok ukur desain yang baik (mamcx)

  • Desain yang baik menunjukkan tujuan dan gagasan, sedangkan codebase menunjukkan sejauh mana itu diimplementasikan
  • Desain yang baik bukan sekadar label seperti "cepat" atau "aman", melainkan harus mencakup pertimbangan konkret dan catatan trade-off
  • Contoh: karakteristik seperti ini dapat diamati pada Erlang, Pascal awal, dan desain banyak RDBMS
  • Library std Rust adalah bahan belajar yang baik karena menekankan keamanan dan konsistensi, dan kode serta dokumentasinya merefleksikan hal itu dengan baik

Keputusan desain yang tak terlihat (ben30)

  • Saat melihat codebase yang dirancang baik, bagian terpenting justru adalah yang tidak terlihat
    • Menghilangkan kompleksitas, menghindari abstraksi yang tidak perlu, dan menolak pola tertentu adalah keputusan berupa ketiadaan yang sangat penting
  • Untuk melengkapinya, gunakan ADR (Architectural Decision Records)
    • Mencatat alternatif, alasan menolaknya, dan dasar pemilihan agar konteks tetap tersimpan
    • Sangat membantu baik bagi maintainer di masa depan maupun alat AI
  • Saat belajar, efektif untuk melihat proyek yang bukan hanya punya kode, tetapi juga dokumen keputusan desain seperti ADR, RFC, PEP, dan sejenisnya

Belum ada komentar.

Belum ada komentar.