Ada 3 masalah kode yang Anda temui dalam pemrograman: Hardcode, Govnokod dan Schizokod.
Mari kita bicarakan.
Hardcode
Ini adalah masalah yang terkenal ketika seorang programmer, karena terburu-buru atau malas, menulis kode tanpa memperhatikan variabel. Mungkin kasus yang paling umum adalah domain situs tersebut. Ini dapat bervariasi dari satu lingkungan ke lingkungan lain dan seringkali menyebabkan banyak masalah. Semuanya sederhana di sini. Dalam platform yang berbeda, ini diselesaikan dengan cara yang berbeda. Hal utama adalah mematuhi perjanjian dan aturan yang diadopsi dalam platform.
Biasanya, masalah kelas ini terdeteksi dengan cepat dan mudah diobati.
Govnokod
Ini adalah masalah yang lebih sulit. Seringkali subyektif. Secara kasar, ini merupakan pelanggaran terhadap gaya kode yang diadopsi di kepala, tim atau komunitas.
Ada berbagai gaya kode tergantung pada platform dan bahkan terkadang di dalam platform:
Ini dari dunia php. Di komunitas lain, situasinya serupa. Ini juga termasuk cerita tentang tab, tab setelah 2 spasi atau tab setelah 4 spasi, dll.
Di sini masalah kode murni muncul ... misalnya, fungsi panjang 3-4 halaman, yang dikritik. Ini tidak selalu tentu buruk, tetapi sering kali dimungkinkan untuk membuat fungsi yang lebih pendek, untuk membaginya menjadi serangkaian fungsi pendek, yang masing-masing memecahkan masalahnya sendiri.
Biasanya, masalah ini mudah ditangani melalui perangkat lunak dan kontrol standar yang diterima dalam tim tertentu.
Aerobatik, ketika pengembang dapat beralih di antara berbagai gaya kode tergantung pada proyek.
Adalah buruk ketika pengembang melanggar gaya kode yang diadopsi oleh tim atau menganggap gaya kode favoritnya (sering kali hanya dipelajari) satu-satunya yang benar.
Tidak ada gaya kode yang tepat. Ada gaya yang disetujui dalam tim atau gaya yang diterima secara umum.
Juga masalah yang relatif sederhana dan mudah diselesaikan.
Skizatode
Ini adalah masalah yang kurang populer, tetapi seringkali yang paling mahal.
Skizkode - berasal dari konsep skizofrenia. Peras dari Wikipedia:
Schizophrenia (dari bahasa Yunani lainnya: σχίζω “split”, “split” + φρήν - “mind, thinking, think”), sebelumnya lat. demensia praecox ("demensia prematur") atau skizofrenia adalah kelainan mental polimorfik endogen atau sekelompok kelainan mental yang terkait dengan gangguan proses berpikir dan reaksi emosional.
Ada 2 poin penting: pemisahan dan demensia. Yang merupakan penyebab skizocode.
Kode ideal adalah kode yang tidak tertulis. Schizocoders tidak terbiasa dengan konsep ini.
Singkatnya, skizocode adalah kode yang melanggar prinsip Razor Occam.
Peras dari Wikipedia:
"Occam's razor (blade)" adalah prinsip metodologis, dinamai setelah biarawan Inggris Franciscan, filsuf nominal William Ockham. Dalam bentuk yang disederhanakan, bunyinya: "Anda tidak boleh melipatgandakan keberadaan tanpa perlu"
Ini dinyatakan dalam kenyataan bahwa pengembang mulai memperumit kode dan arsitektur tanpa alasan yang baik. Atau bobot alasan hanya ada dalam imajinasi mereka.
Masalah imajiner - akar dari perangkat lunak yang buruk
Ada 2 gejala utama: penemuan sepeda pada kruk dan penggandaan lapisan abstraksi.
Penemuan sepeda pada kruk
Diungkapkan bahwa pengembang, mengingat kemampuannya yang buruk untuk belajar, alih-alih mencari solusi / metode yang optimal dalam kerangka platform dan arsitektur yang ada, mulai menciptakan sepeda / kruk.
Contoh:
- Menulis kerangka CMS / ptm Anda sendiri yang sudah ada memiliki kesalahan fatal
- Blog Symfony Terlepas dari kenyataan bahwa seluruh dunia menggunakan WordPress untuk ini.
- Toko online di Laravel, terlepas dari kenyataan bahwa ada WooCommerce (No. 1 di dunia), Magento (juga bagus), 1C-Bitrix (paling buruk, lebih baik daripada Laravel)
- Saya bertemu situasi ketika tata letak ada di Bootstrap, tetapi pengembang memutuskan untuk menulis gayanya sendiri untuk label. Apa yang mencegah Anda menambahkan kelas label yang sudah dimiliki Bootstrap?
- Fungsi, metode, dan kelas yang berlebihan tidak memiliki kalkulus yang dapat dihindari dengan menggunakan perpustakaan dan metode yang sudah jadi di platform yang digunakan
Perambatan lapisan abstraksi yang tidak terkontrol: kelas tambahan, pewarisan, metode
Pembaca yang penuh perhatian dapat melihat konflik dengan govnokod. Dalam satu kasus, masalahnya adalah bahwa fungsi atau kelas terlalu panjang, tetapi masalahnya adalah sebaliknya ada fragmentasi entitas yang berlebihan.
Di sini perlu dicatat bahwa ini adalah salah satu yang ekstrem, yang perbatasannya tidak selalu mudah untuk diamati.
Di satu sisi, itu buruk untuk mencoba menyelesaikan semuanya dengan satu fungsi pada 3 halaman atau kelas yang berisi HTML dan mekanisme templat dan di suatu tempat itu lebih menguntungkan untuk memecah kode menjadi beberapa fungsi / kelas / komponen, yang masing-masing memecahkan masalahnya sendiri. Ini salah satu yang ekstrem.
Di sisi lain, kode yang sangat sederhana dibagi menjadi 5 kelas, masing-masing memiliki 3-4 metode 3-4 baris, dengan banyak warisan yang tidak berguna, ketika Anda dapat melakukan satu atau dua dengan warisan minimal atau bahkan tanpa warisan jika ini dapat dihindari.
Konsekuensi abstraksi berlebihan dan buruk
Propagasi metode, kelas, pewarisan tanpa alasan yang baik - ini adalah kode yang berlebihan dan pertumbuhan lapisan abstraksi.
Semuanya memiliki harga, serta abstraksi tambahan:
- pelatihan pengembang baru dimanjakan
- semakin banyak kode, semakin banyak poin kegagalan, semakin banyak kesalahan
- diagnostik dan debugging kode rumit
Masalah pemikiran
Semakin banyak lapisan abstraksi, warisan, metode, semakin banyak bahan bakar yang dibutuhkan untuk perubahan, peningkatan, dan diagnostik masalah.
Dan volume kerja bahan bakar terbatas dan seringkali kekurangannya memerlukan biaya pengembangan yang sangat besar.
Setiap pengembang yang melakukan diagnosa dan mengubah skizocode bertumpu pada kekurangan bahan bakar pemikiran. Tetapi tidak semua orang menyadari hal ini.
Sebuah video yang menjelaskan apa yang dipikirkan bahan bakar dan memberikan latihan sederhana selama 1 menit, yang memungkinkan Anda mengingat kembali perasaan kekurangan bahan bakar pada contoh sederhana:
Apakah itu berjalan ke OOP, kelas, dan warisan?
Tidak semuanya. Namun, ada beberapa kebenaran dalam hal ini. Dalam gaya fungsional, lebih mudah untuk novokovodit, tetapi skema skiz sulit di sana. OOP, di satu sisi, memberikan banyak keuntungan, tetapi juga membuka ruang lingkup untuk skizocode.
OOP, kelas, dan warisan tidak buruk dan tidak baik. Ini adalah alatnya. Saya pribadi menggunakannya.
Namun, saya memiliki sejumlah aturan sendiri:
- Saya hampir selalu menulis kelas karena enkapsulasi, tetapi seringkali saya memiliki cukup Singleton, metode statis dan stateless
- Di mana ada metode yang umum digunakan, saya menulis fungsi yang sering hanya pembungkus untuk metode kelas, tetapi kadang-kadang fungsi hanyalah fungsi tanpa kelas dan ini bagus jika sesuai.
- Kelas Stateful - ya, tetapi jarang dan lagi hanya di mana ada alasan bagus
- Warisan bahkan lebih jarang, dan hanya jika ada alasan bagus untuk itu (saya mencoba mengurangi lapisan abstraksi dan menghemat pemikiran dan bahan bakar dalam sebuah tim)
Ringkasan
Kami berbicara banyak tentang hardcode dan govnokode karena mereka dimengerti dan mudah berwujud. Tetapi skizocode sering tidak dihukum, karena lebih sulit untuk mengidentifikasi dan memahami jumlah kerugian dari itu. Dan jumlah kerusakan dari itu mungkin lebih dari yang bisa dibayangkan dengan cepat.
Manifes saya sederhana:
- yang terbaik adalah mempelajari prinsip Best of breed sebelum menemukan sepeda kruk lain yang tidak dibutuhkan siapa pun
- mari kita menulis skizokode lebih sedikit
- mari kita belajar untuk mematuhi prinsip Razor Occam dan tidak mempersulit kode tanpa alasan
- mari selamatkan pikiran dan tim kita
Baiklah, saya akan dengan senang hati berkomentar baik dalam mendukung manifesto dan kritiknya.