Apa yang Dimaksud dengan "Selera yang Baik" dalam Rekayasa Perangkat Lunak?

• Selera teknis adalah konsep yang berbeda dari kemampuan teknis; seseorang bisa sangat cakap tetapi memiliki selera yang buruk, dan sebaliknya, meski kemampuannya kurang, seleranya bisa baik
• Selera seorang insinyur perangkat lunak berarti kemampuan memilih nilai-nilai rekayasa yang sesuai untuk proyek
• Hal ini tampak dari rasa seperti kode mana yang terlihat bagus/buruk, keputusan desain mana yang terasa memuaskan, dan masalah mana yang membuat seseorang terobsesi; ini pada akhirnya mencerminkan kumpulan nilai rekayasa yang paling ia utamakan
• Semua keputusan dalam rekayasa perangkat lunak merupakan rangkaian trade-off; insinyur yang belum matang menganggap pendekatan tertentu sebagai kebenaran mutlak, sedangkan insinyur yang matang menyesuaikan nilai secara fleksibel sesuai konteks
• Selera yang baik adalah kemampuan memilih prioritas nilai-nilai yang cocok untuk proyek tertentu, sedangkan selera yang buruk tampak sebagai kekakuan yang terobsesi pada standar absolut seperti "best practice"
• Selera dibangun melalui beragam pengalaman proyek dan pola pikir terbuka, dan pada akhirnya ada atau tidaknya selera yang baik akan terlihat dari keberhasilan proyek

---

Perbedaan antara selera teknis dan kemampuan

• Selera teknis tidak selalu sejalan dengan kemampuan yang unggul
• Seperti halnya siapa pun dapat membedakan makanan yang enak dan tidak enak terlepas dari kemampuan memasaknya, dalam perangkat lunak selera terbentuk lebih dahulu daripada kemampuan
• Selera seorang insinyur tercermin dari apakah suatu kode "terlihat bagus" atau "terlihat kurang bagus"
• Merasa puas terhadap keputusan desain tertentu, dan lebih memperhatikan masalah tertentu, berfungsi sebagai bagian dari selera
• Kemampuan teknis dapat berkembang melalui pengulangan dan pembelajaran, tetapi selera berkembang dengan cara yang lebih samar dan intuitif

• Indikator selera rekayasa

  • Merasa bahwa "kode ini enak dilihat/tidak enak dilihat"
  • Rasa puas yang kuat atau sikap biasa saja terhadap sebagian keputusan desain
  • Masalah perangkat lunak yang terus terbayang bahkan setelah pulang kerja, dan masalah yang tidak
• Selera dapat dipahami sebagai kemampuan mengadopsi nilai rekayasa yang sesuai dengan proyek saat ini

Pembedaan antara kemampuan dan selera

• Muncul pertanyaan apakah "kode yang terlihat bagus" harus benar-benar merupakan kode yang lebih baik
  • Contoh: orang yang menyukai map/filter menekankan keterbacaan kode dan fungsi murni, sedangkan orang yang menekankan for loop bisa lebih mementingkan performa dan perluasan yang sederhana
  • Ini bukan soal benar atau salah, melainkan perbedaan nilai yang diprioritaskan
• Karena masing-masing punya kelebihan dan kekurangan bergantung pada bahasa dan konteks, suatu pilihan tidak selalu pasti lebih baik
• Nilai yang dianggap penting oleh tiap insinyur berbeda-beda, sehingga preferensinya pun berbeda

Apa itu selera rekayasa

• Hampir semua keputusan dalam rekayasa perangkat lunak adalah keseimbangan antara nilai-nilai yang saling bertentangan (trade-off)
• Insinyur yang belum berpengalaman terlalu keras kepala terhadap seleranya sendiri
• Insinyur yang matang memahami keuntungan dari berbagai sudut pandang dan mengutamakan pilihan yang sesuai dengan situasi saat ini
• Yang penting bukan apakah X(teknologi) atau Y(teknologi) lebih baik, melainkan apakah dalam proyek saat ini keunggulan X lebih dibutuhkan daripada Y

