Mengapa Pengembang Benci Mengubah Versi Bahasa

Programmer

Kemajuan mendorong teknologi ke depan. Tetapi kemajuan juga memiliki biaya: dengan menambahkan kemampuan dan fitur baru, komunitas pengembang terus menyesuaikan blok bangunan. Itu termasuk bahasa dasar yang digunakan untuk mengkodekan solusi teknologi.

Ketika blok bangunan berubah, kode di balik solusi teknologi juga harus berubah. Ini adalah latihan yang menantang dan memakan waktu yang menguras sumber daya. Tapi bagaimana jika ada alternatif?

Masalahnya: membaca kode yang ditulis orang lain

Mari kita mundur selangkah dan melihat salah satu tantangan mendasar dalam pengembangan: mengedit kode orang lain. Mengedit kode yang baru saja Anda tulis, atau tulis beberapa minggu yang lalu, tidak masalah. Tetapi mengedit kode Anda sendiri yang ditulis bertahun-tahun yang lalu – apalagi kode orang lain – itu cerita yang berbeda.

Aturan gaya kode internal dapat membantu tetapi selalu ada konvensi penamaan yang aneh untuk variabel dan fungsi, atau pilihan yang tidak biasa untuk algoritme. Bisa dibilang, kemampuan programmer untuk membaca kode adalah keterampilan utama – tetapi sulit untuk semua orang.

Pengembang menyebut proses pengeditan kode lama “refactoring” dan ini adalah proses yang biasanya menimbulkan bug baru atau masalah kinerja. Jadi itulah sebabnya, kembali dan mengedit kode lama, yah – itulah hal terakhir yang ingin dilakukan sebagian besar tim pengembangan, terutama ketika basis kode yang ada berjalan stabil dan melakukan tugasnya.

Ini benar-benar sakit kepala, tetapi terkadang tidak ada alternatif lain

Refactoring adalah sesuatu yang setiap pengembang ingin hindari selama mungkin karena bisa terasa seperti buang-buang waktu. Meskipun demikian, pengembang harus melakukan refactor dari waktu ke waktu karena berbagai alasan, dan salah satu alasan paling umum adalah karena perubahan blok bangunan pengembang.

Related Post :   Paradoks Admin Aplikasi SaaS

Itu termasuk perubahan pada bahasa pemrograman yang digunakan untuk membangun perangkat lunak, yang pasti berkembang seiring waktu. Versi bahasa yang baru sering kali tidak akan menggunakan cara lama dalam melakukan sesuatu sambil memperkenalkan fitur baru. Jika pengembang tidak mengadopsi versi bahasa baru, mereka dikecualikan dari rangkaian fitur baru.

Namun, kode yang ada biasanya memerlukan penyesuaian untuk dijalankan pada versi bahasa yang baru, dan itu menyiratkan proses refactoring. Dan itulah teka-tekinya: untuk mengadopsi versi baru yang lebih maju dari sebuah bahasa, pengembang perlu melakukan refactor, dan di sepanjang jalan mereka akan menghabiskan banyak usaha – dan memecahkan segala macam hal tak terduga, memperkenalkan bug baru ke dalam aplikasi yang berjalan baik-baik saja.

Lebih buruk lagi, refactoring saja tidak memberi Anda keuntungan dari versi bahasa baru, sebaliknya Anda perlu mengembangkan kembali basis kode Anda untuk memanfaatkan peningkatan. Jika tidak, meskipun menyesuaikan kode agar sesuai dengan versi bahasa baru, Anda tetap seperti dulu: basis kode yang berjalan pada versi bahasa baru, tetapi tanpa fitur baru.

Vendor biasanya membiarkan pengguna akhir untuk menanganinya

Ini mungkin tampak seperti latihan yang sia-sia, tetapi, dengan perubahan teknologi yang stabil, seringkali ada sedikit pilihan dalam masalah ini – dengan mitra teknologi Anda yang memilihkan untuk Anda.

Katakanlah kita baru saja pindah dari Python 2.7, ke Python 3.0. Jika Anda mengembangkan aplikasi Anda sendiri, Anda memegang kendali penuh dan dapat melakukan perubahan, atau tidak melakukan perubahan. Pengembang, di sisi lain, mungkin memutuskan untuk membiarkan semuanya. Jika aplikasi dikembangkan untuk dan berjalan di Python 2.7, pengembang akan membiarkannya begitu saja – dan memberi tahu pengguna bahwa aplikasi dikembangkan untuk Python 2.7, tanpa dukungan untuk versi lain.

