Setiap programmer perlu mengetahui ini (atau clickbait yang kuat tentang coding slang)





YAGNI, KISS, DRY, BASAH, SLAP, ASAP, YOLO - apa artinya semua itu?



Ave, Coder! Jika Anda pernah membaca literatur pemrograman bahasa Inggris, mengambil kursus dalam bahasa Inggris, bekerja dengan sesama pembuat kode yang berbahasa Inggris, atau hanya berkorespondensi dengan mereka, Anda mungkin pernah menemukan singkatan ini dan ketika salah satu pembuat kode berjanggut mengatakan KISS kepada yang lain, saya jamin alis Anda setidaknya sedikit terangkat.



Pada artikel ini, kita akan menganalisis kata-kata ini, atau lebih tepatnya singkatan, yang populer di kalangan IT-shnik yang berbahasa Inggris. Visualnya di



sini: youtu.be/ub0YtnSwqRA







KISS ("Tetap sederhana, bodoh")



Ini bukanlah sebuah pola, bukan anti-pola atau bahkan sebuah band rock dari tahun tujuh puluhan, dalam hal ini, ini adalah salah satu prinsip atau pendekatan yang paling populer untuk memprogram apapun.



Padahal, prinsip ini mensyaratkan kode Anda sesederhana mungkin, karena tumpukan fungsi yang tidak perlu yang saling menduplikasi dan kebiasaan menggaruk telinga kiri dengan tangan kanan bukanlah pertanda seorang programmer profesional.



Semakin sederhana kodenya, semakin mudah untuk memahaminya, semakin kecil kemungkinan untuk membakar kursi di bawah orang yang akan mengambil kode ini setelah Anda.



Steve McConnell pernah berkata: "Tulis kode seolah-olah itu akan didukung oleh psikopat yang kejam yang tahu di mana Anda tinggal."

Karena itu, lebih baik sebenarnya tidak mempersulit hal-hal yang tidak membutuhkannya.







KERING ("Jangan ulangi diri sendiri")



Prinsip Don't Repeat Yourself sangat mirip dengan KISS. Ini cukup sederhana dan pada saat yang sama memiliki arti yang luas. Ini cukup sederhana dan pada saat yang sama memiliki arti yang luas - mengerti lelucon?



Menyalin dan menempel serta menggandakan fragmen kode Anda sendiri seperti skoliosis atau gangguan penglihatan - semua pemrogram menderita dari waktu ke waktu. Tidak ada yang salah. Setiap orang terkadang perlu dengan cepat memeriksa sesuatu (perilaku yang diharapkan atau sesuatu yang lain) untuk kemudian menentukan apakah pantas menulisnya dengan benar. Tetapi jelas tidak dapat diterima untuk mengirim kode seperti itu ke produksi.



KERING mengingatkan kita bahwa setiap perilaku berulang dalam kode dapat dan harus diambil kembali (misalnya, di dalam fungsi) untuk digunakan kembali nanti. Memiliki dua bagian kode yang sama dalam basis kode Anda bukanlah hal yang baik. Hal ini sering kali dapat menyebabkan desinkronisasi dan kesalahan lain dalam kode Anda, belum lagi peningkatan ukuran program.







WET ("Kami senang mengetik")



Solusi WET tersebar luas dalam arsitektur multi-tier di mana pengembang dapat ditugaskan, misalnya, menambahkan kolom komentar ke formulir dalam aplikasi web. String teks "komentar" dapat diulangi dalam label, tag HTML, nama fungsi baca, variabel pribadi, DDL database, kueri, dll. Pendekatan DRY menghilangkan redundansi ini dengan menggunakan kerangka kerja yang mengurangi atau menghilangkan semua kecuali tugas pengeditan yang paling penting, sambil membiarkan kemampuan untuk menambahkan variabel baru di satu tempat.







YAGNI ("Anda tidak akan membutuhkannya")



Anda tidak memerlukan ini - ini adalah prinsip yang mungkin bertentangan dengan pandangan beberapa programmer, serta mereka yang telah menambahkan desimeter ke dalam kurikulum sekolah.



Menjadi siap menghadapi masa depan umumnya bagus, tetapi tidak dalam pemrograman. Membiarkan kode apa pun yang ditujukan hanya untuk ekstensi di masa mendatang bukanlah masalah besar.



Tetapi jika Anda pada dasarnya adalah seorang cyber-plushkin dan dari pemikiran hanya menyisakan yang diperlukan, kursi di bawah gulungan Anda mulai meleleh, maka mari kita cari tahu - apakah ini pendekatan yang buruk untuk pemrograman atau apakah itu klinik dalam hidup?



Proyek pembuat kode bukanlah hal-hal yang memiliki akhir yang jelas. Kecuali penulis menyerah pada idenya (dan tidak menyebarkannya kepada orang lain), proyek pada dasarnya berlanjut. Oleh karena itu, ada dan akan selalu ada ruang untuk perbaikan, baik itu konsep, arsitektur, atau bahkan kode itu sendiri.

Itu satu hal - bagaimana kode yang ideal terlihat di kepala Anda - tanpa kesalahan dan kruk, itu hal lain - apa yang sebenarnya terjadi.

Secara alami, sedikit sentuhan kesedihan dan sikap apatis dapat memahami pembuat kode pada malam musim gugur yang dingin dan pembuat kode dapat memutuskan untuk memasukkan ke dalam program apa yang disebut "titik ekstensi" (tempat yang dirancang untuk dengan mudah memperhitungkan fungsi baru) jika tidak digunakan secara wajar atau bukan merupakan fungsi wajib kemudian hanya menjadi monumen penundaan dan menambahkan kerumitan serta ukuran yang tidak perlu ke basis kode. Kalau dipikir-pikir, itu malah bertentangan dengan prinsip KISS yang sudah dibahas sebelumnya.







