Coding sebagai semacam tulisan

May 10 2023

Apa yang dapat dipelajari pengembang perangkat lunak dari penulis prosa

Ada tempat di mana Sungai Ular di Wyoming membelok ke utara, melebar, dan melambat. Moose menelusuri bunga lili air, pelikan menangkap ikan, berang-berang bermain.

Ada tempat di mana Sungai Ular di Wyoming membelok ke utara, melebar, dan melambat. Moose menelusuri bunga lili air, pelikan menangkap ikan, berang-berang bermain. Kemudian sungai itu menggulung kembali dengan sendirinya dan melanjutkan perjalanannya ke arah barat menuju pegunungan.

Anda akan melihat jalur perulangan yang sama jika Anda melihat karier saya sejauh ini. Saya seorang pengembang perangkat lunak berubah menjadi guru humaniora yang kembali menjadi pengembang perangkat lunak. Antara teknik dan humaniora ada jarak yang terkenal, tapi saya sudah cukup menempuhnya sehingga saya tahu itu lebih pendek dari yang dipikirkan orang. Sepanjang jalan, saya telah memperhatikan bahwa beberapa saran yang diberikan oleh penulis prosa juga dapat bermanfaat bagi penulis perangkat lunak—hampir seolah-olah menulis kode adalah bentuk tulisan.¹

Suatu kali, saya perlu membuat sedikit fungsi yang menambahkan item ke array, tetapi menghapus item tersebut jika sudah ada. Seperti ini:

toggle([], 1) // should return [1]
toggle([1], 1) // should return []

import _ from "lodash";
const toggle = (arr, item) => _.xor(arr, [item]);

Namun, tak lama kemudian, saya ingat beberapa kata nasihat: "Baca kembali komposisi Anda, dan setiap kali Anda menemukan bagian yang menurut Anda sangat bagus, coretlah." Itu tip dari Samuel Johnson, penulis esai abad ke-18.³ Kesemutan kepintaran, saya sadari, adalah petunjuk bahwa saya harus menyederhanakan fungsi saya. Saya mengubahnya menjadi:

const toggle = (arr, item) =>
   arr.includes(item) ?
   arr.filter((x) => item !== x) :
   [...arr, item];

Menurut pendapat saya: tidak.⁴ Meskipun lebih kompleks dalam beberapa hal, fungsi baru ini masih cenderung lebih jelas untuk pembuat kode rata-rata, dan karena itu lebih mudah dipelihara. Sebaris kode dapat secara sintaksis sederhana namun tidak jelas, atau jelas namun kompleks secara sintaksis. Persis seperti sebaris prosa. Pikirkan kalimat, “Untuk apa Anda membawa buku itu sehingga saya tidak ingin membacakannya?”⁵ Ini memiliki sintaksis yang berbelit-belit, tetapi jauh lebih dapat dipahami daripada, katakanlah, kalimat sederhana secara sintaksis, “ Myrmecobius absquatated.” Meski tidak lagi singkat, fungsi baru saya lebih mudah dibaca.

Jika dia tahu JavaScript, raja prosa singkat itu sendiri mungkin tidak akan menyukai versi yang lebih ringkas dari toggle. “Hemingway”—raja yang dimaksud—“tidak mengarahkan Anda ke kamus,” kata F. Scott Fitzgerald dengan penuh penghargaan.⁶ Jika digunakan xor, fungsi saya akan mengarahkan sebagian besar pembaca ke dokumentasi. Tanpa itu, fungsinya lebih terurai, eksplisit, dan karena alasan itu, lebih jelas.⁷

Istilah laconic berasal dari Spartan kuno, yang tinggal di daerah bernama Laconia dan tidak membuang kata-kata. Musuh pernah menulis kepada mereka, "Jika saya menyerang Laconia, saya akan mengusir Anda dari tanah." Mereka membalas: “Jika.”⁸

Satu prinsip tentang menulis yang saya kagumi tidak datang dari seorang novelis atau jurnalis melainkan seorang desainer museum. Tulisan yang bagus, menurut Edwin Schlossberg, ”menciptakan konteks yang dapat digunakan orang lain untuk berpikir”.⁹ Itu membantu mereka membayangkan, merenungkan, menanggapi. Ini memberi mereka ruang untuk melakukannya — seperti pameran museum. Dengan cara yang sama, kode yang baik seolah-olah memberi ruang bagi pembaca. Ini membantu mereka bernalar.

