Pembangunan Web 10 Pengekodan Antipatterns Anda Perlu Elakkan

Merancang seni bina laman web atau aplikasi, atau menubuhkan alur kerja pengekodan yang berkesan kerap membuat kita berurusan dengan masalah yang berulang. Kami tidak semestinya perlu menyelesaikan masalah reka bentuk perisian dari awal, seperti penyelesaian pada tahap seni bina boleh digunakan semula dengan cara yang sama seperti coretan kod di peringkat mikro.

Corak reka bentuk pada umumnya penyelesaian yang boleh diguna semula untuk senario tertentu, boleh berguna untuk menyelesaikan masalah yang sering berlaku, dan boleh membantu kami mengoptimumkan kod kami.

Walaupun corak reka bentuk adalah cara terbaik untuk memperbaiki proses pembangunan kami dengan menggunakan formula yang diuji dengan baik, kadang kala kita juga boleh salah dengannya. Ini disebut antipatterns.

Apa itu Antipatterns?

Istilah ini “antipattern” dicipta dalam sebuah buku yang dipanggil AntiPattern pada tahun 1998. Ia merujuk kepada penyelesaian yang digunakan semula pada mulanya kelihatan berguna, tetapi kemudian ternyata untuk melakukan lebih banyak mudarat daripada kebaikan.

Ini boleh berlaku atas sebab-sebab yang berbeza, contohnya jika kita tidak menggunakan corak dalam konteks, tetapan, atau masa yang betul (penyelesaian yang berkesan pada masa lalu mungkin tidak berfungsi pada masa ini), atau dalam kes lain paradigma keseluruhan hanya buruk dari permulaan.

Antipattern juga sering dipanggil corak kegagalan. Berita baiknya ialah ia mungkin untuk mengenali dan mengelakkannya.

Dalam post ini kita akan melihat 10 pengekodan biasa antipatterns dalam pembangunan web yang boleh menipu kita memikirkan kita mempunyai kod yang dioptimumkan dengan baik. (Perhatikan bahawa antipattern yang disenaraikan dalam siaran ini tidak semestinya sama dengan apa yang boleh anda dapati di dalam buku yang disebutkan di atas.)

1. Pengoptimuman awal

Masa yang baik adalah faktor penting dalam pengoptimuman kod. Kita boleh dengan mudah menghasilkan semula antipattern “pengoptimuman awal”, jika kita memberi perhatian kepada kecekapan kecil dan mengoptimumkan mereka terlalu awal dalam proses pembangunan, sebelum kita tahu apa yang ingin kita lakukan.

Mengikut kutipan terkenal Donald Knuth “Pengoptimuman awal adalah akar semua kejahatan“, yang mungkin melebih-lebihkan, tetapi masih menunjukkan betapa seriusnya isu pengoptimuman awal yang kemudiannya boleh menyebabkan.

Sekiranya kita mengoptimumkan prestasi sebelum membuat seni bina yang berkesan, kita boleh kebolehbacaan kod yang lebih rendah, buat debugging dan penyelenggaraan lebih keras, dan tambah bahagian yang berlebihan kepada kod kami.

Untuk mengelakkan pengoptimuman awal adalah idea yang baik untuk mengikuti YAGNI (Anda Tidak Benar) prinsip pengaturcaraan, yang menasihatkan untuk “sentiasa melaksanakan sesuatu apabila anda benar-benar memerlukannya, tidak pernah apabila anda meramalkan bahawa anda memerlukannya.”

2. Menetapkan semula roda

The “mencipta semula roda” antipattern kadang-kadang juga dirujuk sebagai “merancang dalam vakum”. Ia berlaku apabila kita mahu buat segalanya sendiri dan tulis semuanya dari awal, tanpa mencari kaedah sedia ada, API atau perpustakaan.

Menghidupkan semula roda bukan sekadar membuang masa untuk dilakukan, tetapi Penyelesaian khusus, terutamanya untuk fungsi asas, jarang sama dengan yang standard yang telah diuji oleh banyak pemaju dan pengguna.

