Pengembangan Web 10 Antipattern Coding yang Harus Anda Hindari

Merancang arsitektur situs web atau aplikasi, atau mengatur alur kerja pengkodean yang efektif sering membuat kita berurusan dengan masalah yang berulang. Kami tidak perlu menyelesaikan masalah desain perangkat lunak ini dari awal solusi pada tingkat arsitektur dapat digunakan kembali dengan cara yang sama seperti cuplikan kode di tingkat mikro.

Pola desain umumnya solusi yang dapat digunakan kembali untuk skenario tertentu, itu bisa berguna untuk memecahkan masalah yang biasa terjadi, dan dapat sangat membantu kami mengoptimalkan kode kami.

Sementara pola desain adalah cara yang bagus untuk meningkatkan proses pengembangan kami dengan menggunakan formula yang teruji dengan baik, kadang-kadang kita juga bisa salah. Ini disebut antipatterns.

Apa itu Antipatterns?

Syarat “antipattern” diciptakan dalam sebuah buku berjudul AntiPatterns pada tahun 1998. Ini merujuk pada solusi yang digunakan kembali yang awalnya tampak bermanfaat, tapi kemudian ternyata melakukan lebih banyak kerusakan daripada kebaikan.

Ini dapat terjadi karena alasan yang berbeda, misalnya jika kita tidak menggunakan pola dalam konteks, pengaturan, atau waktu yang tepat (solusi yang efektif di masa lalu mungkin tidak selalu berfungsi di masa sekarang), atau dalam kasus lain seluruh paradigma hanya buruk dari awal.

Antipatterns juga sering disebut pola kegagalan. Berita baiknya adalah itu mungkin untuk mengenali dan menghindarinya.

Dalam posting ini kita akan melihat 10 antipattern coding umum dalam pengembangan web yang mungkin menipu kita untuk berpikir kita memiliki kode yang dioptimalkan dengan baik. (Perhatikan bahwa antipatterns yang tercantum dalam pos ini tidak harus sama dengan apa yang dapat Anda temukan dalam buku yang disebutkan di atas.)

1. Optimalisasi Prematur

Waktu yang baik adalah faktor penting dalam optimasi kode. Kita dapat dengan mudah mereproduksi antipattern dari “optimasi prematur”, jika kita memperhatikan efisiensi kecil dan mengoptimalkannya terlalu dini dalam proses pengembangan, sebelum kita tahu persis apa yang ingin kita lakukan.

Menurut kutipan terkenal Donald Knuth “optimasi prematur adalah akar dari semua kejahatan“, yang mungkin berlebihan, tetapi masih menunjukkan seberapa serius masalah optimasi dini dapat menyebabkan kemudian.

Jika kami mengoptimalkan kinerja sebelum menyiapkan arsitektur yang efektif, kami mungkin keterbacaan kode lebih rendah, membuat debugging dan pemeliharaan lebih sulit, dan tambahkan bagian yang berlebihan ke kode kami.

Untuk mencegah pengoptimalan prematur, sebaiknya mengikuti prinsip pemrograman YAGNI (Anda Tidak Akan Membutuhkannya), yang menyarankan untuk “selalu menerapkan hal-hal ketika Anda benar-benar membutuhkannya, tidak pernah ketika Anda hanya meramalkan bahwa Anda membutuhkannya.”

2. Menemukan Kembali Roda

Itu “menciptakan kembali roda” antipattern kadang-kadang juga disebut sebagai “mendesain dalam ruang hampa”. Itu terjadi ketika kita mau lakukan semuanya sendiri dan tulis semuanya dari awal, tanpa mencari metode, API, atau perpustakaan yang sudah ada.

Menemukan kembali roda bukan hanya membuang-buang waktu untuk dilakukan, tetapi solusi khusus, terutama untuk fungsi dasar, jarang sebagus yang standar yang telah diuji oleh banyak pengembang dan pengguna.