Maka, biasanya masuk akal bagi penulis kode untuk mengikuti pola yang sudah dipahami dengan baik oleh pembaca rata-rata. Meskipun sebagian besar pengembang JavaScript akrab dengan ternary (tanda tanya dan titik dua) yang digunakan di atas, banyak yang bahkan lebih nyaman dengan blok if-else, seperti ini:

const toggle = (arr, item) => {
   if (arr.includes(item)) {
      return arr.filter((x) => item !== x);
   } else {
      return [...arr, item];
   }
}

Penulis harus memiliki empati untuk pembacanya, dan Anda juga harus, untuk orang-orang yang akan memelihara, men-debug, atau mengadaptasi kode Anda. Namun, karena Anda adalah penulisnya, wajar jika Anda mengalami kesulitan masuk ke posisi pembaca Anda. Cobalah dua teknik yang dipinjam dari penulis terbaik.

Pertama, Helen Sword menyarankan agar Anda "memvisualisasikan orang-orang tertentu melihat dari balik bahu Anda saat Anda menulis." Lagi pula, "penulis yang paling menarik hampir selalu adalah mereka yang memberikan perhatian paling dekat kepada orang-orang nyata - spesialis dan nonspesialis, kolega dan orang asing - yang di telinga mereka kata-kata mereka akan bergema."¹¹ Nasihat yang bijak juga untuk pembuat kode.

Teknik kedua: sisihkan kode Anda selama satu atau dua hari, jika bisa, lalu kembalikan. “Selesaikan cerpennya, cetak, lalu taruh di laci dan tulis hal-hal lain,” Neil Gaiman pernah memberi tahu seorang calon penulis. “Saat Anda siap, ambil dan bacalah, seolah-olah Anda belum pernah membacanya sebelumnya. Jika ada hal-hal yang membuat Anda tidak puas sebagai pembaca, masuklah dan perbaiki sebagai penulis: itulah revisi.”¹² Penulis kuno Quintilian juga menyarankan agar kita “mengesampingkan apa yang telah kita tulis untuk waktu tertentu”—

sehingga ketika kita kembali ke sana setelah selang waktu, itu akan memiliki suasana kebaruan dan menjadi hasil karya orang lain; karena dengan demikian kita dapat mencegah diri kita dari menganggap tulisan kita dengan semua kasih sayang yang kita curahkan pada seorang anak yang baru lahir. ¹³

Tidak terlalu mengejutkan bahwa panduan penulis dapat diadaptasi untuk simbol-simbol dari jenis yang berbeda. Bidang pengetahuan sering menyusup satu sama lain, atau seperti yang dikatakan dengan indah oleh novelis Charles Johnson:

Satu bentuk ekspresi artistik dan intelektual memelihara dan memberi makan yang lain. Apa pun yang kita sebut kreativitas dan imajinasi—dua misteri besar itu—bagi beberapa pencipta dapat dialami sebagai “global” dalam hidup mereka, tidak terlokalisir dalam satu bentuk ekspresi melainkan menyebar atau tumpah dari satu genre ke genre lain, satu artistik atau disiplin intelektual yang lain, karena semua humaniora (bersama dengan ilmu) saling terkait, saling berhubungan. ¹⁴

Bereksperimen dalam pengkodean Anda sendiri dengan pendekatan yang direkomendasikan di sini mungkin memerlukan perubahan dalam rutinitas Anda. Jalan memutar, sehingga Anda bisa, seperti sungai, melambat dan menjadi lebih reflektif, lebih murah hati. Jadi ambil satu halaman dari sungai. Itu tidak mengikuti jalur linier.

Analogi penulisan kode memiliki keterbatasan, tentu saja. Misalnya, kontradiksi semuanya dilarang dalam kode sumber, dan dalam seni, khususnya puisi, mereka mendapatkan keadilannya. Ada sebuah puisi karya Fernando Pessoa yang saya suka baca keras-keras meskipun saya tidak mengerti bahasa Portugis. Ini berawal:

Poita é um fingidor
Finge tão complete
Que chega a finger que é dor
A dor que deveras sente.

Seorang penyair adalah orang yang berpura-pura.
Dia benar-benar memalsukan yang asli
Dia bahkan memalsukan rasa sakit
dan penderitaan yang mengerikan yang dia rasakan.¹⁵

