Jika Tidak Akan Melakukan Apa Pun, Setidaknya Lakukan Tidak Ada dengan Benar

Saat API tidak melakukan apa pun, lakukan tidak ada dengan benar

• Ketika API seharusnya tidak melakukan apa pun, penting untuk memastikan bahwa ia tidak melakukan apa pun dengan cara yang benar.
• Sebagai contoh, Windows memiliki infrastruktur pencetakan yang sangat besar, tetapi Xbox tidak memiliki infrastruktur semacam itu.
• Saat aplikasi mencoba mencetak di Xbox, melempar NotSupportedException adalah cara yang keliru.
• Karena aplikasi terutama diuji di PC, saat dijalankan di Xbox penanganan pengecualian mungkin tidak ada dan aplikasi bisa crash.
• Desain yang lebih baik untuk "mendukung" fitur pencetakan di Xbox adalah membuat fungsi pencetakan berhasil tetapi melaporkan bahwa tidak ada printer yang terpasang.
• Ketika pengguna mencoba mencetak, sistem meminta pemilihan printer, tetapi daftarnya kosong sehingga pengguna menyadari, "oh, tidak ada printer," lalu membatalkan permintaan cetak.
• Untuk aplikasi yang mencoba memasang printer, fungsi pemasangan printer dapat segera mengembalikan kode hasil "pengguna membatalkan tindakan".
• Tujuannya adalah bertindak seolah fitur pencetakan didukung sepenuhnya, padahal sebenarnya hanya berperilaku seolah tidak ada printer.
• Pada sistem yang pencetakannya benar-benar tidak berfungsi, dapat ditambahkan fungsi untuk memeriksa apakah pencetakan tersedia agar tombol cetak bisa disembunyikan dari UI.
• Perilaku ini disebut "inert".
• Permukaan API tetap ada dan masih berfungsi sesuai spesifikasi, tetapi pada praktiknya tidak melakukan apa pun.
• Yang penting adalah tidak melakukan apa pun secara konsisten sesuai cara yang didokumentasikan, sehingga masalah dengan kode yang sudah ada dapat diminimalkan.

Contoh penonaktifan API

• Ada contoh penonaktifan API yang mencakup berbagai fungsi untuk membuat handle widget, fungsi yang menerima handle widget, dan fungsi untuk menutup handle widget.
• Tim awalnya mengusulkan untuk menonaktifkan API dengan membuat CreateWidget berhasil tetapi mengembalikan pointer null.
• Namun, pendekatan ini bisa membingungkan aplikasi. "Pemanggilan berhasil, tetapi saya tidak menerima handle yang valid?"
• EnableWidget yang mengembalikan "handle tidak valid" juga dapat menimbulkan kebingungan.
• Dari dokumentasi yang ada, ditemukan nilai balikan ERROR_CANCELLED yang berarti pembuatan widget dibatalkan oleh pengguna.
• Karena itu, setiap kali aplikasi mencoba membuat widget, sistem dapat mengatakan, "tidak, pengguna membatalkannya".

Pendapat GN⁺

• Hal terpenting dari tulisan ini adalah bahwa ketika API tidak melakukan apa pun, ia harus tidak melakukan apa pun dengan cara yang tidak merusak pengalaman pengguna dan tetap menjaga kompatibilitas dengan kode yang sudah ada.
• Pendekatan ini menekankan pentingnya desain API kepada para pengembang dan membantu menghadirkan pengalaman perangkat lunak yang ramah pengguna.
• Tulisan ini menunjukkan sisi teliti dari rekayasa perangkat lunak dan memberikan contoh menarik tentang bagaimana aplikasi dapat gagal dengan anggun bahkan di lingkungan yang tidak terduga.

[GN⁺]

Opini Hacker News

• Pendapat tentang "menelan error":

  • Menyembunyikan error adalah praktik yang buruk.
  • Ini mempersulit penemuan bug dan pengujian dengan menutupi cacat perangkat lunak tanpa menyelesaikan masalahnya.
  • panic di bahasa Go adalah cara yang baik untuk dengan jelas menandai kesalahan programmer saat pengujian.
  • Jika aktor dalam sistem berusaha menyembunyikan cacatnya sendiri, akan jauh lebih sulit untuk mengidentifikasi dan menyelesaikan masalah.

