Anti-pola yang Harus Anda Hindari dalam Kode Anda

Setiap pengembang ingin menulis kode yang terstruktur, terencana, dan dikomentari dengan baik. Bahkan ada banyak sekali pola desain yang memberi kita aturan yang jelas untuk diikuti, dan kerangka kerja yang perlu diingat.

Tetapi kami masih dapat menemukan anti-pola dalam perangkat lunak yang ditulis beberapa saat, atau ditulis terlalu cepat.

Peretasan dasar yang tidak berbahaya untuk menyelesaikan masalah dengan cepat dapat menjadi preseden dalam basis kode Anda. Ini dapat disalin di banyak tempat dan berubah menjadi anti-pola yang perlu Anda atasi.

Jadi, apa itu anti pola?

Dalam perangkat lunak, anti-pola adalah istilah yang menjelaskan bagaimana TIDAK memecahkan masalah yang berulang dalam kode Anda. Anti-pola dianggap desain perangkat lunak yang buruk, dan biasanya perbaikan yang tidak efektif atau tidak jelas.  

Mereka umumnya juga menambahkan "hutang teknis" - yang merupakan kode yang harus Anda kembalikan dan perbaiki dengan benar nanti.

Enam anti pola yang akan saya bahas dalam artikel ini adalah Spaghetti Code , Golden Hammer , Boat Anchor , Dead Code , Proliferation of Code dan God Object .

Kode Spaghetti

Kode Spaghetti adalah anti-pola paling terkenal. Ini adalah kode dengan struktur sedikit ke nol.

Tidak ada yang modularised. Ada file acak yang berserakan di direktori acak. Seluruh aliran sulit untuk diikuti, dan benar-benar saling terkait (seperti spageti).

Biasanya, ini adalah masalah di mana seseorang tidak secara hati-hati memikirkan aliran program mereka sebelumnya dan baru saja memulai pengkodean.

Apa fungsinya ?! Saya tidak bisa mengikuti ini

image.png

Ini bukan hanya mimpi buruk pemeliharaan, tetapi juga hampir mustahil untuk menambahkan fungsionalitas baru.

Anda akan terus-menerus merusak barang, tidak memahami ruang lingkup perubahan Anda, atau memberikan perkiraan akurat untuk pekerjaan Anda karena tidak mungkin untuk meramalkan masalah yang tak terhitung jumlahnya yang muncul saat melakukan arkeologi / tebakan seperti itu.

Anda dapat membaca lebih lanjut di sini tentang anti-pola Kode Spaghetti .

Palu Emas

"Kurasa menggoda, jika satu-satunya alat yang kamu miliki adalah palu, untuk memperlakukan segala sesuatu seolah-olah itu paku." Abraham Maslow

Bayangkan sebuah skenario dengan saya: tim pengembang Anda sangat, sangat kompeten dalam arsitektur Hammer yang baru. Ini telah bekerja dengan sangat baik untuk semua rangkaian masalah Anda sebelumnya. Anda adalah tim arsitektur Hammer terkemuka di dunia.

Tapi sekarang, entah bagaimana, semuanya selalu berakhir menggunakan arsitektur ini. Sekrup kepala datar? Palu. Sekrup kepala Phillips? Palu. Anda membutuhkan kunci pas Allen? Tidak, jangan, palu.

Anda mulai menerapkan pendekatan arsitektural yang tidak cukup sesuai dengan apa yang Anda butuhkan tetapi menyelesaikan pekerjaan. Anda terlalu bergantung pada satu pola dan perlu mempelajari alat terbaik untuk pekerjaan terbaik.

Seluruh program Anda bisa berakhir dengan kinerja yang serius karena Anda mencoba men-ram sebuah persegi menjadi bentuk lingkaran. Anda tahu bahwa butuh waktu dua kali lebih lama untuk membuat kode, dan untuk menjalankan program menggunakan arsitektur palu untuk masalah ini, tetapi lebih mudah dan itulah yang membuat Anda nyaman.

Itu juga tidak terlalu bisa diprediksi. Bahasa yang berbeda memiliki perbaikan yang sama untuk masalah yang mereka hadapi, dan standarnya sendiri. Anda tidak dapat menerapkan setiap aturan yang bekerja dengan baik untuk Anda dalam satu bahasa ke bahasa berikutnya, tanpa masalah.

Jangan mengabaikan pembelajaran yang konsisten dalam karir Anda. Pilih bahasa yang tepat untuk masalah Anda. Pikirkan tentang arsitekturnya, dan keluarkan zona nyaman Anda. Teliti dan selidiki alat baru dan cara baru untuk mendekati masalah yang Anda hadapi.

Anda dapat membaca lebih lanjut di sini tentang anti-pola Palu Emas .

Jangkar Kapal

The Boat jangkar anti-pola di mana programmer meninggalkan kode dalam basis kode karena mereka mungkin membutuhkannya nanti.

Mereka mengkodekan sesuatu yang sedikit keluar dari spesifikasi dan itu belum diperlukan, tetapi mereka yakin mereka akan melakukannya bulan depan. Jadi mereka tidak mau menghapusnya. Kirimkan ke produksi dan nanti saat mereka membutuhkannya, mereka dapat dengan cepat membuatnya berfungsi.

Namun hal ini menyebabkan mimpi buruk dalam pemeliharaan dalam basis kode yang berisi semua kode yang sudah usang itu. Masalah besarnya adalah bahwa kolega mereka akan kesulitan menentukan kode apa yang sudah usang dan tidak mengubah alur, versus kode yang mengubahnya.