SLAP ("Prinsip abstraksi tingkat tunggal")



The Single Layer of Abstraction Principle (SLAP) mendefinisikan bagaimana kita harus mengatur kode kita (fungsi harus spesifik) agar tetap dapat dipelihara.



Fungsi yang panjang dan kompleks sulit untuk dijalankan. Mereka sulit dipahami oleh pengembang lain dan sulit untuk diuji. Jika ada di jari kita, maka, begitu kita dihadapkan dengan kekejian seperti itu, kita harus segera mengubahnya menjadi beberapa fungsi kecil!



Seperti yang dikatakan Robert Martin, "Fungsi seharusnya hanya melakukan satu hal, dan mereka harus melakukannya dengan baik."



Tapi bagaimana tepatnya kita harus mengatur fungsi kita? Semakin Anda, teman berbulu saya, semakin berpengalaman dalam pemrograman, Anda akan mulai lebih memahami tentang aspek praktis, estetika dan fungsional dari pemrograman dan sebuah prinsip yang disebut SLAP yang dimaksudkan untuk membantu.



Secara kasar, fungsi Anda harus melakukan hanya satu hal, atau dengan kata SLAP lainnya, harus memiliki hanya satu tingkat abstraksi.



Pada dasarnya, fungsi yang membaca input pengguna, misalnya, juga tidak perlu memprosesnya. Sebagai gantinya, Anda perlu menggunakan fungsi terpisah yang berada di tingkat abstraksi yang lebih rendah. Semakin umum suatu fungsi dan semakin banyak fungsi lain yang digunakannya, semakin tinggi posisinya dalam hierarki abstraksi.







FOOBAR ("F **** d up melebihi semua pengakuan")



Untuk memparafrasekan dalam bahasa Rusia: "rusak sehingga tidak dapat dipulihkan".

Ini adalah ekspresi luar biasa yang datang ke IT dari bahasa gaul militer, bersama dengan mahakarya lainnya, seperti, misalnya, SNAFU - "Situation Normal - all fucked up"; Ini seperti: "situasinya sangat alami, tetapi semuanya sia-sia."

Legenda mengatakan bahwa programmer C menggunakan nama "foo" dan "bar" untuk variabel yang disebut "placeholder" atau placeholder, terutama dalam contoh tutorial. Jadi, kepala kecil mereka yang cerdas terbebas dari beban mencari nama baru dan bisa berkonsentrasi memecahkan masalah.

Seiring waktu, ini menjadi tradisi dan bermigrasi dari C ke banyak bahasa yang tidak terlalu kuno, jadi contoh nama tersebut dapat ditemukan di buku teks di mana-mana, dan kata "FooBar", diterapkan pada proyek, berarti Anda dapat mulai mencari sesuatu yang lain ...







ASAP ("Secepat mungkin")



"Secepatnya."

Baru-baru ini, telah menjadi tren "Secepat mungkin" - "secepat mungkin, tetapi dalam batas yang wajar."

Kata ini juga mulai digunakan dari bahasa gaul tentara selama Perang Dunia Pertama. Ini digunakan secara aktif hingga hari ini, jika akronim ini sering digunakan dalam korespondensi dengan atasan, maka ini dengan fasih dapat menunjukkan tingkat organisasi di perusahaan atau keterampilan manajemen dan kemampuan untuk memprioritaskan di antara para bos. Tetapi tentu saja ada pengecualian, ketika situasi menjadi tidak terkendali dan Foobar secara umum.







FYI ("Untuk informasi Anda")



Arti resminya adalah "Saya membawanya ke perhatian Anda", tetapi diterjemahkan secara longgar: "agar Anda tahu." Ini ditemukan dalam korespondensi email di mana-mana, terutama ketika korespondensi tidak dilakukan secara pribadi dengan Anda, di bawah sinar matahari yang cerah, tetapi, bagaimanapun, mereka memutuskan untuk memberi tahu Anda.







TL; DR ("Terlalu panjang; tidak membaca")



Analog dari "multi-huruf, neosilil" kami. Ini sering terlihat di bawah posting yang panjang, di mana penulis mengungkapkan jiwanya dan air mata dari selubungnya, tetapi pembaca terlalu malas untuk mempelajari karya ini.







DIY ("Lakukan sendiri")



Lakukan sendiri. Berasal dari nama toko konstruksi kecil yang menjual barang untuk memperbaiki rumah daripada membangunnya. Implikasinya adalah pekerjaan itu hal-hal kecil dan Anda bisa melakukannya sendiri, tanpa perlu mempekerjakan personel yang berkualifikasi.

Selanjutnya, konsep bermigrasi ke TI dan dapat sesuai, misalnya, dalam situasi di mana seorang spesialis perlu melakukan pekerjaan dari bidang terkait, tetapi sangat kecil dan sepele sehingga lebih mudah untuk melakukannya sendiri.







YOLO ("Kamu hanya hidup sekali")



"Kamu hanya hidup sekali." Dengan analogi dengan bahasa Latin "carpe diem" ("merebut momen"), ini adalah panggilan untuk hidup seutuhnya, bahkan untuk perilaku yang mungkin membawa risiko. Ini adalah argumen terakhir di perbatasan dengan pengalaman yang tidak masuk akal atau kesenangan yang tidak terkendali, tetapi terkadang argumen itu dapat membawa pesan yang lebih masuk akal: adalah bodoh membiarkan ketakutan mengatur keputusan Anda, karena Anda hanya hidup sekali.



Dan ingat, YOLO, ciuman. Itu adalah V. Sampai jumpa di saluran! Ave!



All Articles