Waspadai efek Makefile

Pemrograman, filosofi, mengayuh.

---

10 Januari 2025

Tag: pemrograman

---

Saya tidak mengetahui a sempurna ^{istilah untuk ini, jadi saya mengarangnya: efek Makefile.}

Efek Makefile bermuara pada ini:

Alat dengan kompleksitas tertentu atau ketidakbiasaan rutin tidak dijalankan laginamun malah disalin dan di-tweak dari contoh-contoh bagus sebelumnya.

Anda sering melihat efek ini pada insinyur dari semua bidang dan tingkat keahlian/pengalaman Membuat menjadi contoh umum^:

1. Sebuah tugas (salah satu bentuk umum) perlu diselesaikan. Tugas yang sangat mirip (atau bahkan identik) telah dilakukan sebelumnya.
2. Membuat (atau alat lain yang rentan terhadap efek ini) adalah alat yang benar atau “terbaik” (mengingat kelayakannya, ketergantungan jalur, apa pun) alat untuk tugas tersebut.
3. Daripada menulis a Makefileinsinyur menyalin yang sebelumnya (terkadang sangat besar dan rumit^{) Makefile dari contoh tugas sebelumnya dan menyesuaikannya hingga berfungsi dalam konteks baru.}

Pada satu tingkat, ini adalah hasil yang sangat bagus (bahkan ideal) rekayasa tanggapan di titik solusi: menerapkan contoh kerja sering kali merupakan hal yang pelit untuk dilakukan, dan memiliki risiko lebih kecil (secara teori) untuk menimbulkan bug, karena sebagian besar pekerjaan tidak berubah.

Namun, di titik desainini menunjukkan desain alat (atau alat aplikasi^{) yaitu cacat: alat (atau sistem) terlalu rumit (atau mengganggu) untuk digunakan dari awal. Alih-alih menggunakannya untuk memecahkan masalah dari awal, pengguna berulang kali menyalin solusi yang sudah dikenal baik dan membuat perubahan seiring berjalannya waktu.}

Begitu Anda menyadarinya, Anda mulai melihat pola ini di mana-mana. Melampaui Pembuatan:

• Konfigurasi CI/CD seperti GitHub Actions dan GitLab CI/CD, tempat pengguna menyalin spaghetti YAML mereka dari terakhir setup yang berfungsi dan sesuaikan (sering kali dengan menjalankan ulang berulang kali) hingga berfungsi kembali;
• Konfigurasi linter dan formatter, di mana seperangkat aturan dasar disalin antar proyek dan diperkuat/dilonggarkan sesuai kebutuhan untuk kondisi lokal;
• Bangun sistem itu sendiri, di mana segala sesuatu yang non-sepele mulai menyerupai sistem pembangunan sebelumnya.

Apakah ini penting?

Dalam banyak kasus, mungkin tidak. Namun, menurut saya hal ini layak untuk dipikirkan, terutama saat merancang alat dan sistem:

• Alat dan sistem yang mengaktifkan pola ini seringkali memiliki dukungan diagnostik atau debugging yang kurang ideal: pengguna harus menjalankan alat tersebut berulang kali, seringkali dengan penundaan yang lama, untuk mendapatkan kembali sejumlah informasi yang relatif kecil. Pikirkan tentang penyiapan CI/CD, di mana pengguna mendiagnosis CI/CD yang disalin dan ditempel dengan melakukan debugging gaya cetak melalui jaringan dengan lapisan orkestrasi VM perantara. Konyol!

• Alat yang sering mengaktifkan pola ini menghambat pembelajaran yang luas: beberapa pakar mengetahui alat ini dengan cukup baik untuk mengonfigurasinya, dan yang lain menyalinnya hanya pengetahuan yang cukup untuk melakukan penyesuaian yang ditargetkan. Hal ini terkadang tidak dapat dihindari, namun seringkali tidak: grafik ketergantungan merupakan kompleksitas yang melekat pada sistem pembangunan, namun perlu diingat perbedaan di antara keduanya $< Dan $^ di Make tidak.

• Alat yang mengaktifkan pola ini adalah lebih sulit untuk digunakan dengan aman: tindakan keamanan biasanya memerlukan pengetahuan mendalam tentang Mengapa di balik suatu perilaku. Sistem yang terkena efek Makefile juga sering kali menyebabkan kebingungan antara kode dan data (atau jenis lainnya
  pensinyalan dalam pita secara lebih umum), sebagian besar karena solusi fungsional tidak selalu aman. Misalnya saja tentang
  injeksi templat di Tindakan GitHub.

Secara umum, menurut saya alat (dan sistem) yang dirancang dengan baik harus bertujuan untuk meminimalkan efek ini. Ini mungkin sulit dilakukan secara umum, namun ada beberapa hal yang saya pikirkan saat merancang alat baru:

• Apakah itu membutuhkan agar dapat dikonfigurasi?
• Apakah itu membutuhkan sintaksnya sendiri?
  • Sebagai akibat wajar: bisakah digunakan kembali sintaks atau idiom yang familier dari alat/CLI lain?
• Melakukan SAYA akhirnya menyalin-menempelkan penggunaannya? Jika ya, ya yang lain kemungkinan besar akan melakukan hal yang sama?

---

---