Tahun 2024, Cara Saya Melakukan Pemrograman

 (akkartik.name)
2 poin oleh GN⁺ 2024-08-06 | 1 komentar | Bagikan ke WhatsApp
  • Saya pernah membahas cara memilih program yang bisa digunakan dalam jangka panjang dan membangun infrastruktur yang dapat diandalkan, tetapi saya mengakui bahwa saya masih belum melakukannya dengan baik
  • Selama sebulan terakhir saya menulis ulang inti dari program yang telah saya gunakan selama dua tahun terakhir, dan lewat proses itu saya meninjau kembali perubahan dalam cara saya memrogram sepanjang hidup saya

Tahun 2015

  • Saya meragukan abstraksi dan menekankan pentingnya pengujian serta kontrol versi
  • Saya menganggap penyalahgunaan abstraksi dan kurangnya pengujian/kontrol versi sebagai penyebab masalah
  • Saya merancang platform Mu1 dengan pengujian dan layer sebagai batasan dasarnya

Tahun 2017

  • Mulai mengerjakan ulang Mu1 menjadi Mu yang sekarang
  • Awalnya saya memakai semua ide baru tentang pengujian dan layer, tetapi perlahan berhenti menggunakannya
  • Mu memiliki banyak pengujian, tetapi dengan cara yang lama, dan infrastruktur layer tidak saya porting

Tahun 2022

  • Mulai mengerjakan Freewheeling Apps
  • Awalnya dimulai tanpa pengujian, lalu saya menulis pengujian yang sangat menyeluruh untuk bagian inti editor teks
  • Bagian sisanya sulit diuji, tetapi tetap berjalan dengan baik

Tahun 2024

  • Sebulan yang lalu saya menghapus semua pengujian
  • Saya mengerjakan ulang editor teks secara radikal dengan cara yang dulu membuat saya khawatir tentang konflik merge dengan Freewheeling Apps lain
  • Saya tidak lagi memikirkan kontrol versi
  • Dengan meninggalkan pengujian dan versi, saya justru membuat program yang jauh lebih baik

Pandangan terpadu saya saat ini tentang pemrograman yang berkelanjutan

  1. Membangun secara berkelanjutan untuk banyak orang terlalu sulit, jadi jangan coba-coba
  2. Sebagian besar perangkat lunak telah terinfeksi oleh insentif untuk melayani banyak orang dalam jangka pendek. Fokuslah pada perangkat lunak yang logonya sedikit, mudah dibangun, memiliki sedikit dependensi, dan tidak melakukan pembaruan otomatis
  3. Perubahan kecil dalam konteks dapat secara mendasar mengubah seberapa cocok sebuah program dengan konteks tersebut
  4. Program baru, dengan satu atau lain cara, akan menuju wilayah yang belum diketahui. Sering kali kita tidak benar-benar tahu apa yang sedang kita lakukan ke arah mana pun
  5. Tipe, abstraksi, pengujian, versi, state machine, immutability, analisis formal, dan sebagainya adalah alat yang bisa digunakan di medan yang belum akrab
  6. Pada akhirnya kita tak terhindarkan akan menggunakan beberapa alat ini secara berlebihan. Jumlah penggunaan yang ideal jauh lebih kecil daripada yang kita kira. Penggunaan berlebih adalah utang teknis
  7. Ketika pemahaman terhadap konteks sudah stabil, ada nilai dalam membuang sebagian besar program dan memulai lagi dari awal
  8. Sebelum menulis ulang, kita perlu menaruh semua hal yang diinginkan dari program dan semua skenario yang harus ditangani program itu di kepala pada saat yang sama
  9. Bangun semuanya sekaligus
  • Pengujian dan kontrol versi menghalangi pencapaian tahap akhir dari evolusi ini
  • Pengujian membuat kita melupakan kekhawatiran, dan kontrol versi membuat kita terikat pada masa lalu

