Anti-minták, amelyeket kerülnie kell a kódban

Minden fejlesztő strukturált, egyszerűen megtervezett és szépen kommentált kódot szeretne írni. Még számtalan olyan tervezési minta létezik, amelyek egyértelmű szabályokat követnek, és egy keretet, amelyet szem előtt kell tartanunk.

De még mindig találhatunk anti-mintákat a szoftverekben, amelyeket egy idő múlva írtak, vagy túl gyorsan írtak.

Az ártalmatlan alapvető feltörés a probléma gyors megoldására precedenst teremthet a kódalapjában. Több helyre másolható, és anti-mintává válhat, amelyet meg kell oldania.

Tehát mi az anti-minta?

A szoftverben az anti-pattern olyan kifejezés, amely leírja, hogy NEM lehet megoldani a kódban előforduló visszatérő problémákat. Az anti-mintákat rossz szoftvertervezésnek tekintik, és általában hatástalanok vagy homályos javítások.  

Általában hozzáadják a "technikai adósságot" is - ez az a kód, amelyet később vissza kell térnie és rendesen helyre kell hoznia.

A hat anti-minták fogom fejteni ebben a cikkben spagetti kód , Arany Hammer , csónak horgony , Dead Code , elterjedése kód és a God Object .

Spagetti kód

A spagetti kód a legismertebb anti-minta. Ez egy kód, amely nulla vagy nulla szerkezettel rendelkezik.

Semmi sem modulált. Vannak véletlenszerű fájlok, amelyek véletlenszerű könyvtárakba vannak szórva. Az egész folyást nehéz követni, és teljesen összekuszálódik (mint a spagetti).

Normális esetben ez egy olyan kérdés, ahol valaki előzetesen nem gondolta át alaposan a programja folyamatát, és csak elkezdett kódolni.

Mit csinal?! Ezt nem tudom követni

image.png

Ez nemcsak karbantartási rémálom, de lehetetlenné teszi az új funkciók hozzáadását.

Folyamatosan törni fog a dolgokat, nem fogja megérteni a változtatások terjedelmét, vagy pontos becsléseket ad a munkájáról, mivel lehetetlen előre látni azt a számtalan kérdést, amely ilyen régészet / találgatás során felmerül.

A Spaghetti Code anti- patternről itt olvashat bővebben .

Arany Kalapács

"Feltételezem, hogy csábító, ha az egyetlen eszközed egy kalapács, akkor mindent úgy kezelj, mintha egy köröm lenne." Abraham Maslow

Képzeljen el egy forgatókönyvet velem: a fejlesztői csapat nagyon-nagyon hozzáértő a vadonatúj Hammer architektúrában. Fantasztikusan működött az összes múltbeli kérdésben. Te vagy a világ vezető Hammer építész csapata.

De most valahogy minden mindig ennek az architektúrának a felhasználásával végződik. Laposfejű csavar? Kalapács. Phillips fejű csavar? Kalapács. Szüksége van egy imbuszkulcsra? Nem, nem, kalapáld meg.

Olyan építészeti megközelítést kezd el alkalmazni, amely nem felel meg pontosan annak, amire szüksége van, de elvégzi a munkát. Túlságosan megbízik egy mintában, és meg kell tanulnia a legjobb munka legjobb eszközét.

Az egész programja komoly teljesítménysikereket érhet el, mert megpróbál egy négyzetet kör alakúra döngölni. Tudja, hogy kétszer annyi időbe telik a kódolás és a program futtatása a kalapácsarchitektúra segítségével ehhez a problémához, de ez könnyebb és ez az, amiben Ön kényelmesen kezelhető.

Ez sem túl kiszámítható. A különböző nyelvek közösen rögzítik a szembesülő problémákat és saját normáikat. Nem alkalmazhat minden olyan szabályt, amely az Ön számára jól működött, egy nyelven, gond nélkül.