Bayangkan Anda sedang dalam perbaikan, dan mati-matian mencoba mencari tahu apa yang bertanggung jawab untuk mengirimkan detail kartu pelanggan ke API untuk menarik dana dari bank mereka. Anda dapat membuang waktu membaca dan men-debug kode yang sudah usang, tanpa menyadari bahwa Anda bahkan tidak berada di tempat yang tepat di basis kode.

Masalah terakhir adalah, kode yang tidak terpakai membuat waktu pembuatan Anda lebih lama dan Anda dapat mencampur kode yang berfungsi dan yang sudah usang. Anda bahkan dapat mulai secara tidak sengaja "mengaktifkannya" dalam produksi.

Sekarang Anda mungkin dapat melihat mengapa ini disebut anti-pola jangkar kapal - berat untuk dibawa (menambah hutang teknis) tetapi tidak melakukan apa-apa (secara harfiah, kode tidak memiliki tujuan, tidak berfungsi).

Anda dapat membaca lebih lanjut di sini tentang Anti-pola jangkar perahu .

Kode mati

Pernahkah Anda melihat kode yang ditulis oleh seseorang yang tidak lagi bekerja di perusahaan Anda? Ada fungsi yang sepertinya tidak melakukan apa pun. Tapi dipanggil dari mana-mana! Anda bertanya-tanya dan tidak ada orang yang yakin apa yang dilakukannya, tetapi semua orang terlalu khawatir untuk menghapusnya.

Terkadang Anda dapat melihat apa yang dilakukannya, tetapi konteksnya hilang. Anda dapat membaca dan memahami alirannya, tetapi mengapa? Sepertinya kita tidak perlu mencapai titik akhir itu lagi. Respon selalu respon yang sama untuk setiap pengguna yang berbeda.

This is commonly described as the Dead code anti-pattern. When you can't see what is "actual" code necessary to the flow and successful execution of your program, versus what was only needed 3 years ago, and not now.

This particular anti-pattern is more common in proof on concept or research code that ended up in production.

One time at a tech meet up I met a guy who had this exact problem. He had tons of dead code, which he knew was dead, and lots he suspected was dead. But he could not get permission from management to ever remove all the dead code.

He referred to his approach as Monkey testing, where he started to comment out and turn off things to see what blew up in production. Maybe a little too risky!

If you don't fancy Monkey testing your production app, try to frame technical debt to management as "technical risk" to better explain why you think it's so important to tidy up.

Or even write down everything your particular module/section does you want to re-write, and take an iterative approach to remove piece by piece the dead code. Checking every time you haven't broken anything.

You don't have to drop a huge rewrite with thousands of changes. But you will either understand why it's so crucial and document why it's needed, or delete the dead code as you desired.

You can read more here about the Dead code anti-pattern.

Proliferation of Code

Objects or modules regularly communicate with others. If you have a clean, modularised codebase you often will need to call into other separate modules and call new functions.

The Proliferation of Code anti-pattern is when you have objects in your codebase that only exist to invoke another more important object. Its purpose is only as a middleman.

This adds an unnecessary level of abstraction (adds something that you have to remember) and serves no purpose, other than to confuse people who need to understand the flow and execution of your codebase.

A simple fix here is to just remove it. Move the responsibility of invoking the object you really want to the calling object.

You can read more here about the Proliferation of Code anti-pattern.

God Object

If everywhere in your codebase needs access to one object, it might be a God object.

God objects do too much. They are responsible for the user id, the transaction id, the customer's first and last name, the total sum of the transaction, the item/s the user is purchasing...you get the picture.

It is sometimes called the Swiss Army Knife anti-pattern because you only really need it to cut some twine, but it also can be a nail file, saw, pair of tweezers, scissors, bottle opener and a cork screw too.

In this instance you need to separate out and modularise your code better.

Programmers often compare this problem to asking for a banana, but receiving a gorilla holding a banana. You got what you asked for, but more than what you need.

The SOLID principles explicitly discuss this in object orientated languages, to help us model our software better (if you don't know what the SOLID principles are, you can read this article).

The S in the acronym stands for Single Responsibility - every class/module/function should have responsibility over one part of the system, not multiple.

You can see this problem over and over again, how about the below interface?

interface Animal { numOfLegs: string; weight: number; engine: string; model: string; sound: string; claws: boolean; wingspan: string; customerId: string; } 

Can you see by even just briefly scanning this interface that the responsibility of this is far too broad, and needs refactoring? Whatever implements this has the potential to be a God object.

How about this?

 interface Animal { numOfLegs: string; weight: number; sound: string; claws: boolean; } interface Car { engine: string; model: string; } interface Bird { wingspan: string; } interface Transaction { customerId: string; } 

Interface segregation will keep your code clear about where the responsibilities lie, and stop forcing classes that only need wingspan to also implement the engine, customerId and model  and so on.

Anda dapat membaca lebih lanjut di sini tentang anti-pola objek Tuhan .

Kesimpulan

Dalam basis kode besar mana pun, ada keseimbangan yang konstan antara mengelola utang teknis, memulai pengembangan baru, dan mengelola antrean bug untuk produk Anda.

Saya harap artikel ini memberi Anda perhatian untuk melihat kapan Anda mungkin akan menyusuri lubang kelinci dari anti-pola, dan beberapa alat untuk menyelesaikannya dengan bersih.

Saya membagikan tulisan saya di Twitter jika Anda menikmati artikel ini, dan ingin melihat lebih banyak.