Kita Sedang Merusak Perangkat Lunak

• Kita sedang merusak perangkat lunak dengan tidak lagi mempertimbangkan kompleksitas saat menambahkan fitur atau mengoptimalkan bagian tertentu
• Kita sedang merusak perangkat lunak dengan sistem build yang rumit
• Kita sedang merusak perangkat lunak dengan membuat segala sesuatu membengkak dan rapuh melalui rantai dependensi yang tidak masuk akal
• Kita sedang merusak perangkat lunak dengan mengatakan kepada programmer baru, "Don’t reinvent the wheel!". Padahal, menciptakan ulang roda adalah cara untuk mempelajari bagaimana sesuatu bekerja dan langkah pertama untuk membuat roda baru yang berbeda
• Kita sedang merusak perangkat lunak dengan tidak lagi mempertimbangkan kompatibilitas mundur API
• Kita sedang merusak perangkat lunak dengan mendorong penulisan ulang hal-hal yang sebenarnya sudah berjalan dengan baik
• Kita sedang merusak perangkat lunak dengan langsung ikut arus setiap kali muncul bahasa, paradigma, atau framework baru
• Kita sedang merusak perangkat lunak dengan selalu meremehkan sulitnya menangani library kompleks yang sudah ada dibandingkan dengan mengimplementasikannya sendiri secara langsung
• Kita sedang merusak perangkat lunak dengan menganggap bahwa standar de facto XYZ selalu lebih baik daripada sesuatu yang bisa kita implementasikan sendiri sesuai kebutuhan penggunaan spesifik kita
• Kita sedang merusak perangkat lunak dengan mengklaim bahwa komentar kode tidak berguna
• Kita sedang merusak perangkat lunak dengan salah mengira perangkat lunak semata-mata sebagai disiplin rekayasa murni
• Kita sedang merusak perangkat lunak dengan membangun sistem yang tidak bisa lagi diperkecil: dalam sistem apa pun, hal yang sederhana seharusnya bisa dicapai dengan sederhana
• Kita sedang merusak perangkat lunak dengan berusaha menghasilkan kode secepat mungkin tanpa berupaya membuat kode yang dirancang sebaik mungkin
• Kita sedang merusak perangkat lunak, dan yang akan tersisa nanti tidak lagi memberikan kesenangan dalam mengutak-atik

[dohyun682]

Menciptakan ulang roda <-> menciptakan ulang sesuatu yang sudah ditulis

Bukankah keduanya merupakan konsep yang benar-benar saling bertentangan?

[roxie]

Ledakan komentar akan datang

[tujuc]

Sangat terasa ya wkwkwk. Setiap kali junior baru masuk... saya selalu kepikiran bagaimana cara menjelaskannya. Sepertinya ini bisa jadi cara yang bagus..

[ilikeall]

Tolong hentikan memukulnya T_T

[bus710]

....Aku akan diam saja...

[laeyoung]

Banyak yang tampak tumpang tindih dengan "10 tanda negara menuju kehancuran" yang pernah dikatakan Han Feizi.

[GN⁺]

Komentar Hacker News

• Mengingatkan pada ceramah Jonathan Blow. Perangkat lunak, jika tidak dirawat, akan membusuk seperti halnya segala sesuatu yang lain

  • Teknologi perangkat lunak tampak seperti berkembang di permukaan, tetapi sebenarnya sedang mengalami kemunduran
  • Peningkatan hardware dan kemajuan machine learning menciptakan ilusi kemajuan, tetapi kekokohan dan keandalan mendasar perangkat lunak justru memburuk
  • Pengembangan perangkat lunak modern menjadi rumit secara tidak perlu, sehingga tugas sederhana pun menjadi sulit
  • Kompleksitas ini menurunkan produktivitas programmer dan menghambat transfer pengetahuan antar generasi
  • Masyarakat pun menerima perangkat lunak yang penuh bug dan tidak dapat diandalkan sebagai sesuatu yang normal
  • Jika kita tidak menyederhanakan sistem perangkat lunak di semua level, dari sistem operasi hingga alat pengembangan, peradaban akan menghadapi risiko kemunduran teknologi yang mirip dengan keruntuhan historis

• Mengingatkan pada "10 prinsip desain yang baik" dari Dieter Rams

  • Desain yang baik itu inovatif
  • Desain yang baik membuat produk berguna
  • Desain yang baik itu estetis
  • Desain yang baik membuat produk mudah dipahami
  • Desain yang baik tidak mencolok
  • Desain yang baik itu jujur
  • Desain yang baik bertahan lama
  • Desain yang baik dikerjakan dengan tuntas hingga detail terakhir
  • Desain yang baik ramah lingkungan
  • Desain yang baik adalah desain sesedikit mungkin

