Selamat siang, saya telah melakukan pemrograman selama 8 tahun, dan pemrograman dalam semua manifestasinya: mengembangkan sisi server dalam berbagai bahasa pemrograman, mengembangkan sisi klien, pemrograman jaringan, mengelola linux, dan mengoptimalkan kinerja. Dan ketika Anda telah sibuk dengan bisnis untuk waktu yang lama, sungguh-sungguh menyukainya dan berusaha untuk pengembangan diri, maka berbagai hubungan sebab akibat di bidang terkait mulai muncul, Anda mulai melihat hubungan yang sebelumnya tidak Anda ketahui sebelumnya atau hanya menganggapnya tidak penting, inilah yang orang sebut pengalaman.
Dan ini adalah tentang salah satu hubungan kausal yang ingin saya bagikan dengan Anda dalam artikel ini. Saya berpikir untuk menulis bahwa ini adalah salah satu hubungan sebab-akibat yang paling penting agar menjadi sedikit kurang radikal, tetapi masih belum, hubungan sebab-akibat ini adalah hubungan sebab-akibat yang paling penting dalam pemrograman dengan margin yang sangat besar. Ini berjalan seperti utas melalui semua bidang pemrograman: menulis kode, merancang antarmuka, menyebarkan aplikasi, mengatur tim, memelihara pelacak bug, dan sebagainya. Dan saya menyebut hubungan kausal yang sakral ini sebagai
minimalisasi variabel .
Dengan istilah variabel yang saya maksud tidak hanya variabel biasa (yang dideklarasikan melalui
var ,
biarkan ,
berfungsi kata kunci), tetapi juga variabel dalam arti yang lebih abstrak dari kata: folder yang dibuat di pohon proyek, perpustakaan terhubung, jumlah panggilan ajax ke server, nomor komponen dalam antarmuka, jumlah protokol yang harus diikuti oleh programmer ketika melakukan kode (misalnya, tinjauan kode, setiap fitur dalam brunch terpisah) dan sebagainya.
Bahkan, seluruh proses pemrograman adalah enumerasi varietas ke arah bagaimana menerapkan ini atau itu fungsional menggunakan jumlah minimum variabel yang mungkin (setidaknya saya melihat pemrograman dari perspektif itu). Kode yang mengimplementasikan fitur dengan lebih sedikit dependensi / file / baris kode lebih baik daripada kode yang mengimplementasikan fungsi yang sama dengan sejumlah besar variabel. Jika kelas utilitas hanya berisi satu fungsi - Anda harus menyingkirkan kelas utilitas ini, jika fungsi hanya terdiri dari satu baris - Anda harus menyingkirkan fungsi ini jika hanya ada 10 baris kode dalam komponen - Anda perlu menghapus komponen ini jika hanya ada satu file di folder - Anda harus menyingkirkan folder ini, dan sebagainya. Dan ketika beberapa ribu dari perubahan yang tampaknya tidak signifikan ini ditambahkan bersamaan, hasilnya adalah kode yang indah, ringkas dan minimalis yang sangat mudah dibaca. Iblis ada dalam perincian seperti yang mereka katakan.
Berikut adalah daftar efek positif yang muncul ketika Anda memulai pemrograman berdasarkan prinsip meminimalkan variabel:
- Lebih sedikit bug. Karena lebih sedikit kode yang ditulis, jumlah tempat di mana Anda dapat membuat kesalahan berkurang.
- Lebih mudah untuk memperkenalkan orang baru ke proyek. Kompleksitas proyek berbanding lurus dengan jumlah variabel dalam proyek ini, semakin sedikit variabel, semakin mudah untuk memperkenalkan orang baru.
- Lebih mudah untuk menambahkan fungsionalitas baru. Karena perlu mempelajari jumlah kode yang lebih kecil, menjadi lebih mudah untuk "memuat" fungsional ke dalam head, dan sebagai hasilnya menambah fungsionalitas baru atau memodifikasi kode yang ada.
- Prediktabilitas. Proses pemrograman menjadi jauh lebih mudah diprediksi, menjadi lebih mudah bagi Anda untuk memperkirakan berapa lama waktu yang dibutuhkan untuk mengembangkan satu fitur atau yang lain karena fakta bahwa jumlah "lelucon" berkurang. Biasanya, itu adalah colokan yang menyebabkan jumlah terbesar masalah, dan menyebabkan keterlambatan tenggat waktu.
Tetapi sangat sering situasi yang berlawanan terjadi, programmer mulai menegaskan diri dengan memperkenalkan variabel baru. Kami memperkenalkan 20 pustaka yang berbeda, kerangka kerja CSS, membuat sejumlah besar abstraksi multi-level seperti
UserFactoryManager (terutama programmer Java berdosa karena suatu alasan), membuat terlalu banyak direktori, memperkenalkan metodologi pengembangan yang lebih maju, menambahkan lebih banyak protokol sebelum melakukan file, dan sebagainya. Dan motivasi di balik keputusan semacam itu dapat dipahami, karena itu menciptakan ilusi profesionalisme, kata mereka lihat seberapa banyak yang saya tahu, dan abstraksi kompleks apa yang dapat saya tangani. Tetapi seringkali hal ini menyebabkan kerusakan yang parah pada proyek.
Jangan salah paham, saya tidak menentang penggunaan metodologi, kerangka kerja, dan teknologi yang lebih maju, saya hanya mengatakan bahwa mereka sangat sering diperkenalkan hanya karena hype, dan bukan karena teknologi ini menyelesaikan masalah mendesak dalam proyek.
Solusi untuk masalah jumlah variabel yang terlalu banyak dapat disebut
Overengineering . Tetapi Anda harus mengakui bahwa jika Anda menggambarkan situasi ini seolah-olah masalahnya sedang dipecahkan oleh terlalu banyak variabel, ini adalah deskripsi yang jauh lebih akurat dari fenomena ini.
Seringkali, pengenalan variabel baru dibenarkan oleh skalabilitas, kata mereka jika Anda membuat
UserManagerFactory di sini , maka kita dapat mengambil dan menambahkan fungsi kapan saja jika perlu. Namun dalam kenyataannya, skalabilitas bukan ketika banyak variabel diperkenalkan, melainkan ketika ada beberapa variabel. Pikirkan di mana akan lebih mudah bagi Anda untuk menulis fungsionalitas baru: di mesin browser chrome atau dalam proyek yang sama sekali baru yang Anda tulis dari awal?
Pengenalan variabel baru tidak mengarah pada skalabilitas arsitektur. Yang benar-benar meningkatkan skalabilitas proyek adalah ketika Anda menghapus variabel yang tidak perlu dan menyederhanakan kode yang ada.
Sejumlah besar variabel yang tidak perlu - ini adalah alasan mengapa saya membenci bahasa pemrograman Scala dengan kebencian yang hebat, dan alasan saya suka JavaScript. Scala hanyalah intisari dari sistem tipe yang terlalu rumit dan sangat membingungkan, banyak konsep yang saling menduplikasi, konversi tersirat, sejumlah besar cara untuk melakukan hal yang sama. Ketika saya menggunakan bahasa pemrograman ini, saya pikir bukan tentang
apa yang perlu dilakukan, tetapi tentang
bagaimana melakukannya. Saya sangat sering menemukan diri saya sekarang, tujuan saya hanya untuk menutup kompiler. Di sisi lain, JavaScript adalah kebalikan dari Scala, ini adalah urutan besarnya lebih minimalis, menggunakannya Saya menghabiskan jauh lebih sedikit upaya mental untuk mengekspresikan satu atau konsep lain. Tentu saja, kesederhanaan ini juga memiliki kekurangannya, misalnya, di Scala, kompiler melaporkan kesalahan pada tahap kompilasi, sedangkan di JavaScript Anda hanya dapat mengenali kesalahan dalam runtime dan pada dasarnya mustahil bagi JavaScript untuk menulis IDE fungsional yang sama seperti untuk yang diketik dengan kuat bahasa, tetapi ini adalah korban dengan siapa saya siap berdamai.
Prinsip meminimalkan variabel perlu diterapkan ketika merancang antarmuka, misalnya, mari kita bandingkan antarmuka web untuk dua jejaring sosial yang bersaing untuk berkencan dengan
Tinder dan
Badoo . Bahkan, hanya ada satu halaman di antarmuka web Tinder, profil pengguna, obrolan aktif dan pencarian kenalan baru ditampilkan pada satu halaman dan tidak perlu beralih ke halaman lain, dalam antarmuka ini semua kebutuhan pengguna dipenuhi oleh jumlah minimum komponen. Sementara di Badoo fungsionalitas beralih ke profil pengguna, antarmuka pesan dan halaman untuk menemukan pasangan diimplementasikan sebagai halaman terpisah, pengguna perlu melakukan lebih banyak tindakan untuk memenuhi kebutuhan, dan karenanya antarmuka ini kurang efisien. Tentu saja, ini hanya satu contoh yang sangat kecil, tetapi ketika ada puluhan dan ratusan contoh seperti itu, mereka bersama-sama menentukan apakah antarmuka dipikirkan atau tidak.
Saat mendesain antarmuka, perlu untuk membuat sejumlah komponen minimum untuk memenuhi kebutuhan pengguna.Untuk alasan yang sama, saya benar-benar tidak suka pendekatan yang memisahkan logika, data, dan presentasi, karena dalam kasus ini muncul situasi di mana untuk menulis satu fungsi Anda perlu membuat tiga file, maka jumlah komponen mulai tumbuh, dan ketika proyek sudah menjadi besar, kemudian jumlah file mulai berguling semua batas yang masuk akal. Misalnya, saat menulis antarmuka web, gaya biasanya dijelaskan dalam file terpisah, sedangkan node yang melampirkan gaya ini berada di file lain. Anehnya, motivasi utama pemisahan semacam itu adalah penskalaan, jadi jika Anda memisahkan simpul itu sendiri dan gayanya, maka akan menjadi lebih mudah untuk dinavigasi dalam proyek, dan akan mungkin untuk secara mandiri mengembangkan dua bagian fungsional ini. Tapi mari kita lihat variabel apa yang ditambahkan dengan pendekatan ini: file baru dengan gaya untuk setiap komponen, penyeleksi (mereka menggambarkan ke simpul mana gaya dilampirkan), aturan cascading (jika beberapa penyeleksi membahas simpul yang sama). Sementara jika Anda menulis gaya secara langsung di titik-titik di mana gaya-gaya ini harus terhubung (misalnya, melalui atribut gaya), maka semua variabel tambahan ini tidak lagi diperlukan, yang sangat menyederhanakan kode. Baru-baru ini, pendekatan ini menjadi semakin populer, ada banyak perpustakaan yang memungkinkan Anda untuk menulis gaya secara langsung di atribut gaya.
Variabel baru harus selalu dimasukkan ke dalam proyek secara bertahap. Misalnya, di awal, ketika menulis proyek, saya memiliki semua file di direktori root, tanpa subdirektori sama sekali, hanya karena lebih mudah, dan hanya ketika jumlah file bertambah menjadi 40-60 file, beberapa file dikelompokkan ke dalam direktori. Pada awalnya, tidak ada metodologi pengembangan yang dibutuhkan, cukup lemparkan semua programmer ke dalam tumpukan, berikan mereka tugas, maka mereka akan mengetahuinya sendiri, jika metodologi pengembangan diperkenalkan terlalu dini, itu akan terasa seperti semacam konsep pengganti. Ketika variabel diperkenalkan sebelum dibutuhkan, ini disebut optimasi prematur.
Dengan cara yang sama, perlu untuk meminimalkan variabel saat menulis dokumentasi / artikel, ketika saya menulis dokumentasi, saya selalu berpikir tentang apa sebenarnya jumlah minimum kalimat yang saya butuhkan untuk menyampaikan pikiran saya. Saya benar-benar menganalisis setiap kalimat, dan jika menurut saya kalimat ini tidak perlu, tidak menanggung beban semantik tambahan, maka itu dihapus, sebagai akibatnya halaman yang sangat terkompresi dengan dokumentasi diperoleh, yang berisi jumlah maksimum informasi yang diperlukan dalam jumlah minimum teks.
Faktanya, secara umum, setiap variabel memiliki anggapan bersalah, tidak ada variabel yang diperlukan sampai hal yang sebaliknya terbukti.
Anda dapat menolak saya, mereka mengatakan hal yang sama kepada saya, menemukan Amerika, telah lama dikenal dan dijelaskan oleh prinsip-prinsip seperti:
pisau cukur Okama ,
SOLID . Tetapi saya lebih suka menyebut konsep ini "minimalisasi variabel," hanya karena penafsiran ini sangat ringkas di kepala dan, karenanya, lebih mudah untuk tetap berpegang pada praktik. Berapa banyak dari Anda yang dapat membanggakan setiap poin dari prinsip SOLID?
Pemula menulis kode sederhana karena mereka tidak tahu cara menulis kode kompleks, rata-rata programmer menulis kode kompleks, hanya karena mereka dapat, para profesional menulis kode sederhana karena mereka tidak ingin menulis kode kompleks.
Harus diingat bahwa setiap ekstrem itu buruk: jika fanatik untuk meminimalkan variabel hingga level atom, maka pendekatan ini, serta memasukkan terlalu banyak variabel adalah ekstrem. Dan ekstrem apa pun, seperti yang Anda tahu, buruk, kebenaran selalu ada di antara keduanya.