Related Post :   Peretas Menyebarkan Kerangka Eksploitasi IceApple di Server MS Exchange yang Diretas

Ini dapat membuat pengguna berada di posisi yang sulit – tetap menggunakan versi Python 2.7 yang lebih lama untuk mengakomodasi aplikasi, meninggalkan kemajuan, atau beralih ke Python 3.0, dan mengambil risiko berbagai ketidaksesuaian dengan aplikasi.

Hasil bersihnya: risiko keamanan utama

Bahasa pemrograman (dan berbagai macam pustakanya) tidak kebal terhadap kerentanan keamanan. Ketika kerentanan ini muncul, pemutakhiran versi bahasa dapat dipaksakan kepada Anda oleh pengembang.

Tetapi pemutakhiran ini tidak akan terbatas pada perbaikan bug sederhana – mereka akan membawa penghentian konstruksi bahasa dengan konstruksi baru yang dibawa, dan itu akan memaksa pengembang untuk melakukan gerakan melakukan perubahan pada kode yang ada, sekali lagi dengan semua potensi masalah yang membawa.

Situasi menjadi lebih buruk ketika Anda memikirkan efek gabungan dari perpustakaan yang disertakan. Setelah perubahan bahasa, perpustakaan ini juga harus diperbarui – tetapi jika salah satu perpustakaan yang digunakan tidak diperbarui oleh pembuatnya, pengembang tidak akan dapat menggunakannya setelah memutakhirkan sisa kode ke versi yang lebih baru, lagi-lagi mengarah untuk lebih banyak menulis kode.

Sangat mudah untuk melihat ke mana semuanya mengarah: lebih banyak usaha, risiko tambahan memperkenalkan bug … dan keengganan untuk melakukan refactoring untuk mengakomodasi pembaruan. Lanjut? Pembaruan tidak selesai, yang berarti bahwa beban kerja bergantung pada blok bangunan yang tidak aman dan ketinggalan zaman.

Related Post :   Gootkit Loader Muncul Kembali dengan Taktik yang Diperbarui untuk Mengganggu Komputer Target

Ceritanya mirip dengan apa yang kita lihat dimainkan di seluruh dunia teknologi, karena blok bangunan tua dan rentan membiarkan pintu terbuka untuk serangan siber. Namun, ada kabar baik yang muncul.

Apakah ada solusi yang lebih baik?

Ambil sistem operasi yang tidak didukung, misalnya. Di masa lalu, ketika OS mencapai akhir masa pakainya, satu-satunya pilihan adalah meningkatkan ke OS yang lebih baru – investasi besar, dan penuh risiko. Hasil akhirnya adalah banyak organisasi mengandalkan sistem operasi yang tidak ditambal dan tidak didukung bahkan untuk beban kerja kritis. Jika Anda tidak memiliki aplikasi yang diperbarui, karena pengembang tidak akan memfaktorkan ulang basis kode lama, Anda tidak dapat memindahkan aplikasi Anda ke sistem operasi yang lebih baru yang tidak mendukung versi lama bahasa tersebut – dan dengan demikian merusak aplikasi.

Untungnya, skenario ini berubah karena dukungan akhir masa pakai sekarang menjadi kenyataan bagi banyak sistem operasi Linux, yang berarti bahwa organisasi dapat mengulur waktu untuk berpindah dari OS yang tidak didukung ke OS dengan dukungan vendor resmi, tanpa mengambil risiko keamanan apa pun.

Bisakah hal serupa dilakukan untuk versi bahasa? Cara untuk secara efektif “meningkatkan” runtime bahasa dengan perbaikan keamanan terbaru sementara pada saat yang sama tidak mengubah cara kerja versi bahasa atau pustaka tertentu, sehingga menghilangkan kebutuhan untuk refactor?

Mengulangi apa yang telah dicapai untuk sistem operasi dan menerapkannya ke versi bahasa akan memberi pengembang ruang bernapas yang sangat besar, mengurangi kebutuhan untuk terus melakukan refactor. Pada gilirannya, ada kemungkinan lebih tinggi bahwa beban kerja berjalan dengan aman dan terjamin.

Apa itu mungkin? Nah, apa yang dicapai agar sistem operasi bisa diperluas ke area lain. Perhatikan ruang ini.


Tinggalkan Balasan

Alamat email Anda tidak akan dipublikasikan.