Cara Saya Memprogram pada 2024

 (akkartik.name)
2 poin oleh GN⁺ 2024-08-06 | 1 komentar | Bagikan ke WhatsApp
  • Pengalaman menulis ulang inti sebuah program yang telah saya gunakan dan perbaiki sendiri selama 2 tahun dalam waktu satu bulan menggoyahkan keyakinan lama saya tentang pengujian dan kontrol versi
  • Pada 2015, saya menganggap pengujian dan versi sebagai inti perangkat lunak yang bertahan lama, lebih penting daripada abstraksi yang buruk, tetapi lewat Mu dan Freewheeling Apps, cara kerja nyata saya makin berubah
  • Saya kini melihat program yang bertahan lama tidak semestinya dibuat untuk banyak orang, melainkan dalam lingkup orang, konteks, dan fitur yang dipahami dengan baik, sambil menerima batas realistis seperti Dunbar's number
  • Tipe, abstraksi, pengujian, versi, state machine, imutabilitas, dan analisis formal berguna di wilayah yang belum dikenal, tetapi jika berlebihan akan menjadi utang teknis yang menutupi kompleksitas yang tidak perlu
  • Setelah pemahaman konteks menjadi stabil, ada nilai dalam membuang bagian besar lalu membuatnya kembali; skenario yang diperlukan harus dimuat sekaligus dalam kepala, lalu menyusun keseluruhannya dalam sekali jalan

Perubahan pandangan tentang pengujian dan kontrol versi

  • Saya terus bergulat dengan persoalan memilih dan membuat sendiri program yang bisa diandalkan untuk waktu lama, tetapi saya sendiri tidak merasa benar-benar pandai melakukannya
  • Selama satu bulan terakhir, saya menulis ulang inti sebuah program yang telah saya gunakan dan modifikasi secara bertahap selama 2 tahun
    • Setelah itu, beberapa hari berikutnya dipakai untuk merapikan apa yang saya pelajari dan ke mana akan melangkah berikutnya
    • Pekerjaan kali ini mulai memperlihatkan perubahan yang lebih luas dalam perjalanan hidup saya
  • Pada 2015, saya mencurigai abstraksi dan menekankan pengujian serta kontrol versi
    • Saya melihat banyak abstraksi buruk di dalam kode, dan menganggap pengujian serta versi sebagai kemajuan inti pada dekade 2000-an
    • Saya mencari akar masalah pada insentif yang buruk, abstraksi berlebihan, serta kurangnya pengujian dan versi
    • Mu1 adalah upaya merancang platform yang menjadikan pengujian dan layers sebagai batasan dasar
  • Pada 2017, saya mulai mengerjakan ulang Mu1 menjadi Mu yang sekarang
    • Pada tahap awal, saya menggunakan semua ide baru tentang pengujian dan layer
    • Seiring waktu, saya makin jarang memakai ide-ide itu
    • Saat ini Mu memiliki banyak pengujian, tetapi sebagian besar adalah pengujian biasa, dan infrastruktur layer tidak berhasil saya pindahkan
  • Pada 2022, saya mulai membuat Freewheeling Apps
    • Awalnya tidak ada pengujian, lalu kemudian saya menulis pengujian menyeluruh untuk editor teks, salah satu bagian intinya
    • Sulit menemukan cara menguji bagian lainnya, tetapi pengembangan tetap berjalan cukup baik tanpa pengujian
  • Pada 2024, saya menghapus semua pengujian
    • Saya mulai membuat ulang editor teks secara besar-besaran, dan pendekatan ini bisa membuat saya khawatir soal konflik merge dengan Freewheeling Apps lainnya
    • Akibatnya, saya juga berhenti memikirkan kontrol versi
    • Setelah meninggalkan pengujian dan versi lalu mendapatkan program yang lebih baik, disonansi kognitif dengan keyakinan lama makin sulit diabaikan