• Contoh nilai rekayasa

  • Resiliency: apakah sistem tetap bekerja dengan baik meski ada gangguan atau masalah jaringan
  • Speed: apakah performanya mendekati batas teoretis, atau ada banyak pekerjaan yang tidak perlu
  • Readability: apakah insinyur baru dapat cepat memahami dan beradaptasi, apakah fungsi-fungsinya singkat dan jelas
  • Correctness: apakah kondisi yang salah dapat termodelkan, apakah test, type, assert, dan sebagainya sudah memadai, bahkan apakah verifikasi formal diterapkan
  • Flexibility: apakah sistem mudah diperluas, apakah perubahan dapat diterapkan dengan sederhana
  • Portability: apakah bergantung pada lingkungan tertentu, apakah perubahan lingkungan deployment mudah dilakukan
  • Scalability: saat trafik meningkat 10x atau 100x, apakah sistem dapat diperluas atau autoscaling dimungkinkan, dan di mana bottleneck berada
  • Development speed: seberapa cepat sistem dapat dikembangkan, apakah sebagian besar insinyur dapat mengerjakannya
  • Selain itu ada pula berbagai nilai seperti elegance, modern-ness, pemanfaatan open source, biaya pemeliharaan, dan lain-lain
• Tidak semua insinyur memberi perhatian pada tiap nilai dalam tingkat yang sama
• Bahasa, framework, dan pola desain yang dipilih akan berbeda bergantung pada nilai mana yang paling tinggi ia hargai

Ciri-ciri selera yang buruk

• Selera yang buruk muncul ketika nilai yang disukai seseorang tidak cocok dengan proyek saat ini
• Masalahnya adalah kurangnya fleksibilitas untuk terus memaksakan kelebihan teknologi atau metodologi tertentu ke dalam proyeknya sendiri
• Klaim yang selalu mengusung "best practice" menunjukkan kurangnya penilaian yang disesuaikan dengan situasi
• Insinyur yang tidak fleksibel mungkin cocok untuk proyek tertentu, tetapi bisa menimbulkan masalah serius saat lingkungan atau pekerjaan berubah

Karakteristik selera yang baik

• Selera yang baik adalah kemampuan memilih nilai rekayasa yang tepat sesuai situasi masalah
• Berbeda dari kemampuan teknis semata, hal ini hanya benar-benar bisa diuji dalam konteks proyek nyata yang kompleks
• Jika proyek yang mengadopsi keputusan desain yang ia setujui berjalan dengan baik, itu bisa menjadi ukuran kecocokan seleranya
• Beragam pengalaman proyek dan keterbukaan terhadap nilai baru pada momen tertentu merupakan unsur pembelajaran yang penting
• Menjaga fleksibilitas dan menghindari prasangka tetap terhadap teknologi atau metode tertentu membantu membentuk selera yang baik

Penutup

• Selera yang baik sama pentingnya dengan kemampuan, dan dalam proses bertumbuh dapat dikembangkan melalui keberagaman dan fleksibilitas, serta refleksi diri
• Beberapa orang kadang menunjukkan selera yang luar biasa melampaui pengalamannya (misalnya talenta muda dalam pemrograman maupun bidang lain)

Diskusi tambahan

• Dalam komentar Hacker News, ada juga pendapat yang skeptis terhadap keberadaan "selera" itu sendiri
• Sebagian orang berpendapat bahwa setiap masalah hanya memiliki satu solusi yang benar, tetapi penulis membantah bahwa dalam kenyataan berbagai solusi dimungkinkan, dan pada akhirnya nilai pribadi serta kontekslah yang menentukan pilihan
• Pendapat lain juga menyoroti bahwa konteks pelanggan dan bisnis merupakan bagian dari selera

[shakespeares]

Sepertinya ini lebih merupakan kecenderungan buruk yang bisa menjadi racun bagi tim dan proyek, daripada sekadar dianggap sebagai selera yang buruk.

[GN⁺]

Komentar Hacker News

