Perangkat lunak berdarah dingin

Perangkat lunak dengan darah dingin

• Pada tahun 2004, saat penulis yang mengambil jurusan ilmu komputer sedang mengikuti kuliah sejarah alam, dosen menunjukkan seekor bayi kura-kura painted yang dibekukan.
• Kura-kura ini adalah salah satu dari sedikit spesies yang dapat bertahan hidup dalam keadaan beku, yaitu hewan berdarah dingin yang mampu mengatur metabolisme pada suhu rendah.
• Dengan mengamati kura-kura itu perlahan bergerak dan kembali hidup selama kuliah berlangsung, pemahaman penulis tentang hewan berdarah dingin menjadi lebih dalam.

Dikotomi proyek perangkat lunak

• Proyek perangkat lunak juga dapat dibagi menjadi proyek berdarah hangat dan berdarah dingin.
• Proyek berdarah hangat membutuhkan aktivitas yang berkelanjutan, dan jika aktivitas berhenti maka masalah akan muncul.
• Proyek berdarah dingin dapat dilanjutkan kembali meski aktivitas sempat jarang, dan saat dimulai lagi bisa langsung berjalan dari kondisi sebelumnya.

Perangkat lunak berdarah dingin pada blog

• Perangkat lunak yang menjalankan blog penulis adalah perangkat lunak berdarah dingin.
• Proyek yang dimulai 12 tahun lalu ini sederhana, tidak bergantung pada layanan eksternal, dan semua dependensi disertakan dalam repositori proyek.
• Selain beberapa peningkatan kecil, proyek ini berjalan baik tanpa perubahan, dan diperkirakan akan tetap berjalan selama 12 tahun ke depan.

Pendapat GN⁺

• Konsep perangkat lunak berdarah dingin memberi dampak penting pada keberlanjutan dan kemudahan perawatan proyek.
• Tulisan ini memberi wawasan tentang bagaimana pilihan tech stack memengaruhi umur hidup sebuah proyek.
• Pengalaman penulis memberi pelajaran bagi para pengembang perangkat lunak tentang cara membangun sistem yang stabil dalam jangka panjang.

[GN⁺]

Opini Hacker News

• Di ekosistem Node dan JavaScript ada framework web Express. Branch versi utama saat ini, 4.x.x, sudah berusia lebih dari 10 tahun dan diunduh lebih dari 17 juta kali per minggu. Meski ada beberapa fitur yang kurang dan performanya bukan yang terbaik, banyak developer menyukainya karena memungkinkan pengembangan yang cepat dan stabil, serta memudahkan membuat rencana jangka panjang tanpa khawatir soal perubahan API atau kurangnya patch keamanan. Go menawarkan stabilitas yang lebih baik berkat standard library yang luas dan janji kompatibilitasnya, sehingga program yang dibuat lebih dari 10 tahun lalu pun masih bisa dijalankan.

• Jika software tetap bekerja dengan baik tanpa update, biasanya itu karena sejak awal dibuat dengan benar. Untuk software yang dipakai pribadi, ini relatif lebih mudah karena preferensi tidak banyak berubah. Namun saat menulis software untuk dipakai orang lain, kebutuhan bisa berbeda dan masalah tak terduga bisa muncul. Misalnya, aplikasi bisa crash saat memproses file besar, dan untuk memperbaikinya mungkin perlu menulis ulang setengah dari software tersebut. Ini adalah sanggahan terbesar terhadap klaim bahwa software yang jarang berubah pasti lebih baik.

• Python adalah contoh yang kurang baik karena terus-menerus mengalami perubahan yang merusak kompatibilitas. Sebaliknya, Go atau Java membuat kode berusia 10 tahun tetap berjalan baik dengan tool modern. Perl adalah contoh yang lebih baik lagi, karena kode berusia 30 tahun pun masih berfungsi dengan baik.

• Saya bekerja dengan mainframe IBM (z/OS). Dalam hal menjaga kompatibilitas ke belakang, IBM adalah yang terbaik. Microsoft (Windows) di posisi kedua, dan ABI Linux (kernel) di posisi ketiga. Sebagian besar sistem lain mengalami masalah yang umum terjadi pada OSS yang tidak ingin meluangkan waktu untuk menjaga kompatibilitas.

• Dependensi bisa membuat aplikasi menjadi 'berdarah hangat', tetapi Docker atau containerisasi bisa menyelesaikan sebagian masalah ini. Saat memilih library untuk sebuah proyek, saya melakukan riset yang cukup untuk memastikan apakah library itu termasuk 'berdarah dingin'.

• Banyak engineer saat mencari library di GitHub memeriksa kapan commit terakhir dibuat. Mereka menganggap semakin baru commit-nya, semakin baik pula dukungannya. Namun menemukan proyek yang sudah diarsipkan, stabil dalam waktu lama, dan bebas bug itu seperti menemukan permata tersembunyi di toko barang bekas.

• Saya memelihara side project saya sendiri. Proyek itu dimulai 12-13 tahun lalu, lalu saya tulis ulang dengan PHP, Laravel, dan Symfony. Pengalaman itu sangat berharga untuk belajar cara memelihara proyek dalam jangka panjang. Misalnya, saya mencari peluang untuk menyederhanakan dari Vagrant ke Docker, dan dari Vue + Axios + Webpack menjadi Htmx. Baru-baru ini saya juga meng-upgrade ke PHP 8.2 dan Symfony 7 serta mengintegrasikan fitur berbasis ChatGPT.

• Saya muak dengan aplikasi mobile beberapa tahun terakhir yang membutuhkan pekerjaan patch setiap beberapa jam. Penulis menggambarkan static site generator miliknya sebagai 'berdarah dingin', berjalan di Python 2, tetapi sekarang instalasi Python 2 makin sulit.

• SDK yang saya tulis pada 1994-95 tetap dipakai sampai saya meninggalkan perusahaan pada 2017. Itu ditulis dalam ANSI C, dan sesuatu yang saya tulis dengan PHP(5) juga tetap berjalan baik di PHP 8.2. Namun hal-hal seperti ini membosankan dan tidak punya nilai sensasional.

• Selain yang disebut dalam artikel, penting juga memiliki threat model yang secara inheren aman. Misalnya, seluruh website harus terus menghadapi penyerang, bot spam, dan sebagainya, sehingga secara inheren bersifat 'berdarah hangat'. Sebaliknya, halaman statis seperti Tiddlywiki jauh lebih baik karena tidak perlu diunggah ke web dan browser adalah platform yang sangat stabil.