Rangkuman saya saat ini untuk program yang bertahan lama

  • Membuat sesuatu yang bertahan lama untuk banyak orang terlalu sulit, jadi menurut saya lebih baik tidak mencobanya sejak awal
    • Kita harus dikendalikan oleh hal yang dikenal baik, orang yang dikenal baik, dan Dunbar's number
  • Menurut saya, sebagian besar perangkat lunak di dunia telah terinfeksi insentif untuk melayani banyak orang dalam jangka pendek
    • Sebisa mungkin saya berfokus pada perangkat lunak yang situs webnya tidak dipenuhi banyak logo
    • Saya lebih menyukai perangkat lunak yang mudah dibuat, punya sedikit dependensi, dan tidak melakukan pembaruan otomatis
    • Jika disaring dengan batasan seperti ini, jumlah perangkat lunak yang bertahan lama yang telah dibuat umat manusia sejauh ini sangat kecil
  • Perubahan kecil dalam konteks seperti orang, tempat, dan fitur yang ingin didukung pun bisa sangat mengubah seberapa cocok sebuah program dengan konteks tersebut
    • Dalam lingkungan yang didominasi cara pikir jangka pendek, sulit bersiap menghadapi fakta ini
  • Karena jumlah pekerjaan masa lalu kecil dan cakupan penerapan per program juga rendah, program yang diputuskan untuk dibuat baru kemungkinan besar akan memasuki wilayah yang belum dikenal dalam satu atau lain bentuk
    • Saat hendak memasukkan “drawing lines” khusus ke editor teks pun muncul berbagai pertanyaan
      • Bisakah kursor berada di atas gambar
      • Bisakah menggambar pada satu baris ketika kursor berada di baris lain
      • Gambar lebih tinggi daripada baris teks; bisakah hanya sebagian gambar terlihat di bagian atas layar
      • Bisakah menggambar di atas gambar yang hanya terlihat sebagian
    • Jawaban untuk pertanyaan-pertanyaan ini lama tidak optimal, sehingga solusi sementara terus ditumpuk di atas solusi sementara lainnya

Alat memang perlu, tetapi jika berlebihan menjadi utang teknis

  • Tipe, abstraksi, pengujian, versi, state machine, imutabilitas, dan analisis formal adalah alat yang bisa digunakan di medan yang belum dikenal
    • Gunakan sesuai kebutuhan dan selera
  • Orang cenderung berlebihan memakai alat yang menarik baginya
    • Menurut saya, kadar ideal penggunaan alat-alat ini sangat kecil
    • Jauh lebih kecil daripada intuisi yang dipelajari dari lingkungan yang didominasi cara pikir jangka pendek
  • Jika alat digunakan berlebihan, ia menjadi utang teknis
    • Makin sulit menyadari bahwa program menjadi rumit tanpa perlu
    • Program menjadi kurang tahan lama dibanding keadaan yang sebenarnya memungkinkan
    • Saat konteks berubah, program menjadi lebih sulit diubah

Menulis ulang dan “membuat semuanya sekaligus”

  • Setelah pemahaman tentang konteks menjadi stabil, ada nilai dalam membuang bagian besar program dan memulai lagi dari awal
  • Sebelum menulis ulang, semua hal yang diinginkan dari program dan semua skenario yang harus ditangani perlu dibawa sekaligus ke dalam kepala
    • Proses ini sulit, tetapi tujuannya adalah mencapai keadaan ketika semuanya bisa dibuat sekaligus
  • Cara akhirnya adalah membuat semuanya sekaligus
  • Dalam pengalaman kali ini, pengujian dan versi justru menghalangi saya mencapai ujung evolusi ini
    • Pengujian membuat saya melupakan masalah yang seharusnya dikhawatirkan
    • Kontrol versi membuat saya terus terpaku pada masa lalu
    • Keduanya kontraproduktif, dan perlu perubahan arah besar untuk melepaskannya
  • Saya melihat semua perangkat lunak yang telah saya buat sejauh ini dan Freewheeling Apps berada di tahap 6 dari lintasan ini

