Anti-modeļi, no kuriem vajadzētu izvairīties savā kodeksā

Katrs izstrādātājs vēlas uzrakstīt strukturētu, vienkārši izplānotu un labi komentētu kodu. Ir pat neskaitāmi daudz dizaina modeļu, kas dod mums skaidrus noteikumus, kas jāievēro, un ietvaru, kas jāpatur prātā.

Bet programmatūrā, kas tika uzrakstīta pēc kāda laika, vai arī tika uzrakstīta pārāk ātri, mēs joprojām varam atrast anti-modeļus.

Nekaitīgs pamata uzlaušana, lai ātri atrisinātu problēmu, var radīt precedentu jūsu koda bāzē. To var kopēt vairākās vietās un pārvērst par anti-modeli, kas jums jārisina.

Tātad, kas ir anti-modelis?

Programmatūrā anti-model ir termins, kas apraksta, kā NEVAR atrisināt atkārtotas problēmas jūsu kodā. Anti-mode tiek uzskatīts par sliktu programmatūras dizainu, un parasti tie ir neefektīvi vai neskaidri labojumi.  

Viņi parasti arī pievieno "tehnisko parādu" - tas ir kods, kas jums jāatgriežas un vēlāk pareizi jānovērš .

Seši anti-modeļi, par kuriem es runāšu šajā rakstā, ir Spageti kods , Zelta āmurs , Laivu enkurs , Dead Code , Kodu un Dieva objekta izplatīšana .

Spageti kods

Spageti kods ir vispazīstamākais anti-modelis. Tas ir kods ar nelielu līdz nulle struktūru.

Nekas nav modulēts. Ir izlases faili, kas izmētāti nejaušos direktorijos. Visai plūsmai ir grūti sekot, un tā ir pilnīgi sapinusies kopā (piemēram, spageti).

Parasti tas ir jautājums, kurā kāds iepriekš nav rūpīgi izdomājis savas programmas plūsmu un tikko sācis kodēt.

Ko tas dara?! Es tam nevaru sekot

image.png

Tas ir ne tikai apkopes murgs, bet tas padara gandrīz neiespējamu jaunas funkcionalitātes pievienošanu.

Jūs pastāvīgi lauzīsit lietas, nesapratīsit savu izmaiņu apjomu vai sniegsiet precīzus aprēķinus par savu darbu, jo nav iespējams paredzēt neskaitāmos jautājumus, kas rodas, veicot šādu arheoloģiju / minējumus.

Vairāk par Spageti Code antimodeļu varat lasīt šeit .

Zelta āmurs

"Es domāju, ka ir vilinoši, ja vienīgais jūsu rīcībā esošais rīks ir āmurs, izturēties pret visu tā, it kā tas būtu naglas." Ābrahams Maslovs

Iedomājieties scenāriju ar mani: jūsu dev komanda ir ļoti, ļoti kompetenta pilnīgi jaunajā Hammer arhitektūrā. Tas ir fantastiski darbojies visos jūsu iepriekšējos jautājumos. Jūs esat pasaules vadošā Hammer arhitektūras komanda.

Bet tagad kaut kā viss vienmēr tiek izmantots, izmantojot šo arhitektūru. Plakana galvas skrūve? Āmurs. Phillips galvas skrūve? Āmurs. Jums vajag uzgriežņu atslēgu? Nē jums nav, āmurs to.

Jūs sākat piemērot arhitektūras pieeju, kas ne visai atbilst vajadzīgajam, bet paveic darbu. Jūs esat vairāk paļāvies uz vienu modeli un jums jāapgūst labākais rīks labākajam darbam.

Visa jūsu programma var beigties ar nopietnu sniegumu, jo jūs mēģināt kvadrātu sagriezt apļa formā. Jūs zināt, ka kodēšanai un programmas izpildei šai problēmai nepieciešams divreiz ilgāks laiks, izmantojot āmura arhitektūru, taču tas ir vieglāk, un tas ir tas, kas jums patīk.

Tas arī nav ļoti paredzams. Dažādām valodām ir kopīgi problēmu risinājumi un viņu standarti. Jūs nevarat lietot visus likumus, kas jums bija labi, vienā valodā uz nākamo, bez problēmām.

Neatstājiet novārtā konsekventu mācīšanos savā karjerā. Izvēlieties savai problēmai pareizo valodu. Padomājiet par arhitektūru un izstumiet savu komforta zonu. Izpētiet un izpētiet jaunus rīkus un jaunus veidus, kā risināt problēmas, ar kurām saskaras.