• Saya pernah mengalami bahwa insinyur yang belum matang cenderung terlalu terobsesi dengan selera mereka sendiri, dan ketidakmatangan seperti ini juga bisa ada pada insinyur berpengalaman. Dulu saat membantu kode tugas komputer teman-teman, saya sering terdorong untuk menulis ulang semuanya hanya karena saya tidak menyukainya. Tapi akhirnya saya sadar, kalau begitu akan memakan waktu terlalu lama dan teman-teman saya juga tidak akan memahami hasil akhirnya. Jadi saya membantu dengan hanya menambahkan sedikit perbaikan pada pendekatan mereka, dan mereka pun lebih puas. Pengalaman seperti ini membuat saya mengenal berbagai sudut pandang dan kode saya sendiri juga jadi berkembang. Saya malah merasa seharusnya berterima kasih kepada teman-teman saya. Sampai sekarang pun saya masih sulit melepaskan prasangka awal, tetapi saya berusaha sebisa mungkin untuk sungguh-sungguh memahami sudut pandang lawan bicara, dan kadang mengakui bahwa cara mereka justru lebih baik. Prinsip pada dasarnya cukup subjektif, jadi selalu bersandar pada prinsip saja berarti tidak benar-benar memikirkan situasi dengan serius, melainkan pendekatan yang malas

  • Bahkan jika insinyur junior melakukan sesuatu dengan tidak efisien, saya tidak pernah langsung bilang bahwa mereka memakai cara yang kurang optimal. Sebaliknya, saya selalu bertanya kenapa mereka melakukannya begitu. Setiap percakapan berakhir dengan salah satu dari kami belajar sesuatu. Entah saya jadi tahu cara baru atau alasan mereka, atau mereka belajar kenapa dalam jangka panjang metode itu tidak akan berhasil. Apa pun hasilnya, percakapan seperti ini tidak pernah berakhir secara konfrontatif

  • Saya rasa “selera yang baik” terbentuk dari pengalaman melihat API yang hebat dan kode yang bagus. Kode yang baik bisa langsung dikenali saat melihatnya, dan seiring waktu saya juga harus bisa menulis seperti itu. Tapi ketika baru masuk ke bidang ini, sulit untuk punya selera coding yang baik, dan punya pengalaman pun tidak otomatis berarti punya selera, jadi kita perlu terus berusaha mencari, mengenali, dan meniru selera yang baik

  • Solusi untuk lepas dari prasangka, bias, dan pola pikir kaku adalah pendidikan dan pengalaman yang beragam di luar sudut pandang masing-masing individu. Kita harus aktif berusaha memahami dunia dari sudut pandang orang lain agar bisa berkembang sebagai manusia maupun profesional dan memperluas perspektif. Sebagai insinyur yang tertarik pada banyak bidang, hanya dengan mengetahui bahwa ada solusi atau sudut pandang lain saja, cara saya memecahkan masalah sudah berubah sehingga saya bisa menemukan solusi yang lebih baik daripada pendekatan naluriah pertama saya

  • Itulah mengapa bagus untuk bereksperimen dengan berbagai bahasa pemrograman. Akan terus muncul momen “aha” saat mencoba bahasa baru yang selalu menantang cara pandang kita selama ini. Awalnya mungkin terasa canggung atau terlihat salah, tetapi sampai benar-benar memahami alasan dan caranya, kita perlu menerima bahwa memang begitulah adanya

  • Pendapat yang bagus. Pola pikir seperti ini adalah cara yang saya terapkan kepada anggota tim yang saya rekrut sendiri atau ajak bekerja. Jika tujuan atau hasil tercapai, proses dan detail saya tidak harus ditiru persis. Saya mengakui ada banyak cara yang berbeda