• Membagikan pengalaman bekerja di perusahaan pada era 2000-an

  • Menjalankan pekerjaan dengan puluhan komputer, membangun ruang server, dan membangun SAN untuk menyimpan 3TB data
  • Mengatur koordinasi pekerjaan antar komputer yang menjalankan skrip Object Rexx dengan scheduler pekerjaan VB6 buatan sendiri
  • Mengirim dan menerima file menggunakan load balancer internal, web server, mail server, FTP server, serta perangkat lunak buatan sendiri
  • Sekarang seluruh pengaturan itu dapat direproduksi dalam waktu kurang dari seminggu melalui file yaml dan layanan cloud
  • Arsitektur server telah menjadi "terabstraksi"
  • Kritik terhadap kompatibilitas mundur, yang disebut sebagai salah satu masalah Windows
  • Apple memutus kompatibilitas mundur, berpindah melewati 5 prosesor, dan menghapus kompatibilitas kode 32-bit pada chip ARM

• Ada banyak pendapat yang saling bertentangan

  • Kita harus menghindari kompleksitas sambil tetap menjaga kompatibilitas mundur
  • Kita harus menghindari pohon dependensi raksasa dan menciptakan ulang roda sendiri
  • Satu-satunya cara untuk memenuhi semua tuntutan adalah jika tidak semua orang menulis kode
  • Ada kalanya berharap itu terjadi setidaknya sekali sehari, tetapi tidak merasa bangga akan hal itu

• Membagikan pengalaman di pekerjaan pertama

  • Menulis perangkat lunak dalam C, dan saat itu itu adalah satu-satunya bahasa yang secara realistis bisa dipakai untuk menulis perangkat lunak komersial
  • Hanya ada satu orang yang bisa melakukan build, memakai alat build komersial, dan dia juga satu-satunya yang bisa menggunakan alat itu
  • Proses build memakan waktu berjam-jam
  • Kami pikir kami sudah bekerja dengan baik

• Pendapat tentang alasan kita merusak perangkat lunak

  • Kita merusak perangkat lunak dengan selalu menganggap standar de facto milik XYZ lebih baik daripada sesuatu yang disesuaikan untuk kita
  • Pendekatan umum membuat kita mudah beralih ke solusi dangkal untuk banyak masalah
  • Para teknisi menyukai pendekatan ini, terutama karena mereka sering berpindah pekerjaan, sehingga mereka punya beberapa hal seperti itu
  • Namun solusi khusus sering kali berkinerja jauh lebih baik daripada yang umum

• Setiap pernyataan adalah trade-off

  • Di setiap kasus, kita mengorbankan sesuatu untuk mendapatkan hal lain
  • Kadang masuk akal untuk tidak menciptakan ulang roda
  • Kadang kita perlu menciptakan ulang roda demi pembelajaran
  • Secara keseluruhan, kita menciptakan lebih banyak daripada yang kita hancurkan
  • Tidak merasa perlu mengambil posisi yang negatif

• Menghormati antirez, tetapi merasa postingan ini penuh dengan pernyataan singkat yang terdengar bagus namun tidak akan bertahan dalam diskusi

  • Contoh: pemula tidak seharusnya menciptakan ulang roda
  • Mereka harus menggunakan alat yang tersedia dalam konteks yang diberikan
  • Jika mereka ingin bereksperimen, mereka harus menulis compiler mereka sendiri
  • Namun itu tidak boleh digunakan dalam produksi
  • Kompatibilitas API ke belakang dalam banyak kasus adalah keputusan bisnis
  • Memulai setiap kalimat dengan "kita sedang merusak perangkat lunak" tidak membantu
  • Itu terdengar jauh lebih suram daripada kenyataannya

• Pendapat tentang grafik kompleksitas/dependensi

  • Grafik kompleksitas/dependensi dari aplikasi acak benar-benar gila
  • Itu tidak mencakup firmware dan OS, tetapi sudah cukup dekat
  • Masalah dependensi transitif harus diselesaikan
  • Menganggap OS (Win32 API, Linux syscalls) sebagai satu-satunya dependensi keras dari segala sesuatu yang ditulis dalam C
  • Jika beralih ke Java/Python, kita tidak dapat mengendalikan layer ini
  • Perlu menulis beberapa ratus baris kode yang sesuai untuk situasi tertentu alih-alih bergantung pada semua library
  • Beban pemeliharaan memang meningkat, tetapi dependensi juga perlu dipelihara
  • Dependensi bisa memiliki API yang buruk, memutus kompatibilitas secara acak, ditinggalkan, atau berubah menjadi malware
  • Batas maksimal pribadi untuk proyek yang berguna adalah 5-10KLOC Java/JS/Python
  • Itu bisa ditinjau dalam beberapa jam dan dimodifikasi dengan mudah beberapa tahun kemudian

• Hal-hal yang merusak perangkat lunak

  • Wawancara Leetcode, pengembangan berbasis resume, perpindahan kerja yang sering, penipuan investasi pertumbuhan, permainan metrik, mengejar promosi, sandiwara sprint, omong kosong di setiap level bagan organisasi, ketidakpedulian industri