Vairāk par Golden Hammer anti-modeli varat izlasīt šeit .

Laivu enkurs

Boat Anchor anti-modelis ir vieta, kur programmētāji atstāj kodu codebase, jo tie var būt nepieciešams vēlāk.

Viņi kodēja kaut ko nedaudz ārpus specifikācijas, un tas vēl nav vajadzīgs, taču viņi ir pārliecināti, ka to darīs nākamajā mēnesī. Tāpēc viņi nevēlas to izdzēst. Nosūtiet to uz ražošanu un vēlāk, kad tas būs vajadzīgs, viņi varēs ātri to darbināt.

Bet tas rada uzturēšanas murgus koda bāzē, kurā ir viss novecojušais kods. Milzīgs jautājums ir tāds, ka viņu kolēģiem būs grūti noteikt, kurš kods ir novecojis un nemaina plūsmu, salīdzinot ar kodu, kas to dara.

Iedomājieties, ka jūs izmantojat karsto problēmu un izmisīgi mēģināt noskaidrot, kas ir atbildīgs par klientu karšu datu nosūtīšanu API, lai izņemtu līdzekļus no viņu bankas. Jūs varētu tērēt laiku nolietota koda lasīšanai un atkļūdošanai, neapzinoties, ka neesat pat īstajā vietā koda bāzē.

Pēdējais jautājums ir tāds, ka novecojis kods padara jūsu veidošanas laiku ilgāku, un jūs varat sajaukt darba un novecojušu kodu. Varētu pat sākt neviļus "ieslēgt" ražošanā.

Tagad jūs, iespējams, redzat, kāpēc to sauc par laivu enkura anti-modeli - tas ir smags pārnēsāšanai (pievieno tehnisko parādu), bet neko nedara (gluži burtiski, kodam nav nekāda mērķa, tas nedarbojas).

Vairāk par Laivu enkura anti-modeli varat lasīt šeit .

Miris kods

Vai jums kādreiz ir nācies apskatīt kodu, ko uzrakstījis kāds, kurš vairs nestrādā jūsu uzņēmumā? Ir funkcija, kas neizskatās tā, ka tā kaut ko dara. Bet to sauc no visurienes! Jūs jautājat apkārt, un neviens cits nav pilnīgi pārliecināts, ko tā dara, bet visi ir pārāk noraizējušies, lai to izdzēstu.

Dažreiz jūs varat redzēt, ko tas dara, bet konteksta trūkst. Jūs spējat lasīt un saprast plūsmu, bet kāpēc? Neizskatās, ka mums vairs vajadzētu sasniegt šo galapunktu. Atbilde vienmēr ir viena un tā pati atbilde katram lietotājam.

To parasti raksturo kā Dead Code anti-modeli. Kad jūs nevarat redzēt, kas ir "faktiskais" kods, kas nepieciešams jūsu programmas plūsmai un veiksmīgai izpildei, salīdzinot ar to, kas bija vajadzīgs tikai pirms 3 gadiem, nevis tagad.

Šis konkrētais anti-modelis ir biežāk sastopams pierādījumos par koncepciju vai pētījumu kodu, kas nonāca ražošanā.

Vienu reizi tehniskās tikšanās laikā es satiku puisi, kuram bija tieši šī problēma. Viņam bija daudz mirušā koda, par kuru viņš zināja, ka tas ir miris, un partijas, par kurām viņš domāja, ka ir mirušas. Bet viņš nevarēja saņemt vadības atļauju kādreiz noņemt visu mirušo kodu.

Viņš atsaucās uz savu pieeju kā Pērtiķu testēšana, kur viņš sāka komentēt un izslēgt lietas, lai redzētu, kas uzspridzinājās ražošanā. Varbūt mazliet par riskantu!

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.

Šeit varat lasīt vairāk par Dieva objekta anti-modeli.

Secinājums

Jebkurā lielā kodubāzē pastāv pastāvīgs līdzsvars starp tehnisko parādu pārvaldīšanu, jaunu izstrādes uzsākšanu un kļūdu rindas pārvaldīšanu jūsu produktam.

Es ceru, ka šis raksts ir devis jums iespēju pamanīt, kad jūs, iespējams, dodaties pa anti-modeļa trušu caurumu, un dažus rīkus, lai to tīri atrisinātu.

Es dalos ar savu rakstu čivināt, ja jums patika šis raksts un vēlaties redzēt vairāk.