3. Ketergantungan Neraka

Kebalikan dari “menciptakan kembali roda” antipattern adalah antipattern umum yang disebut “neraka ketergantungan”.

Jika, alih-alih menulis semuanya dari awal, kami menggunakan terlalu banyak perpustakaan pihak ketiga yang bergantung pada versi spesifik dari perpustakaan lain, kita dapat dengan mudah mengalami situasi yang sulit dikelola ketika kita ingin memperbarui, karena dependensi anak perusahaan ini dalam banyak kasus tidak kompatibel satu sama lain.

Ketergantungan neraka dapat diatasi dengan menggunakan manajer paket yang mampu memperbarui dependensi yang saling tergantung secara cerdas. Jika kita kewalahan oleh masalah, refactoring juga bisa menjadi ide yang bagus.

4. Kode Spaghetti

“Kode spageti” mungkin adalah antipattern coding yang paling terkenal. Itu menggambarkan aplikasi yang sulit di-debug atau dimodifikasi karena kurangnya arsitektur yang tepat.

Hasil desain perangkat lunak yang buruk adalah sekelompok kode yang strukturnya hampir sama dengan semangkuk spageti, yaitu. kusut dan berbelit-belit. Keterbacaan kode spageti sangat rendah, dan biasanya merupakan misi yang hampir tidak mungkin untuk memahami cara kerjanya.

Kode spaghetti biasanya berasal dari kombinasi berbagai praktik pengkodean buruk yang berbeda, seperti kode yang tidak mengandung blok kondisional yang tepat, memiliki banyak pernyataan kebagian, pengecualian, dan utas, yang mengandung bagian-bagian yang dimiliki di tempat lain, memiliki hubungan minimal antara objek, memiliki fungsi atau metode yang tidak dapat digunakan kembali, atau tidak didokumentasikan dengan baik atau sama sekali.

5. Pemrograman dengan Permutasi

“Pemrograman dengan permutasi” atau “pemrograman secara tidak sengaja” terjadi ketika kami mencoba menemukan solusi untuk masalah dengan berturut-turut bereksperimen dengan modifikasi kecil, menguji dan menilai mereka satu per satu, dan akhirnya menerapkan yang berhasil pada awalnya.

Pemrograman dengan permutasi dapat dengan mudah perkenalkan bug baru ke dalam kode kami, lebih buruk lagi, itu adalah bug yang tidak perlu kita kenali sekaligus. Dalam banyak kasus, juga tidak mungkin untuk mengantisipasi apakah solusi akan bekerja untuk semua skenario yang mungkin, atau tidak.

6. Copy dan Paste Programming

“Salin dan tempel pemrograman” terjadi ketika kami tidak mengikuti prinsip pengkodean Jangan Ulangi Sendiri (KERING), dan alih-alih membuat solusi umum, kami menyisipkan potongan kode yang sudah ada ke tempat yang berbeda, dan kemudian mengeditnya agar sesuai dengan konteks yang diberikan.

Latihan ini menghasilkan kode yang sangat berulang, karena bagian kode yang dimasukkan biasanya berbeda hanya dalam perbedaan kecil.

Copy dan paste pemrograman tidak hanya dilakukan oleh pengembang pemula, tetapi juga programmer berpengalaman, karena banyak dari mereka cenderung menggunakan cuplikan kode pra-tertulis dan teruji dengan baik untuk tugas tertentu, yang dapat dengan mudah menyebabkan pengulangan yang tidak diinginkan.

7. Pemrograman Cargo-Cult

Nama “pemrograman kargo-kultus” berasal dari fenomena etnografi spesifik yang disebut “kultus kargo”. Kultus-kultus kargo muncul di Pasifik Selatan setelah Perang Dunia kedua, ketika kontak paksa dengan peradaban maju membuat penduduk asli berpikir bahwa produk-produk manufaktur, seperti Coca-Cola, TV, dan lemari es yang dibawa oleh kapal kargo ke pulau-pulau, diciptakan oleh supernatural metode; dan jika mereka melakukan ritual magis yang mirip dengan kebiasaan orang Barat, barang yang penuh dengan barang akan datang lagi.

