Nama untuk templat ini adalah fungsi.
Lebih khusus lagi, ini adalah antarmuka, yang biasanya merupakan kumpulan fungsi.
Bahasa apa yang sudah kamu pelajari?
Salah satu yang pertama ketika kita belajar pemrograman, kita mempelajari prinsip logika yang dapat digunakan kembali. Ini selalu membawa kita untuk berfungsi - blok bangunan dari setiap proyek perangkat lunak. Fitur-fiturnya sendiri tidak terlalu buruk, tetapi justru karena mereka digunakan sebagai komponen yang dapat digunakan kembali sehingga perangkat lunak penulisan, pemeliharaan, dan penskalaan menjadi sangat mahal.
Mengapa?
Menulis kode yang dapat digunakan kembali itu sulit.
Tidak, tidak seperti itu. Ini tidak bisa diterima.
Setiap pengembang dapat menulis kode yang dapat digunakan kembali, terlepas dari pengalaman mereka. Bahasa seperti JavaScript, Python, Ruby, dan Go terdiri dari jutaan modul umum kecil yang menunjukkan kemudahan penulisan kode sumber yang sederhana dan dapat digunakan kembali. Sangat mudah untuk menulis kode yang dapat digunakan kembali .
Mari kita perbaiki pernyataan ini.
Tapi ini juga tidak terjadi. Lihatlah perpustakaan node.js
repeat-string
di npm. Itu tidak melakukan apa-apa selain mengulang baris, dan para pengembang mengunduhnya tujuh belas juta kali setiap minggu.
Jumlah unduhan repeat-string di npm
Seventeen juta hanyalah jumlah unduhan. Angka ini tidak akan memberi kita gambaran berapa kali fungsi ini digunakan dalam kode sumber. Jumlahnya harus sangat besar!
Jadi apa yang saya lakukan?
Bagaimana Anda bisa menemukan modul seperti
repeat-string
untuk proyek node.js Anda? Cari "string berulang" di npm . Mungkin Anda memasukkan "string repeat", tetapi hasilnya akan serupa. Masalah yang saya bicarakan dapat dilihat di hasil pencarian kedua. Dan yang keempat, dan yang kesembilan, dan yang kesepuluh, dan yang kesebelas.
Lihat contoh berikut. Setiap pustaka menyediakan perilaku yang sepenuhnya identik.
Contoh pustaka pengulangan baris npm
Apakah Anda melihat apa masalahnya?
Tidak, bukan karena salah satunya tidak sinkron karena alasan yang tidak diketahui. Belum lagi pengulangan string telah menjadi bagian dari bahasa JavaScript (
"A".repeat(5)
) selama lebih dari enam tahun sekarang . Masalahnya adalah setiap perpustakaan berbeda:
- Di tanda tangan data yang masuk. Beberapa mungkin menerima
(string, int)
, yang lain mungkin menerima(int, string)
. Satu menerima angka floating point, yang lain membutuhkan fungsi callback. - Di tanda tangan keluaran. Setiap perpustakaan mencetak string, kecuali satu, yang tidak mencetak apa-apa dan meneruskan hasilnya ke fungsi callback. Dan biarkan saya bahkan tidak mulai mengurai kesalahan mereka.
- Dalam perilaku saat mereka dieksekusi. Yang satu tidak sinkron, yang lainnya sinkron.
- Dengan metode pemberian akses. Beberapa menyediakan akses ke satu fungsi yang diekspor, yang lain menyediakan fungsi sebagai metode objek.
Anda dapat menyalahkan JavaScript karena berbagai alasan, tetapi ini bukan masalah dengan bahasanya. Karena popularitas JavaScript dan keterbatasan pustaka standarnya, masalah ini sangat umum sehingga saya dapat mendemonstrasikannya dengan contoh yang sederhana seperti pengulangan string. Di sisi lain, tidak ada yang mencegah saya untuk menciptakan kembali semua perbedaan ini dalam bahasa lain. Ini adalah contoh yang sangat sederhana, tetapi karena fungsionalitas menjadi lebih kompleks, perbedaan ini menjadi lebih jelas.
Mengapa ini menjadi masalah?
Masalahnya adalah banyaknya pilihan tidak menciptakan nilai apapun , hanya masalah saja. Mereka tidak mempengaruhi "logika bisnis" (yaitu, yang penting sejak awal). Ini adalah detail implementasinya. Kadang-kadang pilihan ini muncul dari kurangnya sesuatu dalam bahasa atau kerangka kerja, dan terkadang itu hanya pilihan spontan. Kami mencoba memilih opsi yang akan menyederhanakan pekerjaan pengembang sekarang atau di masa depan, tetapi tidak mungkin untuk memprediksi masa depan. Solusi semacam itu benar-benar jahat - setiap opsi yang Anda pilih tampak bagus pada awalnya, sementara semuanya berfungsi. Kami menerima dorongan dopamin dan merasa seperti berada di puncak dunia. Tuan dari semua sistem! Namun, ketika kita perlu menambah, mengganti, atau mengubah sesuatu, kita menyadari bahwa kita bukanlah orang yang jenius.
Seberapa sering kita perlu mengubah sesuatu? Setiap hari. Inilah yang kami lakukan. Seberapa sering perangkat lunak rusak karena ini? Secara harfiah setiap saat. Terkadang kerusakannya kecil dan kami memperbaikinya dengan sedikit usaha. Kami telah menerima fakta bahwa perangkat lunak yang rusak itu normal. Bahkan ketika kami menulis tes otomatis yang tidak melakukan apa-apa selain memeriksa bahwa ada sesuatu yang rusak.
Masalah dengan antarmuka berasal dari fakta bahwa seorang programmer dapat membuat banyak keputusan selama proses pengembangan. Keputusan seperti memilih antara parameter posisi, konfigurasi dan linker, asynchronous versus synchronous, global versus local, stateful versus stateless, konstruktor versus pabrik, pendekatan fungsional versus berorientasi objek, dan sejumlah pilihan lain yang tak terbatas. Setiap pilihan ditentukan oleh praktik terbaik modern dan masing-masing menjadi butiran pasir yang terperangkap di dalam mekanisme tersebut.
Masalah ini bukanlah hal baru, bagaimanapun, kami menahannya dan mengajarkan pendekatan ini kepada setiap generasi baru. Mengapa? Masalahnya bukan karena kita membuat keputusan yang salah, tetapi kita dihadapkan pada pilihan yang buruk. Setiap opsi adalah kaleidoskop trade-off, dan jawaban yang benar tergantung pada sudut pandang. Ketika semuanya adalah kompromi, selalu ada pilihan yang lebih baik . Anda selalu dapat menulis ulang kode Anda untuk membuatnya lebih baik.
Mari kita perbaiki pernyataan kita untuk ketiga kalinya.
Pernyataan ini tidak begitu menarik, tetapi lebih mendekati kebenaran.
Tanpa kode untuk hanya menempel, kita perlu menyetrika setiap lipatan antarmuka sebelum kita dapat menggunakannya. Anda perlu menyesuaikan setiap kode yang masuk ke aplikasi. Setiap masukan. Setiap kesimpulan. Setiap API. Kami mendorong linker ke adaptor dan membungkusnya di pabrik berbasis layanan. Tapi riasan berapa pun tidak akan membuat pola desain Anda terlihat cantik .
Ini seperti kita sedang membangun perangkat lunak di abad ke-18. Kami secara manual melihat pepohonan menjadi papan dengan berbagai ukuran. Kami membuat palu dan melubangi paku dari awal hanya untuk membangun rumah yang terlihat persis seperti rumah berikutnya. Biayanya terlalu mahal dan terlalu lama. Bahkan setelah proyek selesai, kami masih tersungkur oleh beban pendukung. Dimensinya tidak standar, pemasangan kabelnya mengejutkan tukang listrik, dan tukang yang baru saja lulus dari sekolah kejuruan tidak menyukai cara kami membuat paku. Sudah saatnya Leroy-Merlin dan digital 2x4 muncul di dunia software.
“Hai, nama saya Tim. Saya bekerja sebagai pimpinan teknologi di Google, memiliki pengalaman coding selama 30 tahun, tetapi harus mencari tahu cara mendapatkan panjang string dengan Python. "
Untuk bantuan dengan API apa pun agar terus mencari Anda secara pribadi ?
Tidaklah mengherankan jika saya mengatakan bahwa kita dapat memiliki standar yang cukup baik untuk semua orang. Microsoft memperkenalkan teknologi COM di tahun 90-an untuk bertukar logika antara aplikasi yang ditulis dalam bahasa apa pun. Teknologi JVM hampir seumuran, dan telah mendemonstrasikan berapa banyak bahasa yang dapat menangani bytecode yang sama dan juga berinteraksi satu sama lain. Dunia terus menemukan kembali Flow selama beberapa dekade dan Linda sebagai cara untuk menghubungkan kotak hitam yang didistribusikan satu sama lain, dan Docker adalah cara baru untuk melihat seperti apa kotak hitam modern.
Masalah ini menghadirkan banyak kemungkinan, dan banyak yang mencoba menyelesaikannya. Dapr dan WasmCloud terlihat menjanjikan solusi baru ... Mereka menyelesaikan sebagian masalah dengan cara yang berbeda. Betapa menyedihkan keadaan pengembangan perangkat lunak saat ini, saya memiliki lebih banyak harapan hari ini daripada 10 tahun terakhir. Periode singkat janji menarik ini datang dari JavaScript, yang berjanji untuk membuat platform universal tempat aplikasi amorf dapat menyebar ke seluruh dunia, tetapi sebagai hasilnya, itu berubah menjadi sekumpulan Electron, React, dan RAM yang terbuang percuma. Bagi saya, Web Assembly telah menjadi sumber optimisme baru. Ini jauh dari ideal, tetapi juga luar biasa. Cita-cita tidak pernah menang.
Periklanan
Apakah Anda mencari server untuk disewa untuk proyek debugging, server untuk pengembangan dan hosting? Anda pasti klien kami :) Penagihan harian server, buat konfigurasi Anda sendiri dalam beberapa klik, anti-DDoS sudah termasuk dalam harga.
Berlangganan obrolan kami di Telegram .