Batas kompleksitas dan desain berorientasi data

  • Jika program menjadi terlalu kompleks, pada tahap 8 mungkin mustahil memuatnya seluruhnya di dalam kepala
    • Menurut saya, sebagian besar perangkat lunak sejauh ini, terutama perangkat lunak yang ditulis oleh lebih dari satu-dua orang, termasuk kategori ini
    • Bahkan editor teks kecil pun terasa membebani, sehingga saya menghabiskan banyak waktu dalam bulan itu untuk bersiap menghadapi rasa takut tersebut
  • Tidak semua perangkat lunak harus mencapai tahap 9
    • Banyak Freewheeling Apps cukup sederhana dan berevolusi perlahan
    • Menurut saya, hanya dengan digunakan oleh sedikit orang, ia bisa stabil tanpa bug terlepas dari pilihan desain awalnya
    • Terutama karena sekarang saya tahu cara menyederhanakan satu bagian inti yang kompleks
  • Meski begitu, ketika nilainya muncul, ada baiknya mengetahui cara memperbaikinya
  • Sebagai metode yang tampak jelas berguna untuk mencapai tahap 9, saya menunjuk data-oriented design
    • Ini bukan alat yang bisa diterapkan secara membabi buta, melainkan cara berpikir untuk melihat gambaran besar tentang bagaimana program mengakses data
    • Alat seperti ECS tidak boleh sampai menutupi aktivitas intelektual yang esensial
  • Pembagian tahap ini mungkin tidak sepenuhnya tepat
    • Saya mungkin meremehkan alat-alat yang belum banyak saya alami
    • Apa yang ada di luar tahap-tahap ini juga masih menjadi pertanyaan terbuka
  • Jejak perubahan pemikiran sejak tulisan tentang cara memprogram yang saya tulis pada 2019 bisa terlihat

Bacaan terkait

