Setiap pembangun ingin menulis kod berstruktur, terancang, dan dikomentari dengan baik. Bahkan terdapat sebilangan besar corak reka bentuk yang memberi kita peraturan yang jelas untuk diikuti, dan kerangka yang perlu diingat.

Tetapi kita masih boleh menemui anti-corak dalam perisian yang ditulis dalam beberapa waktu, atau ditulis terlalu cepat.

Peretasan asas yang tidak berbahaya untuk menyelesaikan masalah dengan cepat dapat menetapkan preseden dalam pangkalan data anda. Ia dapat disalin di beberapa tempat dan berubah menjadi pola anti yang perlu anda atasi.

Jadi apa itu anti-corak?

Dalam perisian, anti-pola adalah istilah yang menjelaskan bagaimana TIDAK menyelesaikan masalah berulang dalam kod anda. Anti-pola dianggap reka bentuk perisian yang tidak baik, dan biasanya tidak berkesan atau tidak jelas.  

Secara amnya mereka juga menambah "hutang teknikal" - kod yang harus anda kembalikan dan perbaiki dengan betul kemudian.

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

Kod Spaghetti

Spaghetti Code adalah anti-corak yang paling terkenal. Ini adalah kod dengan struktur sedikit hingga sifar.

Tidak ada yang modular. Terdapat fail rawak yang tersebar di direktori rawak. Seluruh aliran sukar diikuti, dan benar-benar terjerat bersama (seperti spageti).

Biasanya, ini adalah masalah di mana seseorang tidak memikirkan aliran program mereka terlebih dahulu dan baru memulakan pengekodan.

Apa yang dilakukannya ?! Saya tidak boleh mengikuti ini

Ini bukan hanya mimpi buruk penyelenggaraan, tetapi menjadikannya mustahil untuk menambahkan fungsi baru.

Anda akan terus menerus memecahkan sesuatu, tidak memahami ruang lingkup perubahan anda, atau memberikan anggaran yang tepat untuk kerja anda kerana mustahil untuk meramalkan masalah yang tidak terhitung jumlahnya yang muncul ketika melakukan arkeologi / tekaan tersebut.

Anda boleh membaca lebih lanjut di sini mengenai anti-corak Spaghetti Code .

Tukul Emas

"Saya rasa itu menggoda, jika satu-satunya alat yang anda miliki adalah tukul, untuk memperlakukan semuanya seolah-olah paku." Abraham Maslow

Bayangkan senario dengan saya: pasukan dev anda sangat cekap dalam seni bina Hammer yang baru. Ia telah berfungsi dengan hebat untuk semua masalah masa lalu anda. Anda adalah pasukan seni bina Hammer terkemuka di dunia.

Tetapi sekarang, entah bagaimana, semuanya selalu berakhir dengan menggunakan seni bina ini. Skru kepala rata? Tukul. Skru kepala Phillips? Tukul. Anda memerlukan sepana Allen? Tidak, jangan.

Anda mula untuk memohon pendekatan seni bina yang tidak agak sesuai apa yang anda perlukan tetapi mendapat pekerjaan yang dilakukan. Anda terlalu bergantung pada satu corak dan perlu mempelajari alat terbaik untuk pekerjaan terbaik.

Seluruh program anda akhirnya dapat membuat persembahan yang serius kerana anda cuba mengetatkan kotak menjadi bentuk bulatan. Anda tahu memerlukan dua kali lebih lama untuk membuat kod, dan untuk melaksanakan program menggunakan seni bina tukul untuk masalah ini, tetapi lebih mudah dan itulah yang anda selesa.

Ia juga tidak dapat diramalkan. Bahasa yang berbeza mempunyai penyelesaian umum terhadap masalah yang mereka hadapi, dan standard mereka sendiri. Anda tidak boleh menerapkan setiap peraturan yang sesuai untuk anda dalam satu bahasa ke bahasa yang lain, tanpa masalah.

Jangan lalai belajar secara berterusan dalam kerjaya anda. Pilih bahasa yang tepat untuk masalah anda. Fikirkan seni bina, dan keluarkan zon selesa anda. Teliti dan selidik alat baru dan cara baru untuk mendekati masalah yang anda hadapi.

Anda boleh membaca lebih lanjut di sini mengenai anti-corak Golden Hammer .

Jangkar Bot

The Boat Anchor anti-corak adalah di mana pengaturcara meninggalkan kod dalam pangkalan kod kerana mereka mungkin memerlukannya kemudian.

Mereka mengkodkan sesuatu yang sedikit daripada spesifikasi dan belum diperlukan, tetapi mereka pasti akan melakukannya bulan depan. Oleh itu, mereka tidak mahu menghapusnya. Hantarkan ke pengeluaran dan kemudian apabila mereka memerlukannya, mereka dapat membuatnya berfungsi dengan cepat.

Tetapi ini menyebabkan mimpi buruk penyelenggaraan di pangkalan kode yang mengandungi semua kod yang usang itu. Masalah besarnya ialah rakan sekerja mereka akan mengalami kesukaran untuk mengetahui kod apa yang usang dan tidak mengubah aliran, berbanding dengan kod yang berlaku.

Bayangkan anda sedang dalam proses yang sedang diperbaiki, dan berusaha keras untuk mengetahui apa yang bertanggungjawab untuk menghantar butiran kad pelanggan ke API untuk mengeluarkan dana dari bank mereka. Anda boleh membuang masa membaca dan menyahpepijat kod usang, tanpa menyedari bahawa anda bahkan tidak berada di tempat yang tepat di pangkalan data.

Isu terakhir adalah, kod usang menjadikan masa binaan anda lebih lama dan anda mungkin menggabungkan kod yang berfungsi dan usang. Anda bahkan boleh mula "menghidupkannya" secara tidak sengaja dalam pengeluaran.

Sekarang anda mungkin dapat melihat mengapa ia disebut anti-corak perahu - ia berat untuk dibawa (menambah hutang teknikal) tetapi tidak melakukan apa-apa (secara harfiah, kod itu tidak mempunyai tujuan, ia tidak berfungsi).

Anda boleh membaca lebih lanjut di sini mengenai anti-corak Boat anchor .

Kod mati

Pernahkah anda melihat kod yang ditulis oleh seseorang yang tidak lagi bekerja di syarikat anda? Ada fungsi yang nampaknya tidak melakukan apa-apa. Tetapi ia dipanggil dari mana-mana sahaja! Anda bertanya-tanya dan tidak ada orang yang yakin dengan apa yang dilakukannya, tetapi semua orang terlalu risau untuk menghapusnya.

Kadang-kadang anda dapat melihat apa yang dilakukannya, tetapi konteksnya tidak ada. Anda dapat membaca dan memahami alirannya, tetapi mengapa? Sepertinya kita tidak perlu mencapai titik akhir itu lagi. Tindak balas selalu merupakan tindak balas yang sama untuk setiap pengguna yang berbeza.

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 boleh membaca lebih lanjut di sini mengenai pola anti objek Tuhan .

Kesimpulannya

Di mana-mana pangkalan data besar terdapat keseimbangan berterusan antara menguruskan hutang teknikal, memulakan pembangunan baru, dan menguruskan barisan bug untuk produk anda.

Saya harap artikel ini memberi Anda perhatian untuk melihat ketika anda mungkin akan memasuki lubang kelinci anti-corak, dan beberapa alat untuk menyelesaikannya dengan bersih.

Saya berkongsi tulisan saya di Twitter jika anda menikmati artikel ini, dan ingin melihat lebih banyak lagi.