Ketika kami melakukan antipattern dari pemrograman kargo-kultus, pada dasarnya kami melakukan hal yang sama. Kami menggunakan kerangka kerja, perpustakaan, solusi, pola desain, dll. Yang bekerja dengan baik untuk orang lain, tanpa mengerti mengapa kami melakukannya, atau bagaimana teknologi itu bekerja.

Dalam banyak kasus, pengembang hanya secara ritual melakukan apa yang pinggul pada waktu itu tanpa tujuan yang nyata. Praktik ini tidak hanya buruk karena membuat aplikasi kita membengkak secara berlebihan, tetapi juga dapat dengan mudah memasukkan bug baru ke dalam kode kita.

8. Aliran Lava

Kami berbicara tentang “aliran lava” antipattern ketika kita perlu berurusan dengan kode yang memiliki komponen yang berlebihan atau berkualitas rendah bahwa tampaknya tidak terpisahkan ke program, namun kami tidak sepenuhnya memahami apa yang dilakukannya atau bagaimana pengaruhnya terhadap keseluruhan aplikasi. Ini membuatnya berisiko untuk menghapusnya.

Ini biasanya terjadi dengan Kode Warisan, atau ketika kode ditulis oleh orang lain (biasanya tanpa dokumentasi yang tepat), atau ketika proyek bergerak terlalu cepat dari pengembangan ke tahap produksi.

Nama antipattern berasal dari ressemblance-nya dengan lava yang berasal dari gunung berapi, yaitu awalnya bergerak cepat dan lancar tanpa mengambil terlalu banyak tindakan pencegahan, tetapi kemudian ia membeku dan menjadi sulit untuk dihilangkan..

Secara teori, kita bisa membuang aliran lahar pengujian ekstensif dan refactoring, tetapi dalam praktiknya, implementasi seringkali sulit atau bahkan tidak mungkin. Karena aliran lava biasanya memiliki biaya kinerja tinggi, lebih baik untuk mencegahnya dengan menyiapkan arsitektur yang dirancang dengan baik dan alur kerja yang baik dari awal..

9. Hard Coding

“Pengodean keras” adalah antipattern yang terkenal terhadap mana kebanyakan buku pengembangan web memperingatkan kita tepat di kata pengantar. Hard coding adalah praktik yang tidak menguntungkan di mana kami menyimpan konfigurasi atau memasukkan data, seperti jalur file atau nama host jarak jauh, dalam kode sumber daripada memperolehnya dari file konfigurasi, database, input pengguna, atau sumber eksternal lain.

Masalah utama dengan kode keras adalah itu itu hanya berfungsi dengan baik di lingkungan tertentu, dan pada setiap saat kondisinya berubah, kita perlu memodifikasi kode sumber, biasanya di beberapa tempat terpisah.

10. Soft Coding

Jika kita berusaha sangat keras untuk menghindari perangkap dari pengkodean yang sulit, kita dapat dengan mudah mengalami antipattern lain yang disebut “pengkodean lunak”, yang merupakan kebalikannya.

Dalam soft coding, kami memasukkan hal-hal yang harus ada dalam kode sumber ke sumber eksternal, misalnya kita menyimpan logika bisnis dalam database. Alasan paling umum mengapa kita melakukannya, adalah ketakutan bahwa aturan bisnis akan berubah di masa depan, oleh karena itu kita perlu menulis ulang kode.

Dalam kasus ekstrim, program kode lunak dapat menjadi begitu abstrak dan berbelit-belit sehingga hampir mustahil untuk memahaminya (terutama untuk anggota tim baru), dan sangat sulit untuk mempertahankan dan men-debug.