Opini GN⁺

  • Jika program menjadi terlalu kompleks, mengingat semuanya pada langkah 8 bisa menjadi mustahil. Ini berlaku untuk sebagian besar perangkat lunak, terutama perangkat lunak yang ditulis oleh lebih dari satu orang
  • Tidak semua perangkat lunak harus mencapai langkah 9. Banyak Freewheeling Apps cukup sederhana dan berevolusi cukup lambat sehingga dapat stabil tanpa bug hanya dengan digunakan oleh beberapa orang, terlepas dari pilihan desain awalnya
  • Desain yang berpusat pada data jelas berguna untuk mencapai langkah 9. Ini bukan alat yang bisa diterapkan secara membabi buta, melainkan pola pikir untuk melihat gambaran besar tentang bagaimana program mengakses data, melampaui immediate data structure choices
  • Langkah-langkah ini mungkin tidak sepenuhnya benar. Bisa jadi ada alat yang kurang saya kuasai dan sedang saya remehkan
  • Saya penasaran langkah apa yang mungkin ada setelah tahapan-tahapan ini

Bacaan terkait

1 komentar

 
GN⁺ 2024-08-06
Komentar Hacker News

  • Tanpa pengujian, masalah tidak terlihat sehingga seolah-olah masalahnya hilang

    • Setiap kali melakukan pengujian, selalu menemukan bug
    • Menghapus pengujian berarti menipu diri sendiri
    • Setelah membaca halamannya, muncul kesan bahwa penulis lelah dengan pengelolaan mutasi/konfigurasi
    • Harus punya banyak pengguna agar bisa menghasilkan uang

  • Setelah meninggalkan pengujian dan versi, justru mendapatkan program yang lebih baik

    • Sulit memahami tidak menggunakan pengelolaan kode sumber pada tahun 2024
    • Fitur untuk bekerja di beberapa perangkat, melihat riwayat, rollback, dan membuat branch sangat berguna

  • Awalnya mengira penulis salah, tetapi ada wawasan yang bagus

    • Workflow ini sangat cocok untuk penulis
    • Mungkin pernah mengalami Git atau pengujian otomatis menurunkan produktivitas
    • Ada alternatif yang lebih sederhana juga (misalnya Dropbox, FTP)
    • Penulis suka membuat program kecil
    • Pengujian otomatis berguna, tetapi dalam kasus penulis nilainya mungkin tidak terlihat

  • Kontrol versi dan pengujian otomatis menyelesaikan masalah nyata

    • Memulai proyek hari ini tanpa kontrol versi adalah tindakan gila
    • Pengujian otomatis adalah praktik terbaik
    • Dalam use case spesifik penulis, ini mungkin masuk akal

  • Saat menulis/memfaktor ulang program besar, penting untuk menulis, membuang, lalu menulis ulang

  • Artikel ini membingungkan

    • Bertanya-tanya mengapa ini menjadi yang pertama di-upvote

  • Perubahan kecil bisa sangat mengubah kecocokan sebuah program

    • Ada contoh K9 Mail
    • K9 Mail dimulai dengan UI yang tidak konvensional
    • Banyak pengguna mengeluhkan UI baru
    • Perubahan kecil merusak kecocokan aplikasi
    • Masih menggunakan versi lama

  • Membuat software sendirian dan membuatnya dalam tim adalah dua hal yang sepenuhnya berbeda

    • Pengujian adalah sarana, bukan tujuan
    • Saat percaya diri, pengujian dilakukan lebih sedikit
    • Menambahkan integration test pada bagian yang penting
    • Unit test berguna untuk desain API baru

  • Mulai mengerjakan Freewheeling Apps pada tahun 2022

    • Merasa frustrasi karena tidak ada pengujian
    • Test suite memberi kepercayaan diri untuk mengembangkan sistem
    • Saat kompleksitas fitur meningkat, pengujian menjadi sulit
    • Menghapus semua pengujian pada tahun 2024
    • Filosofi ini hanya berlaku untuk satu orang

  • Tidak setuju bahwa perubahan kecil bisa sangat mengubah kecocokan program

    • Jangka pendek adalah untuk beradaptasi dengan perubahan kecil

  • Menyukai penulis dan menyukai proyek Mu

    • Ini adalah mesin Lisp modern

  • Merasa kewalahan oleh kompleksitas rekayasa perangkat lunak

    • Menolak semua ide bukanlah solusi
    • Tetap perlu menulis pengujian, menggunakan VCS, dan memakai abstraksi
    • Harus tahu mengapa menggunakannya, dan jika tidak ada alasannya, perlu dievaluasi ulang