3. Ketergantungan Neraka

Sebaliknya “mencipta semula roda” antipattern adalah satu lagi antipattern biasa yang dipanggil “kebergantungan neraka”.

Jika, bukannya menulis semua dari awal, kita gunakan terlalu banyak perpustakaan pihak ketiga yang bergantung pada versi tertentu perpustakaan lain, kita boleh dengan mudah menghadapi situasi yang tidak dapat diurus apabila kita ingin mengemaskini, kerana kebergantungan anak-anak syarikat ini dalam banyak kes tidak serasi dengan satu sama lain.

Pertahanan neraka boleh diselesaikan dengan menggunakan pengurus pakej yang mampu cerdas mengemaskini kebergantungan antara bergantung. Jika kita terlalu banyak masalah dengan masalah ini, refactoring juga boleh menjadi idea yang baik.

4. Kod Spaghetti

“Kod spageti” mungkin pengekodan yang paling terkenal antipattern. Ia menerangkan aplikasi yang sukar untuk debug atau mengubah suai kerana kekurangan seni bina yang betul.

Hasil dari reka bentuk perisian yang buruk adalah sekumpulan kod yang sama dalam struktur ke mangkuk spageti, yaitu. kusut dan kusut. Keterbacaan kod spaghetti sangat rendah, dan biasanya misi yang hampir mustahil untuk memahami bagaimana ia berfungsi dengan betul.

Kod spageti biasanya berasal dari kombinasi amalan pengkodan buruk yang berbeza, seperti kod yang tidak mengandungi blok konduktor yang betul, mempunyai banyak kenyataan goto, pengecualian, dan benang, yang mengandungi bahagian yang dimiliki di tempat lain, mempunyai hubungan yang minimum antara objek, mempunyai fungsi atau kaedah yang tidak dapat digunakan semula atau tidak didokumenkan dengan betul atau sama sekali.

5. Pemrograman mengikut Permutasi

“Pengaturcaraan dengan permutasi” atau “pengaturcaraan secara tidak sengaja” berlaku apabila kita cuba mencari penyelesaian untuk masalah dengan berturut-turut bereksperimen dengan pengubahsuaian kecil, menguji dan menilai mereka satu persatu, dan akhirnya melaksanakan satu yang berfungsi pada mulanya.

Pengaturcaraan dengan permutasi dengan mudah memperkenalkan pepijat baru ke dalam kod kami, Lebih teruk lagi, mereka adalah bug yang kita tidak semestinya mengenali sekaligus. Dalam banyak kes, juga mustahil untuk menjangka sama ada penyelesaian akan berfungsi untuk semua senario yang mungkin, atau tidak.

6. Copy and Paste Programming

“Salin dan tampal pengaturcaraan” berlaku apabila kita tidak mengikuti Prinsip pengekodan Jangan Ulangi sendiri (DRY), dan bukannya membuat penyelesaian generik, kami masukkan cuplikan kod sedia ada ke tempat yang berbeza, dan kemudian editnya agar sesuai dengan konteks yang diberikan.

Amalan ini menghasilkan kod yang sangat berulang, kerana bahagian kod yang dimasukkan biasanya berbeza hanya dalam percanggahan kecil.

Salin dan tampal pengaturcaraan bukan sahaja dilakukan oleh pemaju baru, tetapi juga pemrogram yang berpengalaman, kerana kebanyakan daripada mereka terdedah kepada menggunakan coretan kod pra-ditulis, yang diuji dengan baik untuk tugas tertentu, yang dengan mudah boleh membawa kepada ulangan yang tidak diingini.

7. Pengaturcaraan Cargo-Cult

Nama “pengaturcaraan kargo-kultus” berasal dari fenomena etnografi tertentu yang dipanggil “kultus kargo”. Kultus kargo muncul di Pasifik Selatan selepas Perang Dunia Kedua, apabila hubungan terpaksa dengan tamadun maju memimpin orang asli untuk berfikir bahawa produk yang dibuat seperti Coca-Cola, TV, dan peti sejuk yang dibawa oleh kapal-kapal kargo ke pulau-pulau, dicipta oleh ghaib kaedah; dan jika mereka melakukan upacara magis yang serupa dengan kebiasaan warga Barat, kargo yang penuh dengan barang akan datang lagi.