Ne hanyagolja el a következetes tanulást a karrierje során. Válassza ki a problémának megfelelő nyelvet. Gondoljon az architektúrára, és tolja ki a kényelmi zónáját. Kutasson és vizsgáljon meg új eszközöket és új módszereket a szembesülő problémák kezeléséhez.

A Golden Hammer anti-mintáról itt olvashat bővebben .

Hajóhorgony

A Boat Anchor anti-minta az, ahol a programozók otthagyják a kódot a kódalapban, mert később szükségük lehet rá.

Kódoltak valamit, ami kissé specifikáción kívül esett, és erre még nincs szükség, de biztosak benne, hogy a következő hónapban megteszik. Tehát nem akarják törölni. Küldje el a termelésnek, majd később, amikor szükségük van rá, gyorsan működőképessé tehetik.

De ez karbantartási rémálmokat okoz a kódbázisban, amely tartalmazza az összes elavult kódot. Óriási kérdés, hogy kollégáik nehezen tudják majd kideríteni, hogy melyik kód elavult és nem változtatja meg a folyamatot, szemben a kóddal, amelyik igen.

Képzelje el, hogy gyorsjavításon van, és kétségbeesetten próbálja kideríteni, mi a felelős azért, hogy az ügyfelek kártyaadatait elküldje az API-nak pénzeszközök felvételére a bankjukból. Időt pazarolhatna az elavult kód olvasásával és hibakeresésével, anélkül, hogy észrevenné, hogy a kódbázisban sincs jó helyen.

A végső kérdés az, hogy az elavult kód meghosszabbítja az összeállítási időt, és keverheti a működő és az elavult kódot. Akár akaratlanul is elkezdheti "bekapcsolni" a gyártást.

Most valószínűleg láthatja, miért hívják a hajóhorgony anti-mintázatának - nehéz cipelni (technikai adósságot ad hozzá), de nem tesz semmit (szó szerint a kódnak semmi értelme nincs, nem működik).

A hajóhorgony anti-mintájáról itt olvashat bővebben .

Halott kód

Neked kellett-e már megnézned egy olyan kódot, amelyet valaki írt, aki már nem dolgozik a cégedben? Van olyan funkció, amely nem úgy néz ki, mintha bármit is csinálna. De mindenhonnan hívják! Kérdezel, és senki más nem egészen biztos abban, hogy mit csinál, de mindenki túlságosan aggódik, hogy törölje.

Néha láthatja, hogy mit csinál, de a kontextus hiányzik. Képes olvasni és megérteni az áramlást, de miért? Úgy tűnik, már nem kell elérnünk ezt a végpontot. A válasz minden felhasználó számára mindig ugyanaz.

Ezt általában a Dead code anti-mintaként írják le . Amikor nem látja, mi szükséges a "tényleges" kódnak a program folyamatához és sikeres végrehajtásához, szemben azzal, ami csak 3 évvel ezelőtt volt szükség, és nem most.

Ez a sajátos anti-minta gyakoribb a gyártásba kerülő koncepció vagy kutatási kód bizonyításában.

Egy alkalommal egy technikai találkozón találkoztam egy sráccal, akinek éppen ez a problémája volt. Rengeteg halott kódja volt, amelyről tudta, hogy halott, és sok tételről azt hitte, hogy halott. De nem kaphatta meg a menedzsment engedélyét, hogy valaha eltávolítsa az összes halott kódot.

Monkey-tesztnek nevezte a megközelítését , ahol kommentálni kezdte és kikapcsolta a dolgokat, hogy lássa, mi robbant fel a gyártásban. Talán egy kicsit túl kockázatos!

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.

Itt többet olvashat az Isten objektum antimintájáról.

Következtetés

Bármely nagy kódbázisban állandó egyensúly van a technikai adósságkezelés, az új fejlesztés megkezdése és a termék hibáinak sora között.

Remélem, hogy ez a cikk figyelt a figyelmedre, amikor esetleg egy anti-minta nyúllyukán haladsz, és néhány eszközt annak tiszta tisztázására.

Megosztom írásomat a Twitteren, ha tetszett ez a cikk, és szeretne többet látni.