Fenomena Preferensi Throwaway Code dibanding Dokumen Desain

 (softwaredoug.com)
3 poin oleh GN⁺ 2024-12-16 | 1 komentar | Bagikan ke WhatsApp

  • Kita membayangkan pengembangan perangkat lunak mengikuti alur yang rapi dan teratur

    • Menulis dokumen desain, lalu merilis perubahan kecil melalui PR untuk mengimplementasikan fitur
    • Riwayat Git terlihat bersih dan tertata
    • Namun kenyataannya berbeda

  • Perbedaan antara dokumen desain dan implementasi nyata

    • Mengimplementasikan dokumen desain apa adanya adalah ilusi
    • Saat mulai coding, isi dokumen desain akan ikut direvisi
    • Rencana tidak akan bertahan setelah bersentuhan dengan musuh

  • Metodologi desain baru: tenggelam dalam coding

    • Menggunakan draft PR untuk mengimplementasikan prototipe
    • Mendapatkan umpan balik lebih awal lalu menyesuaikan pendekatan
    • Mendokumentasikan draft PR sebagai ide desain historis
    • Siap untuk membuang draft PR sepenuhnya
    • Dari draft PR, melanjutkan PR secara bertahap
    • Menguji setiap PR secara bertahap dan memperkuat ketahanannya

  • Pentingnya kedewasaan

    • Kemampuan untuk membuang ide yang sudah dikodingkan itu penting
    • Yang penting bukan jumlah baris kode, melainkan transfer pengetahuan organisasi
    • Menyelaraskan hal-hal penting sejak awal agar pekerjaan prototipe tidak terbuang sia-sia

  • Cara menggunakan PR sebagai dokumentasi

    • PR adalah salah satu bentuk dokumentasi terbaik bagi developer
    • PR adalah artefak historis yang merefleksikan keadaan pada titik waktu tertentu
    • Dokumen desain sering kali memberikan informasi yang berbeda dari kenyataan

  • Pentingnya prototipe

    • Prototipe lebih berharga daripada 1000 dokumen desain
    • Untuk mendorong perubahan, itu harus dilakukan dengan kode, bukan dokumen
    • Organisasi perlu melihat prototipe bukan sebagai jawaban, melainkan sebagai pertanyaan

  • Kegunaan dokumen desain

    • Berguna untuk mengorganisasi dan mengarsipkan umpan balik dari berbagai pemangku kepentingan
    • Berguna ketika ide terlalu konseptual atau bersifat jangka panjang
    • Berguna ketika mengekspresikan ide lewat tulisan lebih efisien daripada lewat coding
    • Berguna ketika organisasi tidak memiliki disiplin untuk membuang solusi pertama
    • Memberikan lingkungan yang aman agar staf junior dapat mempertanyakan ide developer senior

  • Penggunaan dokumen desain yang keliru

    • Digunakan untuk memperlambat proses bagi developer yang kurang berpengalaman
    • Dipakai sebagai dokumentasi tetapi cepat usang
    • Berusaha menyelesaikan semua masalah desain, padahal masalah nyata ditemukan lewat coding

  • Jika tim bisa memiliki disiplin, hacking jauh lebih efisien daripada desain

    • Disarankan untuk membangun disiplin semacam ini di dalam organisasi
    • Pada akhirnya, kode punya daya yang lebih besar daripada kata-kata

Bacaan terkait

1 komentar

 
GN⁺ 2024-12-16
Opini Hacker News

  • Prototyping adalah bagian penting dari proses desain, dan perlu mendefinisikan masalah serta memperjelas solusinya

    • Terkadang dokumen sederhana sudah cukup, tetapi kadang dibutuhkan banyak masukan dan iterasi
    • Ada ungkapan, "beberapa minggu coding bisa menghemat beberapa jam perencanaan"

  • Menulis bermanfaat untuk mengeksplorasi masalah, dan ada pengalaman merasa sudah memahami masalah tetapi saat menulis justru muncul pertanyaan baru

    • Ini mengingatkan pada kasus seorang mentor yang menggunakan Lucidchart untuk menjelaskan pekerjaan selama 6 bulan

  • Ada pengalaman menggunakan solusi sementara untuk menyelesaikan proyek tepat waktu

    • Solusi sementara itu juga dipakai sebagai alat pendukung produksi, dan dimanfaatkan sebagai jalur alternatif jika versi permanennya dihentikan

  • Masalah terbesar dokumen desain adalah tidak ada yang membacanya

    • Masalah prototyping adalah orang-orang menganggapnya sebagai kode final
    • Lebih menyukai pendekatan hibrida: perencanaan dan dokumentasi dilakukan dengan saksama, sambil menulis kode prototipe dengan kualitas yang bisa dipakai pada produk akhir

  • Ada perbedaan besar dalam umpan balik terhadap kode dan desain

    • Dokumen desain mendorong pertanyaan "mengapa" tentang ruang masalah
    • Jika prototipe sudah berjalan, pertanyaan seperti ini menjadi sulit diajukan

  • Jika deskripsi pekerjaannya adalah menulis banyak kode untuk melihat apa yang efektif, GPT bisa menggantikannya dengan lebih cepat dan murah

    • Mendapatkan kesepakatan tentang apa yang harus dibangun selalu menjadi tantangan

  • Hampir tidak ada orang yang membayangkan pengembangan perangkat lunak mengikuti alur yang rapi dan teratur

    • Menulis kode mirip seperti menulis, draf awal selalu buruk, dan tulisan yang baik lahir dari banyak revisi

  • Pernah melihat kode menumpuk seperti Jenga hingga tidak ada yang ingin menyentuhnya

  • Lebih menyukai proses mendokumentasikan keputusan desain menggunakan thread komentar yang berkelanjutan

    • Proses ini dijalankan menggunakan GitHub Issues

  • Sedang memikirkan pendekatan ini, dan dalam skenario terburuk bisa membuang banyak waktu

    • Menulis dokumen desain paling bermanfaat ketika masalah sudah dipikirkan cukup matang sehingga bisa menjabarkan sifat-sifat yang diperlukan untuk implementasi yang benar
    • Mengimplementasikan solusi parsial lalu meningkatkannya secara bertahap juga berhasil