1 komentar

 
GN⁺ 2024-08-06
Komentar Hacker News

  • Jika tidak ada pengujian, kegagalan pengujian tidak akan terlihat, jadi masalahnya hanya tampak seperti hilang
    Saya belum pernah menguji sesuatu lalu tidak menemukan bug, dan sebagian besar yang saya uji adalah hal-hal yang sebelumnya saya kira sudah siap dirilis
    Jika Anda menghapus pengujian, pada akhirnya kemungkinan besar satu-satunya orang yang Anda tipu adalah diri sendiri. Dari membaca tulisannya, ia tampak lebih lelah dengan variasi/manajemen konfigurasi daripada pengujian itu sendiri, dan itu sangat bisa dipahami. Namun, harus ada jumlah pengguna agar bisa menghasilkan uang, dan kalau ini masalah yang mudah, pasar pasti sudah jenuh dengan solusi serbaguna

    • Menurut saya ini bergantung pada domain. Pada codebase yang sedang saya kerjakan sekarang, sebagian bagiannya sangat terbantu oleh pengujian saat refactoring, tetapi bagian lain punya banyak perilaku UI sehingga pengujian manual jauh lebih cepat
      Jika UI atau workflow berubah terlalu cepat, kita jadi tidak menulis pengujian karena tahu itu akan tidak berguna pada iterasi berikutnya; sebaliknya, jika berubah terlalu lambat, bagian itu tidak akan disentuh lagi, sehingga kecil kemungkinan bug baru masuk lewat refactoring. Pengujian atau tipe bukanlah cawan suci yang serba bisa, melainkan alat yang sesuai dengan pekerjaan. Saya belum pernah melihat codebase yang, meskipun punya cakupan pengujian yang baik, tidak menemukan bug lewat pengujian manual atau penggunaan nyata. Sedikit melebih-lebihkan, kalau Anda cukup hebat untuk menulis pengujian yang sempurna, maka tulis saja kode yang sempurna. Kalau Anda tidak bisa menulis pengujian dengan sempurna, bagaimana Anda tahu bahwa pengujian itu lengkap, bebas bug, dan benar-benar berguna?
    • Ungkapan “Pengujian dapat menunjukkan keberadaan bug, tetapi tidak dapat menunjukkan ketiadaannya” lebih sesuai dengan pengalaman saya
      Setiap beberapa bulan saya menemukan bug baru dan dengan tekun menambahkan pengujian, tetapi beberapa bulan kemudian seseorang yang baru memakai 10 menit pertama akan menemukan bug baru lagi. Di versi baru pun pasti ada bug yang bisa ditemukan, tetapi berkat struktur data yang dipilih, saya rasa banyak pengujian lama secara struktural tidak lagi diperlukan. Setidaknya untuk penggunaan ringan, saya berharap ini akan cukup stabil setelah menangkap beberapa bug lagi. Pengujian sangat berharga ketika tim besar terus mengubah codebase, tetapi di sini saya sedang mencoba membuat sesuatu dengan kumpulan fitur yang tetap
    • Saya menonton video Go Testing By Example dari Russ Cox yang direkomendasikan di thread terbaru: https://www.youtube.com/watch?v=X4rxi9jStLo
      Ada banyak sekali saran berguna, tetapi satu hal yang khusus ingin saya sebutkan adalah bahwa kita bisa menguji dengan acuan implementasi yang lebih sederhana, misalnya implementasi brute force. Ada kebijaksanaan yang lebih dalam di sini. Kegunaan pengujian bergantung pada seberapa jauh implementasi pengujian lebih sederhana daripada implementasi yang diuji. Lebih tegas lagi, pengujian hanya berguna ketika lebih sederhana daripada yang diuji. Sebanyak apa pun pengujian yang ditulis, pada akhirnya kita tetap harus menalar kode, dan fakta bahwa sesuatu disebut “pengujian” tidak otomatis membuatnya berguna. Karena itu, saya rasa banyak programmer mewaspadai kebiasaan memecah fungsi menjadi potongan-potongan yang bukan antarmuka berguna hanya supaya mudah diuji, menguji helper sederhana atau query kecil hanya demi cakupan, atau memperkenalkan inversi dependensi dan mocking semata-mata untuk pengujian. Tentu masing-masing bisa punya alasan, tetapi yang penting jangan kehilangan inti persoalannya
    • Dalam kasus saya, setiap kali menulis unit test, bug selalu muncul
      Biasanya saya tidak terlalu memakai gaya test-driven development yang menulis pengujian gagal terlebih dahulu, meski kadang melakukannya. Jadi pengujian seperti ini biasanya ditujukan pada kode yang saya kira sudah berfungsi. Namun, biasanya saya lebih suka test harness daripada unit test[0]. Itu tetap menemukan bug, tetapi alurnya tidak terlalu linear. Ini membuat saya menguji lebih banyak selama pengembangan dan memperbaiki bug saat itu juga
      [0] https://littlegreenviper.com/testing-harness-vs-unit/
    • Fokus pada unit/integration test otomatis adalah tren yang relatif modern, mungkin sejak sekitar akhir 90-an. Sebelum itu pun, perangkat lunak yang cukup besar dan sangat stabil sudah dirilis
      Misalnya, kernel Linux dulu tidak punya banyak pengujian, dan tampaknya sekarang sudah lebih banyak. Unix juga mungkin tidak punya banyak “pengujian”. Compiler cenderung punya pengujian, tetapi sistem operasi lebih sedikit, dan game seperti Doom kemungkinan juga tidak punya banyak pengujian. Pada akhirnya kita harus menemukan titik keseimbangan. Kita tahu pengujian otomatis—unit, integrasi, dan end-to-end test—membantu membuat perangkat lunak berkualitas. Pada saat yang sama, pengujian yang baik tidak selalu mudah ditulis, pengujian yang buruk membuat refactoring sulit, dan pengujian yang tidak stabil menghabiskan banyak waktu dalam proyek besar. Meski begitu, terutama jika Anda mengembangkan sendirian, mencoba berbagai pendekatan dan menemukan yang cocok untuk diri sendiri adalah hal yang menarik

  • Bagian “setelah menyerah pada pengujian dan versi, programnya menjadi jauh lebih baik” sulit dipahami. Saya tidak tahu siapa pada 2024 yang secara sukarela ingin memprogram tanpa manajemen kode sumber
    Bahkan untuk proyek satu orang, kemampuan bekerja dari beberapa perangkat, melihat riwayat, melakukan rollback, dan memakai branch memberi nilai yang sangat besar dengan biaya nyaris nol. Mungkin saja saya salah memahami apa yang dimaksud penulis dengan “versi”

    • Ia sedang mencoba membuat sesuatu yang kecil, cepat, dan kumpulan fiturnya tetap. Ia memutuskan membangun di atas fondasi yang tidak sering berubah, dan latar belakangnya ada lebih lanjut di https://akkartik.name/freewheeling
      Benar bahwa pendekatan ini tidak cocok untuk kebanyakan program yang dibuat orang saat ini, yaitu tim besar dan kebutuhan yang terus berubah. Meski begitu, ia tetap memakai manajemen sumber. Seperti disebutkan dalam tulisan aslinya, ia hanya berhenti mengkhawatirkan konflik merge dengan fork lain. Sekarang ada lebih dari 24 fork, dan detailnya ada di tautan di atas. Untuk penggunaan dasar seperti backup, “barusan saya mengubah apa?”, dan memasang software di perangkat baru, ia memakai version control. Hanya saja, khusus untuk program ini, ia tidak lagi menganggap version control sebagai sarana untuk memahami dan melacak apa yang berubah. Detailnya ada di https://akkartik.name/post/wart-layers. Misalnya, ia jadi kurang peduli pada kebersihan pesan commit. Version control tetap ada, tetapi dalam konteks sempit seperti ini—membuat artefak tahan lama yang kumpulan fiturnya tetap dan akan bertahan puluhan tahun—prioritasnya sebagai “praktik pemrograman yang baik” menjadi lebih rendah
    • Sepertinya penulis tidak berada dalam situasi harus mendukung pengguna profesional atau pengguna berbayar, dan tampaknya lebih menginginkan kebebasan bereksperimen daripada menjamin versi stabil yang diketahui
      Ia juga tampaknya tidak sedang menangani sistem besar atau pekerjaan tim yang krusial. Dalam kondisi seperti ini, alat-alat tersebut mungkin tidak memberi nilai besar. Pemain flute dalam orkestra besar yang memainkan simfoni kompleks membutuhkan partitur dan dirigen, tetapi jika bermain sendiri mengikuti drum machine atau memainkan free jazz, partitur tidak terlalu dibutuhkan dan malah bisa mengganggu
    • Penulis tampaknya mengalami kelelahan mental atau burnout terhadap pemrograman. Kalau version control terasa sampai sebegitu mengganggu, menurut saya itu tanda yang cukup baik bahwa ia perlu beristirahat
    • Programmer terus-menerus dibanjiri pilihan dan opsi. Alat dan zeitgeist yang menyebut “alat terbaik” umumnya bergerak ke arah membuat suatu pekerjaan menjadi lebih mudah
      Namun jika selalu ada 1000 pilihan mudah, memilih pilihan yang benar menimbulkan beban kognitif yang besar. Itu juga salah satu alasan mengapa industri menyakralkan berbagai best practice dan memberi tekanan sosial pada orang yang tidak mengikutinya. Arsitektur buruk dan kode spaghetti yang mengerikan memang sangat sulit dikerjakan, tetapi dengan mempertanyakan hal-hal yang tampak jelas benar dan menjelajahi lingkungan pengembangan yang ketat yang mengurangi pilihan serta alat, kita bisa lebih fokus pada masalah akhir. Version control pun mendorong branch memecah program menjadi “fitur independen”, riwayat membuat kita memakai unit fitur yang mungkin sudah usang secara membabi buta, dan kolaborasi biasanya membekukan batas organisasi yang tidak relevan ke dalam arsitektur kode. Ini juga bersinggungan dengan apa yang dikatakan Mel Conway. Manfaat version control memang akal sehat, tetapi pada level “menyelesaikan masalah bisnis X”, ada trade-off nyata. Fakta bahwa trade-off semacam ini hampir tidak terlihat di tingkat industri cukup bermakna
    • Dalam kasus ini, sepertinya yang dimaksud penulis adalah mengodekan logika versi di dalam aplikasinya sendiri. Misalnya endpoint API per versi untuk kompatibilitas ke belakang

  • Awalnya saya mengira penulis sepenuhnya keliru, tetapi tetap ada beberapa insight yang bagus
    Alur kerja ini sangat cocok bagi penulis. Sebagian besar dari kita juga bisa mengingat saat-saat frustrasi atau produktivitas menurun karena Git atau pengujian otomatis. Ada juga solusi yang lebih sederhana dan tidak mengganggu, seperti mencadangkan kode dengan Dropbox, FTP, dan sebagainya. Alasan pendekatan di atas cocok adalah karena penulis mengoptimalkan produktivitasnya sendiri pada proyek pribadi yang ia sayangi dan dikerjakan bersama sedikit orang. Pengujian otomatis berguna, tetapi penulis tampaknya suka membuat program yang cukup kecil sehingga nilainya sulit terlihat. Saya tetap melihat ada nilai pengujian otomatis bahkan dalam konteks ini, tetapi kita semua bisa sepakat bahwa pengujian otomatis memperlambat laju. Tentu banyak orang akan berargumen bahwa imbalannya datang nanti. Version control dan pengujian otomatis memang menyelesaikan masalah nyata. Memulai proyek tanpa version control saat ini tidak masuk akal, dan ada alasan mengapa pengujian otomatis menjadi best practice. Namun untuk use case khusus penulis, ini terdengar masuk akal. Kalau bagian kontroversial soal version control/pengujian disingkirkan, butir 7/8/9 menangkap dengan sempurna cara berpikir saya saat menulis dan me-refactor program besar. Tulis, buang, tulis lagi

    • Saya tidak setuju soal version control. Bahkan untuk proyek solo dan meski tidak ada beberapa branch versi
      Manusia membuat kesalahan, dan pada proyek berisi lebih dari 100 ribu baris, mengetahui apa yang diubah selama 3 minggu terakhir sangat membantu. Itu berguna untuk menemukan dan memperbaiki masalah. Fitur yang lebih baik adalah branch, yang memungkinkan kita mencoba apa pun yang diinginkan sambil tetap punya cara kembali ke kondisi stabil sebelumnya. Menurut saya pengujian otomatis boleh saja tidak ada
    • Bahkan untuk proyek solo, waktu yang dipakai untuk mempelajari Git secukupnya agar bisa menyiapkan .gitignore lalu menjalankan git init, git add -A, git commit -a -m "before I changed the foo function to use bar" dan kembali ke revisi sebelumnya sangatlah sepadan
      Tidak perlu menguasai Git, tetapi sekadar memiliki pesan commit dan versi tempat kembali saja sudah menyelamatkan saya berkali-kali. Belum lagi fitur yang lebih maju

  • Ini tulisan yang cukup membingungkan. Saya benar-benar penasaran apa yang membuatnya naik sampai peringkat 1

    • Di satu sisi, ini bisa saja tulisan seorang developer yang bereksperimen dengan alat dan teknik lain untuk memperbaiki hidupnya. Di sisi lain, ini juga bisa saja umpan untuk menyeret orang ke dalam perdebatan

  • Motivasi utama untuk memiliki rangkaian pengujian yang masuk akal adalah mengurangi frustrasi. Rangkaian pengujian memberi pengembang keyakinan untuk mengevolusikan sistem
    Jika dibuat dengan benar, sering muncul juga pikiran seperti “sulit menemukan cara untuk menguji sisanya, dan toh semuanya berjalan cukup baik.” Seiring kompleksitas fitur meningkat, menguji komponen atau keseluruhan sistem bisa menjadi sangat sulit untuk ditangani. Namun filosofi bahwa program menjadi lebih baik dengan meninggalkan pengujian dan version control tidak dapat diskalakan melampaui satu orang. Itu pun hanya mungkin jika orang tersebut mengetahui semua keputusan saat ini dan masa lalu yang tertanam dalam source code sebagai ingatan dekat yang masih segar. Selain itu, jika Anda memahami implementasinya secara mendalam, semua verifikasi perubahan secara definisi harus dilakukan secara manual

    • Dulu di HN, saya pernah melihat kisah tentang seseorang yang tidak pernah me-merge kode kecuali kode yang ia tulis sendiri pada hari itu
      Isinya kira-kira, jika di akhir hari belum berada dalam keadaan yang bisa di-merge, berarti ia belum cukup memahami masalahnya untuk mengekspresikannya dalam satu hari, jadi keesokan paginya ia mencoba lagi dari awal. Saya tidak tahu apakah ada yang mengingat ini, atau saya sedang tertukar dengan situs atau anekdot lain
    • Sebagai tim pemrograman satu orang, itu masuk akal. Sejujurnya, bahkan saat bekerja sendiri, membayangkan memprogram tanpa rangkaian pengujian atau version control saja sudah menakutkan
      Dokumentasi, pengujian, dan version control mengurangi jumlah konteks kode yang harus saya ingat. Saya memang perlu mengingat detail kode yang ada di depan mata, tetapi jika saya mendokumentasikannya, mengujinya, dan melakukan check-in tentang mengapa/bagaimana saya mengubahnya dengan pesan commit yang baik, saya bisa mengosongkan kode itu dari kepala saya dan beralih ke pekerjaan berikutnya

  • Contoh bagus untuk poin nomor 3, bahwa “perubahan kecil pada konteks seperti orang/tempat/fitur yang ingin didukung dapat secara drastis mengubah seberapa cocok sebuah program dengan konteks itu,” adalah K9 Mail. Sekarang aplikasi itu sedang menjadi Thunderbird versi Android
    K9 Mail dimulai dengan UI yang tidak tradisional, yang menampilkan daftar akun email di home screen serta jumlah pesan belum dibaca dan jumlah total pesan untuk setiap akun. Ada unified inbox, tetapi tidak dipaksakan kepada pengguna. Saya ingat secara eksplisit memilih aplikasi ini karena ingin memisahkan satu akun pribadi, satu akun kerja, dan beberapa akun kerja yang diberikan pelanggan. Mungkin banyak pengguna K9 juga memilih aplikasi ini karena alasan yang sama. Itu pula sebabnya ada banyak keluhan ketika pengembang beralih ke UI Android tradisional, dengan daftar akun yang meluncur dari kiri dan perlu satu tap tambahan untuk berpindah akun. Jika kami menyukai UI seperti itu, kemungkinan besar sejak awal kami tidak akan memilih K9. Jadi satu perubahan kecil, meski mungkin melibatkan banyak coding, merusak kecocokan aplikasi yang sebelumnya pas bagi penggunanya. Saya tetap memakai 5.600, versi terakhir dengan UI lama, dan melakukan sideload setiap kali membeli perangkat baru. Yang lebih tidak biasa lagi, saya hanya memakai POP3 untuk akses akun. Alurnya adalah melihat pratinjau di ponsel, menghapus yang perlu dihapus, membalas dengan BCC ke diri sendiri jika perlu, lalu pada akhirnya mengunduhnya di laptop; K9 sangat cocok untuk workflow ini. Saya tidak butuh yang mewah; aplikasi ala tahun 90-an sudah cukup

  • Saya juga terus penasaran ke mana jalan ini akan mengarah. Satu hal yang jelas: membuat software sendirian adalah aktivitas yang sepenuhnya berbeda dari membuatnya dalam tim
    Mengenai pengujian, pengujian adalah sarana, bukan tujuan. Menurut saya yang kita cari adalah keyakinan. Jika kita yakin pada implementasi, kita melakukan lebih sedikit pengujian. Sebaliknya, jika ada sesuatu yang harus terus berjalan, kita menambahkan beberapa integration test di batas luar yang tidak terlalu terpengaruh refactoring sehingga tidak terlalu memperlambat laju. Semacam menusuk web backend dari luar, alih-alih menguji bagian dalamnya. Unit test bagus untuk mengonkretkan desain API baru, tetapi setelah arahnya diketahui, test-test itu hampir tidak berguna lagi

    • Ada sangat banyak alasan bagus untuk tetap menaruh test bahkan di proyek satu orang
      Mengunci sementara if statement dengan sesuatu seperti true || agar langsung menuju fitur yang sedang dibuat itu memakan waktu dan nantinya harus dihapus. Lebih baik buat dan jalankan test saja, lalu bisa ditinggalkan sebagai regression test. Jika Anda men-deploy aplikasi besar atau lambat—kadang sekadar memakai Qt saja sudah membuat build atau eksekusi lama—maka satu test biasanya memuat lebih cepat dan berjalan lebih cepat. Jika mereproduksi bug butuh 45 detik, lebih baik pakai test. Anda bisa mengotomatiskan bagian pekerjaan yang paling membosankan, mempertahankan flow, memeriksa kondisi bug sesering yang Anda mau tanpa harus setiap kali memikirkan apakah layak diperiksa, dan lagi-lagi meninggalkannya sebagai regression test

  • Saya sangat menyukai penulis ini, dan Mu adalah salah satu proyek favorit saya. Proyek yang menarik, semacam mesin Lisp modern, dan berjalan di QEMU

  • Saya suka kalimat “sebagian besar software sudah terinfeksi secara tak tersembuhkan oleh insentif untuk melayani banyak orang dalam jangka pendek.” Bahkan jika software diganti menjadi “bisnis”, kalimat itu tetap berlaku

  • Kita semua sampai taraf tertentu kewalahan oleh kompleksitas di bidang rekayasa perangkat lunak. Terkadang kompleksitas itu memang bersifat aksidental
    Namun saya tidak setuju bahwa solusinya adalah menolak semua ide yang telah dibuat selama puluhan tahun. Sebaliknya, kita juga tidak boleh menerima semua solusi secara harfiah atau menggunakannya “terlalu banyak”. Kewalahan, menurut definisinya, muncul ketika kita menggunakan sesuatu terlalu banyak. Tulislah pengujian, gunakan sistem kontrol versi, gunakan abstraksi, tetapi harus tahu mengapa menggunakannya. Jika “mengapa” itu tidak lagi berlaku, harus dievaluasi ulang

    • Menurut saya salah satu sumber besar masalahnya adalah akademia. Saya menjadi penguji eksternal untuk mahasiswa CS di Denmark, dan mereka masih belajar cara menumpuk abstraksi di awal dengan pendekatan berorientasi objek dan arsitektur onion
      Ini adalah salah satu mantra yang hampir paling buruk dalam pengembangan perangkat lunak. Yang lebih buruk, hal-hal seperti ini diajarkan nyaris seperti agama. Yang aneh adalah, selama beberapa tahun terakhir, cara para profesional menulis perangkat lunak sudah banyak berkembang. Seperti yang saya katakan, abstraksi tidak secara inheren buruk untuk segala hal. Sulit juga membayangkan data tipikal yang masuk ke basis data SQL tidak memiliki kelas dasar yang memuat field seperti updated, updated_by. Namun secara umum saya hampir tidak menggunakan abstraksi kecuali benar-benar dipaksa. Tetapi di akademia mereka masih mengajarkan kurikulum yang persis sama dengan yang saya pelajari 25 tahun lalu. Rasanya aneh ketika menilai kemampuan mahasiswa membuat abstraksi raksasa dengan UML yang keren lalu mengimplementasikannya ke kode. Padahal 90% dari mereka mungkin tidak akan pernah melihat satu diagram UML pun lagi. Setidaknya begitu di ranah kecil tempat saya berada. Meski begitu, kenyataan tetap kenyataan
    • Satu-satunya alasan saya benar-benar mulai memakai Git adalah magit
      Saya berharap ada “porcelain” tingkat command line untuk semuanya. Jika ada output standar --help=ui dan antarmuka bergaya dialog, sepertinya itu bisa diotomatisasi. Ini bukan semata soal kewalahan oleh kompleksitas, melainkan lebih dekat ke masalah bahwa jumlah memori otot aktif yang bisa dimanfaatkan itu terbatas, dan pada titik tertentu kita harus memangkasnya