• Saya pikir “selera yang baik” dalam mode bukan soal tiap potong pakaian itu sendiri, melainkan kemampuan menggabungkan pakaian-pakaian yang secara intrinsik tampak tidak terlalu berarti menjadi kesan yang kuat dan harmonis. Saya berharap tulisan ini akan mengarah ke sana. Saya ingin lebih mengeksplorasi apakah hal yang diputuskan insinyur perangkat lunak berdasarkan selera itu benar-benar wilayah selera, bukan sekadar trade-off teknis. Sejujurnya, tulisan ini sendiri terasa seperti contoh selera yang kurang baik. Dari sisi isi, tiap bagiannya ditulis cukup rapi, tetapi gagal membentuk “tampilan” keseluruhan sehingga terasa tercerai-berai. Ini bukan serangan pada penulisnya; saya justru menganggap topiknya bagus, jadi saya ingin lebih menekankan masukan perbaikannya

  • Saya tidak setuju dengan pendapat bahwa satu potong pakaian tidak berarti apa-apa dengan sendirinya. Pakaian punya makna budaya, historis, dan simbolis bahkan sebelum dikombinasikan. Mode adalah wilayah yang lebih dari sekadar kombinasi. Selain itu, mode juga punya berbagai trade-off dalam produksi, pemakaian, dan pencocokan

  • Hal yang kamu tanyakan, yaitu “bagaimana kita mengenali keindahan dan keanggunan”, sudah menjadi tema para filsuf sejak zaman kuno, dan terlalu luas untuk disimpulkan dalam satu artikel. Christopher Alexander dari bidang arsitektur mengeksplorasi hal ini secara mendalam, dan pemikirannya juga sangat memengaruhi arsitektur perangkat lunak. Alexander berpendapat bahwa keindahan objektif itu ada. Layak melihat pidato utama OOPSLA-nya atau disertasi doktoral Roy Fielding. “Nilai” yang disebut dalam tulisan ini disusun lebih sistematis sebagai “atribut arsitektur” dalam disertasi Fielding

  • Menariknya, saya justru menganggap tulisan ini sebagai esai langka yang mendalam dan sistematis dalam membahas topiknya, sesuatu yang tidak mudah ditemukan

  • Saya ingin bertanya pada titik seperti apa seorang insinyur benar-benar dinilai dari “selera”-nya dalam suatu kombinasi, dan kapan itu bisa dibedakan dari sekadar trade-off teknis. Menurut saya banyak keputusan dianggap sebagai “trade-off teknis, tetapi tidak bisa dibuktikan secara mutlak, atau perbedaannya sangat kecil sehingga praktis tidak penting”. Artinya, kalau terlalu samar untuk diperdebatkan, ya dibiarkan saja sebagai selera

  • Kebanyakan developer umumnya kurang punya selera mode, sehingga secara keseluruhan juga kurang memahami apa itu selera yang baik. Dan kebanyakan hal di dunia teknologi sama sekali tidak terlihat keren bagi orang non-teknis. Bahasa pemrograman itu tidak keren. Di dunia developer, titik awalnya bahkan sudah dari “tidak keren” lalu turun lagi ke bawah. Sebagai contoh, Rust, C++, dan sejenisnya masuk kategori “tidak keren”, sedangkan bahasa fungsional yang asing atau Bash, Linux, dan sejenisnya masuk kategori “sangat tidak keren”

• Selera yang baik adalah menulis kode yang sangat sederhana namun kuat, sampai-sampai terlihat seperti sesuatu yang bisa ditulis siapa saja

  • Saya akan membagikan contoh lain. Saat membongkar dan merakit kembali Dodge Challenger keluaran 72, saya selalu kagum bahwa mobil ini dibuat dengan sangat baik: sederhana, langsung, murah, tetapi mengejutkan efektif. Misalnya, daya untuk panel instrumen membutuhkan 5 volt yang terpisah dari tegangan keseluruhan mobil (10~18V), dan ada semacam buzzer (memanfaatkan elektromagnet) yang memutus rangkaian di atas 5 volt, lalu menutupnya lagi di bawahnya, sehingga cepat menyala/mati dan menghasilkan rata-rata 5 volt. Kebanyakan orang menggantinya dengan regulator tegangan elektronik, tetapi akibatnya panel instrumen malah tidak berfungsi. Ternyata panel itu bersifat mekanis, sehingga tanpa sedikit noise halus pada 5 volt, jarumnya sering macet; justru 5 volt yang “kasar” ini mencegah kemacetan itu. Kalau diganti dengan versi elektronik, kita malah harus sengaja menambahkan sebagian “noise” itu. Saya kagum betapa unggulnya perangkat mekanis sederhana seperti ini dari sisi efektivitas dan kesederhanaan

  • Nilai sejati dari kode sederhana seperti ini, meskipun menghemat pemeliharaan kode atau waktu kerja orang, sering kali tidak benar-benar diakui. Kode yang menerapkan prinsip KISS (Keep It Simple, Stupid) justru sering diremehkan karena nilainya tidak terlihat. Karena itu, memang ada tim atau organisasi yang pada praktiknya hanya mengelola kompleksitas yang sebenarnya tidak perlu

  • Kadang menyenangkan jika seorang insinyur bisa melakukan sesuatu yang luar biasa, tetapi yang benar-benar penting adalah insinyur yang, meski awalnya tampak sulit, pada akhirnya sering menemukan solusi yang biasa dan sederhana

  • Saat melihat balet, yang terdengar hanya “kelihatannya mudah sekali!”, padahal sebenarnya mereka berlatih puluhan ribu kali agar bisa melakukannya dengan begitu mudah

  • Saya selalu paling menghormati orang yang mampu merangkum hal rumit menjadi sesuatu yang benar-benar sederhana. Sejelas contoh-contoh K&R C, hanya saja saya berharap komentarnya sedikit lebih teliti