Pessoa mengundang kita untuk sejenak mengesampingkan gagasan konvensional tentang benar dan salah. Dia dengan tidak menyesal menyatakan sebuah kontradiksi: penyair menyembunyikan diri di balik puisi mereka, dan dengan melakukan itu, mereka menjadi terlihat melalui puisi itu. Meninggalkan logika Boolean, Pessoa menciptakan logikanya sendiri. “Penyair adalah orang yang berpura-pura”: apa artinya, jika bukan, “Saya mengarang semua yang saya katakan—semuanya salah, termasuk kata-kata ini”? Ini adalah pernyataan yang menyangkal diri, kebohongan logis. Tetapi jika Anda melihat kata-kata ke akar etimologisnya, "O Poeta é um fingidor" berarti "Pembuat adalah pembuat". Kebenaran yang logis. Seperti simulasi rasa sakit yang dia sebutkan, pernyataan penyair itu salah di permukaan, benar di bawahnya. Kode dan puisi menawarkan strategi pelengkap untuk mengatasi dunia yang seringkali tidak logis: seseorang memberikan perlindungan dari kontradiksi,

Catatan kaki

[1]: Analogi penulisan kode telah dibuat sebelumnya, meskipun berbeda, antara lain oleh Brian Kernighan dan PJ Plauger , Donald Knuth , Richard Gabriel , James Devlin , Jeff Atwood , dan Rebecca Sutton Koeser . Steve McConnell mengkritik analogi tersebut.

[2]: Inilah contoh fungsi lodashperpustakaan xordalam aksi. Di Boggle Anda mencari kata-kata dalam kotak huruf. Jika Anda menemukan kata yang tidak ditemukan orang lain, Anda mendapat poin untuk itu. Misalkan Anda membuat versi game dalam JavaScript. Anda memiliki data ini:

const wordsFoundByPlayerOne = ["apple", "peel"];
const wordsFoundByPlayerTwo = ["apple", "leap"];
const wordsFoundByPlayerThree = ["apple", "able"];

_.xor(
   wordsFoundByPlayerOne,
   wordsFoundByPlayerTwo,
   wordsFoundByPlayerThree
); // Output: ["peel", "leap", "able"]

[4]: Kami juga dapat membuat alternatif yang sangat mudah dibaca dengan bantuan Set:

const toggle = (arr, item) => {
  const set = new Set(arr);
  if (set.has(item)) set.delete(item);
  else set.add(item);
  return Array.from(set);
}

[6]: Dikutip oleh pelatih penulis Gary Gilson dalam artikel 2019 .

[7]: Sebaliknya, blogger Jeff Atwood telah mempromosikan " pemrograman Spartan ".

[8]: Plutarch, Tentang Banyak Bicara .

[9]: Dikutip oleh fisikawan Konstantin Likharev dalam buku tahun 2021 .

[10]: Dalam ceramahnya tahun 2012 “Simplicity Matters,” Rich Hickey berpendapat bahwa programmer tidak perlu takut akan kesulitan , sebagian karena itu membuat pekerjaan kita menarik. Tetapi pekerjaan kita akan sangat menarik jika berada di zona Goldilocks antara membosankan dan melelahkan—seperti halnya pelajaran sekolah .

[11]: Helen Sword, Stylish Academic Writing (2012), hal. 44. Untuk meningkatkan kejelasannya, banyak penulis membaca karya mereka dengan lantang, mendengarkan diri mereka sendiri. Filsuf Jonathan Bennett menulis : “Gilbert Ryle pernah mengatakan kepada saya, 'Apa yang tidak terbaca dengan baik di telinga tidak terbaca dengan baik di mata', dan itu mengubah hidup saya. Lebih dari satu hal lainnya, wawasan itu menunjukkan kepada saya bagaimana mulai keluar dari lubang sampah ke dataran prosa yang layak. Kernighan dan Plauger menawarkan wawasan serupa tentang pemrograman: “Cara yang berguna untuk memutuskan apakah beberapa bagian kode jelas atau tidak adalah 'tes telepon'. Jika seseorang dapat memahami kode Anda saat dibacakan melalui telepon, itu sudah cukup jelas. Jika tidak, maka perlu ditulis ulang” ( Elements of Programming Style , hal. 21).