• Pendapat tentang kompatibilitas mundur:

  • Kompatibilitas mundur selalu merupakan pekerjaan yang berantakan, dan pilihannya adalah melakukannya secara tidak sempurna atau tidak melakukannya sama sekali.
  • Inilah alasan mengapa ketika Anda mengklik file Word '97 atau game untuk MS-DOS, file tersebut masih terbuka seperti yang diharapkan di komputer masa kini.

• Keluhan tentang desain UI:

  • UI yang menyarankan adanya perangkat yang mungkin saja tidak ada sangatlah menjengkelkan.
  • Ini membuat orang membuang waktu untuk menemukan perangkat yang sebenarnya tidak didukung.

• Kritik terhadap kurangnya pembelajaran Microsoft:

  • Bahkan setelah 30 tahun, Microsoft masih terus mengulangi kesalahan yang sama.
  • Menampilkan daftar kosong saat aplikasi mencoba mencari printer adalah pengulangan dari masalah lama.

• Pendapat tentang Xbox yang tidak mendukung pencetakan:

  • Xbox tidak mendukung pencetakan karena Microsoft mendefinisikannya seperti itu.
  • Dari sisi hardware, kemampuannya untuk mencetak sama dengan perangkat Windows lainnya.
  • "Solusi" seperti ini adalah masalah yang timbul dari keputusan Microsoft yang tidak rasional.

• Saran tentang penggunaan API:

  • Memang benar bahwa komponen seharusnya mengalami masalah lebih dulu daripada pengguna, tetapi saya tidak setuju dengan cara penulis mengungkapkannya.
  • Tidak ada yang salah jika fungsi pencetakan melempar NotSupported­Exception.
  • Yang dijelaskan penulis adalah hack untuk mendukung klien yang buruk.

• Perasaan tentang "kepatuhan yang berniat jahat":

  • Saya suka sekaligus tidak suka dengan cara ini dalam menangani masalah.
  • Namun, jika tujuannya adalah memungkinkan lebih banyak pengguna menjalankan lebih banyak perangkat lunak di platform tersebut, cara ini bagus.

• Pendapat positif tentang keamanan:

  • Mengabaikan pemanggilan API dengan benar mencegah program melakukan tindakan yang lebih berbahaya.

• Kilas balik tentang strategi browser:

  • Strategi untuk tetap berusaha menampilkan halaman sebaik mungkin meskipun ada error di kode HTML pernah dianggap sebagai strategi yang baik.
  • Pengguna tidak menginginkan error, dan seharusnya kita sudah belajar dari pengalaman itu.

• Hal yang disalahpahami para pengkritik tentang penanganan exception:

  • Ada poin yang dilewatkan para pengkritik dalam situasi ketika exception memang tidak perlu dilempar.
  • Jika perangkat (printer) tidak terhubung, aplikasi harus menangani situasi itu dengan rapi dan tidak boleh crash.

[GN⁺]

Pendapat di Lobste.rs