• Pertanyaan “apakah kode bisa dipahami sekilas dan onboarding insinyur baru mudah dilakukan” ternyata tidak semudah yang dibayangkan. Tidak jelas apakah yang dimaksud baru itu orang dengan pengalaman 0 tahun, 10 tahun, atau 30 tahun. “Keterbacaan” juga, bagi sebagian orang tampak seperti konsep yang jelas, tetapi sebenarnya merupakan spektrum dari 0 sampai tak terhingga. Persamaan Maxwell sangat jelas bagi seseorang, tetapi sama sekali buram bagi orang lain. Jadi saya selalu bertanya-tanya, ketika orang bilang “kode harus mudah dibaca”, sebenarnya untuk siapa

  • Kode yang mudah dibaca berarti kode yang mempertimbangkan pembacanya dan meminimalkan beban kognitif. Ini juga tujuan abstraksi berlapis dan design pattern. Tentu ini subjektif karena bergantung pada tingkat keahlian pembaca sasaran dan seberapa akrab mereka dengan codebase. Tapi menolak keberadaan keterbacaan hanya karena sifatnya subjektif rasanya berlebihan. Ulysses karya Joyce dan The Cat in the Hat karya Seuss jelas tidak bisa sama-sama disebut sama mudah dibacanya

  • Saya tidak setuju dengan klaim bahwa “keterbacaan bukan konsep”. Kode yang tidak terbaca adalah kode yang tidak bisa dibaca siapa pun, termasuk penulisnya sendiri (atau AI). Kode yang hanya bisa dibaca penulisnya juga bukan kode yang mudah dibaca

  • Persamaan Maxwell pada masanya memang benar-benar sulit, tetapi bentuk yang kita kenal sekarang adalah hasil penyempurnaan oleh Heaviside dan lainnya sehingga keterbacaannya meningkat

  • Saya rasa “keterbacaan lokal” dari sebagian kecil kode tidak terlalu berarti. Jika pola diterapkan secara konsisten di seluruh codebase, maka walaupun polanya agak rumit, secara keseluruhan kode tetap bisa sangat mudah dibaca. Kompleksitas sementara itu tidak masalah selama tidak memengaruhi kualitas keseluruhan kode

  • Keterbacaan biasanya bertujuan mengurangi accidental complexity. Notasi yang buruk bisa membuat persamaan seperti naskah film maupun algoritme yang rumit menjadi sulit dipahami. Jadi, terhadap pertanyaan “kode harus mudah dibaca oleh siapa?”, menurut saya jawabannya adalah: oleh insinyur yang paham bidang terkait, akrab dengan masalahnya, tetapi belum pernah melihat kode itu sendiri. Ini mirip dengan makalah ilmiah; setidaknya harus mudah dibaca oleh kelompok peneliti di bidang itu. Ringkasan No Silver Bullet

• Saya pikir analogi “insinyur yang seleranya buruk pada akhirnya menunjukkan arah yang salah seperti kompas yang rusak” menjelaskan esensinya dengan baik. Orang yang “rusaknya bisa diprediksi” seperti ini bisa disaring lewat wawancara. Yang justru lebih berbahaya adalah “kompas yang rusak sebagian”. Dari luar kelihatan hanya agak melenceng, padahal sebenarnya selalu salah tepat 127 derajat

  • Saya penasaran apakah ada contoh konkret dari insinyur “kompas yang rusak sebagian” ini