Apabila kita melakukan program pengaturcaraan kargo, kita pada dasarnya melakukan perkara yang sama. Kami menggunakan rangka kerja, perpustakaan, penyelesaian, corak reka bentuk, dan lain-lain yang berfungsi dengan baik untuk orang lain, tanpa memahami mengapa kita berbuat demikian, atau bagaimana teknologi berkata betul-betul berfungsi.

Dalam banyak kes pemaju hanya ritually melakukan apa yang hip pada masa itu tanpa apa-apa tujuan sebenar. Amalan ini bukan sahaja buruk kerana ia menjadikan aplikasi kami terlalu besar, tetapi ia juga boleh dengan mudah memperkenalkan pepijat baru ke dalam kod kami.

8. Lava Flow

Kami bercakap tentang “aliran lava” antipattern apabila kita perlu berurusan dengan kod yang mempunyai bahagian yang berlebihan atau berkualiti rendah itu seolah-olah menjadi penting untuk program ini, namun kita tidak sepenuhnya memahami apa yang dilakukannya atau bagaimana ia mempengaruhi keseluruhan aplikasi. Ini menjadikannya berisiko untuk membuangnya.

Ia biasanya berlaku dengan kod warisan, atau apabila kod telah ditulis oleh orang lain (biasanya tanpa dokumentasi yang betul), atau apabila projek bergerak pantas dari pembangunan ke fasa pengeluaran.

Nama antipattern berasal dari kemunculannya dengan lava yang berasal dari gunung berapi, iaitu pada awalnya ia bergerak dengan cepat dan curang tanpa mengambil langkah berjaga-jaga yang terlalu banyak, tetapi kemudiannya menguatkan dan menjadi sukar untuk menghapus.

Secara teori, kita boleh menyingkirkan aliran lava dengan ujian luas dan refactoring, tetapi dalam amalan, Pelaksanaannya sering sukar atau bahkan mustahil. Oleh kerana aliran lava biasanya mempunyai kos berprestasi tinggi, lebih baik menghalangnya dengan menubuhkan senibina yang direka dengan baik dan aliran kerja yang baik dari awal.

9. Pengekodan keras

“Pengekodan keras” adalah antipattern terkenal yang mana kebanyakan buku pembangunan web memberi amaran kepada kami tepat di muka surat. Pengekodan keras adalah amalan malang di mana kami menyimpan konfigurasi atau data input, seperti laluan fail atau nama hos jauh, dalam kod sumber bukannya mendapatkannya dari fail konfigurasi, pangkalan data, input pengguna, atau sumber luaran lain.

Masalah utama dengan kod keras ialah ia hanya berfungsi dengan betul dalam persekitaran tertentu, dan pada bila-bila masa keadaan berubah, kita perlu mengubah suai kod sumber, biasanya di beberapa tempat berasingan.

10. Pengekodan Lembut

Sekiranya kita berusaha keras untuk mengelakkan kejatuhan pengekodan keras, kita dapat dengan mudah berjalan ke antipattern lain yang dipanggil “pengekodan lembut”, yang bertentangan dengannya.

Dalam pengekodan lembut, kami meletakkan perkara-perkara yang sepatutnya di dalam kod sumber menjadi sumber luaran, contohnya kita menyimpan logik perniagaan dalam pangkalan data. Sebab yang paling umum mengapa kita berbuat demikian, adalah ketakutan bahawa peraturan perniagaan akan berubah di masa depan, oleh itu kita perlu menulis semula kod.

Dalam kes yang teruk, program berkod lembut boleh menjadi sangat abstrak dan berbelit-belit bahawa hampir mustahil untuk difahami (terutamanya untuk ahli pasukan baru), dan amat sukar untuk diselenggarakan dan debug.