• Yang dimaksud di sini adalah fungsi-fungsi pencetakan bertindak secara konsisten seolah-olah pencetakan didukung sepenuhnya, tetapi anehnya tidak akan pernah ada printer sungguhan untuk mencetak, dan itu menjelaskan banyak hal
  Terlepas dari leluconnya, saya tidak setuju dengan pemrograman yang terlalu defensif dan pengalaman pengguna seperti ini. Akibatnya, perangkat lunak tidak menjalankan tugasnya tanpa alasan yang jelas, dan tidak ada cara untuk mengetahui mengapa. Aplikasi seharusnya menangkap error dan, jika memungkinkan, membuat pesan yang ramah pengguna, atau setidaknya menampilkan pesan error aslinya kepada pengguna. Jika ini pekerjaan latar belakang, harus ada log error
  Saya mengakui bahwa tulisan ini ditulis dari sudut pandang pengembang API, bukan pengembang aplikasi. Jadi error API harus didokumentasikan, dan harus menyediakan pesan error yang bisa ditindaklanjuti oleh pihak pemanggil
  Saya juga tidak suka ketika tombol disembunyikan di UI hanya karena tidak ada hak akses. Jika ruang memungkinkan, menurut saya lebih baik tombolnya tetap ditampilkan namun dinonaktifkan, lalu ketika pengguna mengarahkan mouse ke sana, tampilkan pesan yang menjelaskan bagaimana cara mengaktifkannya
  • Perlu diingat juga bahwa tulisan ini bukan dari sudut pandang pengembang API biasa, melainkan pengembang Windows API. Sudah lama posisi Microsoft adalah bahwa Windows API tidak boleh merusak kompatibilitas meskipun versinya berubah
  • Ini adalah pembahasan klasik tentang Hukum Postel / prinsip ketangguhan. Sekarang semua orang tahu bahwa prinsip ketangguhan sudah usang, dan telah melahirkan monster seperti HTML atau protokol besar serta format file yang sulit sekali diparse dengan benar
    Secara umum, lebih baik menuntut ketepatan. Namun jika pengguna yang sudah ada berjumlah 1 miliar, sangat bijak untuk sebisa mungkin tidak merusaknya, dan dari sudut pandang pengguna hal itu memang menciptakan nilai nyata di tingkat sistem karena semuanya tetap berjalan. Pada akhirnya sikap yang tepat adalah fail fast, tapi jangan sampai membuat banyak hal ikut gagal
  • Dalam kasus ini, salah satu API lama kemungkinan tidak memiliki error yang terdokumentasi, sehingga besar kemungkinan sejak awal tidak ada penanganan error. Jika Anda tidak ingin merusak seluruh perangkat lunak lama, Anda harus melakukan kebohongan putih demi kebaikan
    Ini lebih dekat ke stabilitas ABI daripada API. Di Windows, perangkat lunak yang dibangun 15 tahun lalu pun harus tetap berjalan di OS baru sebisa mungkin. Karena signature fungsi tidak bisa diubah, Anda harus melakukan kebohongan putih agar API yang sudah tidak lagi bermakna tetap bisa berjalan
    Misalnya, API masih berpura-pura bahwa Active Desktop itu ada. Alternatifnya adalah merusak banyak perangkat lunak lawas yang sudah telanjur ada
  • Saya benar-benar setuju. Ada sedikit hal yang lebih menjengkelkan daripada kebingungan mencari tombol yang tidak muncul di layar saya, padahal terlihat di layar orang yang sedang menjelaskan di sebelah saya atau di tutorial
    Jadinya kita tidak tahu apakah fitur itu memang sudah hilang, atau hanya tersembunyi di layar lain di tengah jalan
  • Memang benar aplikasi seharusnya menangkap error dan menampilkannya kepada pengguna.
    Tetapi kalau aplikasinya tidak melakukan itu, orang yang memakai aplikasi tersebut akan menyalahkan Windows. Mereka menyalahkan Windows, bukan aplikasinya, dan hal yang sama terjadi bahkan saat aplikasinya crash
    Itulah sebabnya Microsoft membuat jalan memutar seperti ini. Jauh lebih mudah membiarkan pekerjaan cetak menghilang begitu saja, sehingga pengguna akan berhenti sejenak lalu menerima, “oh benar, memang tidak ada printer”
• Jika fungsi instalasi printer bisa langsung mengembalikan hasil dengan kode hasil pengguna membatalkan operasi, dari sudut pandang dukungan aplikasi hal itu hampir pasti akan mengarah pada perilaku tak diinginkan yang jauh lebih sulit ditangani dibanding jika API pencetakan sejak awal melempar exception
• Akhir-akhir ini saya banyak memakai AI-assisted programming, dan saya melihat agen sering menambahkan pemeriksaan if untuk mengecek null. Setiap kali melihatnya, saya teringat tulisan ini
  Jadi saya menginstruksikan agen agar tidak mengulang-ulang pemeriksaan null, melainkan menggunakan fungsi yang aman dan memeriksa sekali saat deklarasi bahwa nilainya tidak akan pernah null