- Pengembangan software sulit berlanjut langsung dari dokumen desain ke PR yang rapi; karena asumsi sering goyah saat benar-benar coding, mengeksplorasi desain dengan kode yang akan dibuang bisa lebih cepat
- Mengusulkan alur membuat prototipe atau proof of concept dalam draft PR yang tidak akan di-merge, mendapatkan review awal untuk menyelaraskan arah pendekatan, lalu menyimpannya sebagai catatan ide desain
- Prasyarat pendekatan ini adalah kematangan organisasi untuk berani membuang solusi pertama; sikap mampu mengimplementasikan masalah yang sama dengan 2–3 cara dianggap sebagai tanda senioritas
- PR dapat menjadi dokumen yang mudah ditemukan berisi niat implementasi dan diskusi pada titik waktu tertentu, sementara dokumen desain mudah menjadi “undead documentation” yang melenceng dari realitas jika tidak sering diperbarui
- Dokumen desain tetap diperlukan untuk merangkum feedback dari banyak pemangku kepentingan, sebagai dokumen North Star jangka panjang, untuk ide awal yang masih sulit dikodekan, atau di organisasi yang berisiko langsung mengirim prototipe ke produksi
Mengeksplorasi Desain dengan Throwaway PR
- Alur pengembangan ideal kira-kira adalah menulis dokumen desain, menggabungkan PR kecil satu per satu untuk merilis fitur, dan menjaga riwayat Git tetap rapi
- Dalam praktiknya, asumsi di dokumen desain sering baru goyah setelah mulai coding, dan kita kerap harus menilai ulang urutan rilis
- Karena itu, membuat eksperimen kode besar terlebih dahulu lalu menyusun rencana nyata berdasarkan hasilnya bisa lebih efisien
-
Prosedur yang diusulkan
- Implementasikan prototipe atau proof of concept sebagai draft PR tanpa niat untuk di-merge
- Dapatkan pandangan orang lain sejak awal tentang refactoring besar atau pendekatan fitur untuk memperoleh penyelarasan arah
- Dokumentasikan pendekatan di dalam draft PR agar tersimpan sebagai catatan historis ide desain
- Bersiaplah untuk membuang seluruh draft PR sedini mungkin
- Tarik PR yang benar-benar dapat dirilis secara bertahap dari draft PR, lalu pecah menjadi PR rilis yang bersih selama kira-kira satu minggu
- Saat menahapkan tiap PR, isi celah pada testing dan ketangguhan secara bertahap
-
Kondisi tim yang dibutuhkan pendekatan ini
- Syarat terpenting adalah kematangan untuk bisa membuang ide pertama yang sudah dikodekan sendiri
- Kenyamanan untuk mencoba mengodekan masalah yang sama dengan 2–3 cara dapat dipandang sebagai sinyal penting senioritas
- Nilai yang disampaikan bukan jumlah baris kode yang masuk production, melainkan pengetahuan yang diperoleh organisasi
- Jika penyelarasan didapatkan sejak awal pada bagian penting, prototyping berikutnya tidak berakhir sebagai pemborosan belaka
- Perlu cukup akrab dengan codebase untuk dapat menghubungkan bagian-bagian inti dengan cepat; staf senior membutuhkan tingkat kenyamanan seperti itu
- Pendekatan ini dapat dilakukan bukan hanya secara individu, tetapi juga di tingkat tim
Dokumentasi PR dan Peran Nyata Dokumen Desain
- PR adalah salah satu bentuk dokumentasi yang berguna bagi developer
- Salah satu tempat pertama yang dilihat saat ingin memahami mengapa implementasi tertentu dibuat seperti itu
- PR tidak mengklaim mencerminkan kondisi saat ini, melainkan tersisa sebagai artefak historis yang merekam keadaan pada titik waktu tertentu
- Jika dokumen desain tidak sering dijaga tetap mutakhir, dokumen itu mudah menjadi undead documentation yang mencerminkan realitas lama
- Prototipe cocok untuk “tunjukkan, bukan sekadar katakan”, dan saat membuat perubahan, kode bisa lebih efektif daripada dokumen
- Namun di organisasi tanpa disiplin, prototipe berisiko diterima sebagai “jawaban”, bukan “pertanyaan”
- Niat awalnya lebih dekat ke “apakah kita harus melakukan ini, atau melakukan hal lain?”
- Masalah muncul jika organisasi menerimanya sebagai “kita harus melakukan ini”
-
Kapan dokumen desain masih tepat
- Berguna saat perlu merangkum dan menyimpan feedback dari banyak pemangku kepentingan, manajer, dan tim eksternal
- GitHub saja mungkin sulit menangani kolaborasi semacam itu
- Jika ide terlalu konseptual dan jangka panjang sehingga sulit langsung dikodekan, sejumlah dokumen North Star dapat membantu
- Berguna ketika mengekspresikan lewat tulisan lebih efisien daripada draft kode pertama, atau ketika onboarding ke codebase belum cukup sehingga ingin meninggalkan draft untuk feedback
- Jika perusahaan mendorong deployment ke production tanpa disiplin untuk membuang solusi pertama, prototipe dapat mengeras begitu saja menjadi “solusi”
- Di organisasi tempat staf junior sulit membantah implementasi ide developer senior, mungkin diperlukan artefak yang lebih lunak agar pertanyaan dapat diajukan dengan lebih aman
-
Ketika dokumen desain dipakai untuk alasan yang buruk
- Dokumen dapat menjadi sarana memperlambat proses pada tim yang kurang disiplin atau kurang terampil
- Meski dipakai untuk tujuan dokumentasi, biasanya dokumen cepat menjadi usang
- Sulit menjawab semua pertanyaan desain di awal, dan masalah nyata baru terungkap setelah kode ditulis
- Jika tim dapat memiliki disiplin yang memadai, belajar sambil hacking bisa lebih efisien daripada “desain”
1 komentar
Opini Hacker News
Ini disebut prototyping, merupakan bagian yang bernilai dalam proses desain, dan sebagian orang juga menyebutnya “pathfinding”
Semua itu adalah masukan untuk desain, tetapi desain dengan ukuran yang tepat tetap diperlukan. Kalau tidak, itu hanya membuat sesuatu seadanya saat itu juga. Perlu mendefinisikan masalah apa yang ingin diselesaikan dan apa solusinya. Kadang dokumen 1 halaman tanpa tinjauan formal sudah cukup, kadang diperlukan dokumen beberapa halaman dengan tinjauan dan iterasi umpan balik selama berminggu-minggu
Jangan lupa: “Coding selama beberapa minggu bisa menghemat perencanaan beberapa jam” ;)
Justru kebalikannya jauh lebih sering benar. Orang-orang merencanakan dan terus merencanakan, sampai rencana itu bukan hanya tidak berarti, tetapi secara aktif merusak produktivitas
Coding selama beberapa minggu bisa menghemat perencanaan beberapa jam, tetapi perencanaan selama beberapa minggu juga bisa terbuang sia-sia. Di atas kertas, hal yang tidak masuk akal atau mustahil pun mudah ditulis. Misalnya, “mengecat armada unicorn dengan warna setengah sedih”
Idealnya, desain dan prototipe harus berevolusi bersama, berkembang secara spiral seperti heliks ganda DNA, dengan iterasi di satu sisi mendorong iterasi berikutnya di sisi lain. Keuntungan besar saat condong ke pembuatan prototipe adalah, setelah satu putaran selesai, yang tersisa adalah perangkat lunak yang benar-benar melakukan sesuatu. Setelah putaran desain selesai, secara praktis tidak banyak yang tersisa
Dan sampai tahap implementasi pun, kemungkinan kode untuk dibuang harus tetap diprioritaskan. Semakin mudah dihapus, semakin baik
Namun rekayasa perangkat lunak tanpa dokumen desain atau spesifikasi apa pun, meski ringkas sekalipun, bukanlah rekayasa, melainkan lebih mirip membangun rumah pohon
Semakin besar skala dan pentingnya proyek, semakin cepat masalah dan utang teknis mulai terlihat
Menulis sangat bermanfaat untuk menjelajahi ruang masalah
Sering kali saya merasa sudah memahami masalah dengan pasti, tetapi begitu mulai menuliskannya, muncul pertanyaan baru yang penting. Hal-hal seperti ini biasanya lebih mudah terlihat dari sudut pandang yang lebih abstrak, atau mungkin tidak muncul pada beberapa milestone rilis pertama
Saya teringat seorang mentor yang saya temui di awal karier. Ia pernah merancang ulang konfigurasi active/active untuk gateway pembayaran, lalu membuka Lucidchart dan berkata, “Diagram ini mewakili 6 bulan hidup saya”
Tidak selalu perlu atau membantu, tetapi saat dibutuhkan, beberapa hari perencanaan bisa menghemat berminggu-minggu coding
Karena ia bisa memprediksi jauh sebelumnya di mana masalah akan muncul, proyek selalu berjalan mulus. Jika terlihat masalah atau ketidakpastian, ia hanya memodelkan bagian itu, lalu kembali ke whiteboard dan melanjutkan
Sebagai analogi, ini seperti merencanakan perjalanan mobil dengan peta. Dokumen desain zaman sekarang hanya menandai jalan lalu langsung mengemudi, sementara peta whiteboard atasan itu “terlalu banyak merencanakan” sampai ke tempat mengisi bahan bakar, jam buka objek wisata, dokumen untuk melintasi perbatasan, total anggaran, perlengkapan darurat, Plan A dan Plan B
Sangat membosankan, tetapi jauh lebih baik daripada kode sekali buang. Sekarang, tidak merencanakan secara berlebihan terasa seperti kemalasan
Tentu, ungkapan “semua orang punya rencana sampai kena pukul” memang benar, tetapi itu berlaku untuk perang, politik, dan negosiasi, bukan untuk coding
Pada akhirnya, PR yang bagus juga berisi banyak tulisan dan memberi efek yang sama. Menurut saya, draft PR yang terdokumentasi dengan baik lebih baik daripada proposal desain murni. Sebab jika hanya menulis, kita bisa lupa pada batasan penting yang baru terpikir saat berada di dalam kode
-- Dick Guindon
Masalah terbesar yang saya alami dengan dokumen desain adalah tidak ada yang membacanya. Bahkan ketika pemberi kerja mewajibkannya
Masalah terbesar yang saya alami dengan prototyping adalah orang-orang melihatnya sebagai “kode rilis” dan memaksa agar itu dipakai sebagai kode final
Karena itu, pendekatan campuran paling cocok. Saya menghabiskan banyak waktu untuk perencanaan dan dokumentasi, tetapi pada dasarnya melakukannya untuk diri sendiri, lalu menulis kode prototipe berkualitas rilis agar nantinya boleh dipakai di produk final
Dokumen desain menjadi sekumpulan catatan mentah yang tidak benar-benar dipahami siapa pun selain penulisnya, dan orang-orang jadi takut membaca catatan seperti itu
Namun jika penulis dokumen desain diberi tahu bahwa ini seperti laporan akhir semester yang akan dinilai di sekolah, setelah beberapa kali menulis ulang, tulisannya bisa menjadi cukup baik. Gejalanya sama seperti prototyping. Orang-orang menulis dokumen desain berkualitas draft, lalu berharap secara ajaib itu menjadi tulisan bagus yang cocok untuk audiens yang lebih luas. Seperti halnya kode prototipe perlu direfaktor beberapa kali, dokumen desain juga perlu beberapa putaran penyuntingan
Agar dapat menghindari perpanjangan kontrak, mereka harus membuat dan merilis sesuatu sebelum tenggat, dan kontrak itu diperkirakan akan menelan biaya jutaan dolar. Namun, ternyata dengan sumber daya dan pendekatan yang direncanakan, pekerjaan itu tidak akan selesai tepat waktu
Jadi mereka mendapat persetujuan untuk cepat-cepat membuat versi sementara, parsial, dan tidak optimal, dan berkat itu mereka bisa lepas landas tepat waktu
Berkat itu, mereka bisa terbang sementara orang lain menyelesaikan versi permanen dan benar untuk bagian sayap tersebut
Saat benar-benar terbang, mereka juga menemukan kebutuhan yang terlewat dari desain awal. Hal ini menunda rilis produksi versi yang benar, tetapi pada versi hack saya, saya bisa menambahkannya dengan cepat dan tetap mempertahankan penerbangan
Versi hack saya juga berperan sebagai alat dukungan produksi. Saat versi permanen memiliki bug dan harus dihentikan, versi itu juga menjadi jalur alternatif. Memang hack yang parsial dan tidak sempurna, tetapi ada kelebihannya
Ada juga yang mengeluh karena bahasa yang digunakan kurang umum. Namun, perlu diingat bahwa dengan sumber daya dan pendekatan yang ada, sejak awal mereka tidak akan bisa lepas landas
Untuk memenuhi tenggat, mereka akan membutuhkan lebih banyak developer atau developer yang lebih cepat dalam bahasa pilihan. Jika ada karyawan saat itu, termasuk saya, yang punya kelonggaran dan kemampuan untuk seproduktif hack bahasa non-arus-utama saya dengan bahasa pilihan, orang itu pasti sudah ditugaskan membuat solusi permanen tepat waktu. Opsi seperti itu tidak ada
Bagaimanapun, jika sudah ada alat dukungan produksi, itu juga bisa menjadi tempat bagi fitur prototipe untuk tinggal sementara waktu
Ini satu lagi tulisan opini, tanpa data dan bahkan tanpa contoh konkret
Saya tahu semua software engineer punya pendapat kuat, tetapi ini argumen yang lemah. Jika menurut Anda pekerjaan ini adalah menulis banyak kode untuk melihat mana yang benar, Anda akan segera digantikan oleh GPT. Karena ia bisa melakukannya lebih cepat dan lebih murah. Bagian yang sulit selalu ada pada mencapai kesepakatan tentang apa yang harus dibuat, dan Anda tidak bisa menghindari masalah itu dengan coding
Jika requirement sudah jelas dan apa yang akan saya berikan juga jelas bagi semua orang, itu tidak diperlukan. Bisa langsung masuk ke prototyping. Namun, pada proyek yang serius, kasus seperti ini jarang terjadi. Selalu ada unknown unknowns yang harus digali dari stakeholder, dan analisis teknis adalah cara yang baik untuk melakukannya
Kotak dan garis putus-putus punya batas. Jika terpisah dari kode nyata, kita lupa kendala sebenarnya. Hal-hal yang benar-benar memperlambat pekerjaan tidak muncul di Google Docs. Dalam pengalaman saya, menunjuk ke draft PR sambil mengatakan “yang saya pikirkan seperti ini” membawa kita lebih jauh
Dan benar, ini 100% opini. Ini blog pribadi, bukan makalah peer-reviewed :) Tidak apa-apa kalau salah
Tanpa sesuatu yang nyata untuk menahan percakapan seperti kode, diskusi tentang desain abstrak pada akhirnya cenderung mengalir menjadi debat tanpa kesimpulan seperti “tali imajiner saya lebih panjang daripada tali imajiner Anda”
Dalam pengalaman saya, feedback terhadap kode dan feedback terhadap desain adalah jenis yang sangat berbeda
Dokumen desain memancing pertanyaan “mengapa” yang membuat semua orang memikirkan ruang masalah. Misalnya, komentar seperti “Mengapa mengusulkan webserver Rust padahal di perusahaan belum ada yang mahir Rust?” bisa muncul
Pertanyaan halus seperti ini jauh lebih sulit diajukan setelah prototipe mulai berjalan. Mudah sekali berubah menjadi “Mengapa pengalaman tim penting? Ini berjalan dengan baik! Kalau tidak dihalangi, kita bisa memoles prototipe ini saja dan memasukkannya ke produksi dalam seminggu!”
Terutama ketika yang direview hanya desain, bukan kode yang berjalan
Kita membayangkan pekerjaan software berjalan dalam alur yang rapi dan teratur
Menulis dokumen desain, membuat perubahan kecil dan bertahap untuk merilis fitur dalam PR, dan riwayat Git bersih serta tertata. Terlihat seperti kemajuan yang stabil
Siapa yang membayangkan seperti itu? Profesor yang mengajar kelas rekayasa perangkat lunak?
Ini mengingatkan saya pada orang-orang yang mengira prosa, esai, cerita, novel, dan sebagainya ditulis dengan membuat outline lalu “mengisinya” menjadi prosa. Seolah-olah dalam proses itu tidak ada penemuan apa pun yang mengharuskan dokumen ditulis ulang atau disusun ulang. Tidak ada yang menulis seperti itu. Draft pertama selalu buruk, dan hampir semua tulisan bagus adalah hasil revisi besar
Menulis kode jauh lebih mirip menulis daripada membangun rumah atau jembatan
Proses menelusuri logika baru baris demi baris serta melihat variabel dan memori benar-benar membantu memperbaiki kode. Saya menemukan hal-hal seperti “oh, variabel lokal ini tidak perlu”, “di sini sebaiknya tambahkan variabel sementara agar mudah di-debug”, “kode ini aneh kalau collection yang diiterasi kosong”
Berapa pun usia saya, sebanyak apa pun kode yang saya tulis, saat men-debug kode baru yang saya tulis, saya selalu menemukan hal baru. Mungkin bisa dibandingkan dengan penulis yang setelah membuat draft membacanya kembali, atau membacakannya keras-keras kepada diri sendiri atau orang lain
Saya sangat menyukai proses mencatat keputusan desain sebagai thread komentar yang sedang berjalan, alih-alih mencoba memformalkannya dalam satu dokumen
Saya menggunakan issue GitHub seperti ini, tetapi secara fungsional sama dengan menggunakan PR. PR pada dasarnya adalah issue GitHub yang ditempeli branch kode
Tulisan saya yang membahas lebih lanjut cara saya melakukan ini ada di sini: https://simonwillison.net/2022/Jan/12/how-i-build-a-feature/...
Dengan kata lain, bagaimana Anda merangkum thread itu menjadi dokumen final?
Saya tidak menganggap keduanya saling eksklusif
Dokumen desain adalah konsep yang lebih luas, dan tujuannya adalah komunikasi
Terkadang hal itu harus disampaikan dengan cara selain kode. Diagram, gambar, tulisan, dan sebagainya diperlukan
Sangat sulit bagi orang yang bukan penulisnya atau yang tidak terlalu familier dengan kodenya untuk memahami perubahan secara sekilas. Agar pembaca dapat dengan cepat membangun model mental yang tepat untuk memahami perubahan dalam konteksnya, diperlukan penjelasan dan dokumentasi tingkat tinggi
Jika Anda bisa melihat diff 1000 baris dan mengatakan dengan tepat apa yang dilakukannya, dan yang lebih penting, apa dampaknya ke upstream dan downstream, maka Anda sedang berbohong, atau Anda bekerja di lingkungan yang benar-benar tertutup dan dapat diverifikasi secara sempurna sampai-sampai saya sangat iri
Dokumen desain membantu mengurangi jumlah prototipe menjadi 2–3 dari berbagai opsi yang mungkin. Ini sangat berguna terutama saat mengeksplorasi penambahan sesuatu yang benar-benar baru
Saya merasa menunjukkan sesuatu lebih baik daripada sekadar menjelaskannya, tetapi orang yang baru bergabung lebih mudah memahaminya lewat dokumen desain daripada lewat kode