• Banyak tulisan seperti ini mencampuradukkan dua isu. Pertama, ada keputusan yang secara objektif buruk tanpa kaitan dengan selera atau prinsip, misalnya pencarian O(n) di list versus pencarian O(1) dengan dictionary. Ada hal-hal teknis yang jelas lebih unggul. Kedua, sisanya adalah trade-off. Mau pakai map-reduce atau loop biasa, tinggal pertimbangkan performa, keterbacaan, kompatibilitas, dan sebagainya. Selama ada alasannya, saya tidak masalah walau berbeda dari pendapat saya. Masalahnya adalah kalau jawabannya salah atau trade-off itu sendiri tidak dipertimbangkan. Saat itu sudah masuk wilayah pemeliharaan, dan tergantung performa atau frekuensinya, kadang memang tidak perlu disentuh. Selama “alasan(why)” untuk keputusan itu jelas, saya bisa menerima semuanya. Saya sendiri tidak yakin apakah ini benar-benar bisa disebut “selera”

• Masalah tulisan ini adalah bahwa poin “orang memberi bobot berbeda pada nilai yang berbeda” dibahas terlalu tanpa konteks. Padahal, dalam praktiknya seorang insinyur seharusnya bisa merasakan nilai mana yang paling penting bagi masalah tersebut (= hard constraint). Kebebasan yang tersisa setelah hard constraint itu dikeluarkan itulah yang pantas disebut “selera”. Kalau dianalogikan dengan seniman, itu adalah bagian di mana, di luar bahan dan spesifikasi yang sudah ditentukan, masih ada batasan tambahan atau kebebasan yang mereka tetapkan sendiri. Selera yang baik pada insinyur perangkat lunak mirip dengan mengejar hal yang minimalis secara estetis dan maksimal dalam pengendalian diri. Kasus yang menurut saya benar-benar “seleranya buruk” adalah ketika seseorang melanggar prinsip tanpa alasan apa pun. Artinya, mereka sering salah mengira kesederhanaan sebagai “sesuatu yang sudah familier”

• Bagian “nilai” dalam tulisan ini terhubung dengan atribut arsitektur perangkat lunak dalam disertasi doktoral Roy Fielding. Disertasi Fielding memang lebih terkenal karena REST, tetapi sebenarnya merupakan pembahasan arsitektur perangkat lunak yang lebih luas dan kokoh. Itu membantu kita berpikir dalam konteks berbagai “atribut arsitektur” seperti skalabilitas, keterbacaan, maintainability, dan lain-lain, dan secara pribadi saya juga ingin menekankan betapa pentingnya memahami “constraint arsitektur” selain atribut-atribut ini

• Engineering yang benar (Principled engineering) seharusnya memang menjadi hal yang mendasar. Di atas fondasi itu, selera bisa baik atau buruk. Tapi kebalikannya tidak berlaku. Jika engineering-nya sendiri buruk, selera tidak ada artinya. Selera buruk bisa menghambat efisiensi engineering, tetapi tidak membuat engineering itu sendiri mustahil. Pada dasarnya engineering berperan menopang selera. Misalnya, bahkan sesuatu yang direkayasa dengan sempurna pun tidak berarti apa-apa kalau tidak dibutuhkan dan tidak diinginkan

• Selera yang buruk pada akhirnya membawa kita ke situasi tak pasti (X) yang ingin kita hindari. Menurut saya, selera yang baik pada akhirnya berarti menyiapkan fondasi yang kokoh dan pagar pengaman di codebase untuk menghadapi ketidakpastian masa depan yang akan datang. Dengan begitu kita tidak jatuh ke dalam risiko

[gagamel]

Sangat bagus

[castedice]

Artikel aslinya bagus, tetapi isi komentarnya juga benar-benar bagus.

[edunga1]

Kalau bicara soal selera, saya jadi teringat video TED Torvalds:
https://www.ted.com/talks/linus_torvalds_the_mind_behind_linux

Mulai 14:20, selera yang baik dilihat dari cara mengimplementasikan kode penghapusan entry pada linked list

[bakyeono]

Bahkan “keputusan yang secara objektif buruk (misalnya pencarian O(n) pada list vs pencarian O(1) dengan dictionary)” yang disebutkan dalam opini Hacker News pun, tergantung konteksnya, bisa jadi perlu diputuskan secara berbeda.
Jika pencarian hanya dilakukan satu kali, biaya membuat hash table bisa lebih besar daripada melakukan pencarian O(n) pada list.

[shakespeares]

Komentar yang bagus.