Mga antipattern

Panimula sa mga anti-pattern

Ang mga anti-pattern ay ang eksaktong kabaligtaran ng mga pattern. Alalahanin na ang mga pattern ng disenyo ay mga halimbawa ng mahusay na mga kasanayan sa programming, iyon ay, mga pattern para sa paglutas ng ilang mga problema. Ngunit ang mga anti-pattern ay ganap na kabaligtaran, iyon ay, mga pattern ng mga pagkakamali na ginawa kapag nilulutas ang iba't ibang mga problema.

Bahagi ng mahusay na kasanayan sa programming ang tiyak na pag-iwas sa mga anti-pattern. Huwag isipin na ito ay isang hindi maintindihan na teoretikal na basura - ito ay mga tiyak na problema na halos bawat developer ay nakatagpo. Sino ang nakakaalam, siya ay armado!

Tingnan natin ang ilang anti-pattern na karaniwan sa mga nagsisimula:

• Mga magic na numero at string
• klase ng diyos
• Napaaga ang pag-optimize
• ang pag-imbento ng bisikleta
• Pag-imbento ng unicycle

Mga magic na numero at string

Ang magic number ay isang pare-parehong ginagamit sa code para sa isang bagay (madalas na pagkakakilanlan ng data), ang numero mismo kung saan ay walang kahulugan nang walang kaukulang komento. Ang mga numero ay talagang walang semantika.

Kapag nagsimulang lumitaw ang mga numero sa code ng iyong proyekto, ang kahulugan nito ay hindi halata, ito ay napakasama. Ang isang programmer na hindi ang may-akda ng naturang code ay mahihirapang ipaliwanag kung paano ito gumagana. Sa paglipas ng panahon, kahit na ang may-akda ng code na may mga magic number ay hindi maipaliwanag ito.

Ang mga numero ay nagpapahirap sa code na maunawaan at refactor. Ang mga pangunahing dahilan para sa error na ito ay ang pagmamadali sa pag-unlad at ang kakulangan ng kasanayan sa programming. Ang anti-pattern na ito ay dapat na nipped sa simula sa pamamagitan ng stipulating ang paggamit ng mga numeric constants bago simulan ang pagbuo.

Upang malutas ang problemang ito, kailangan mong lumikha ng isang variable na ang pangalan ay nagpapaliwanag ng layunin ng numeric constant, at italaga ito ng nais na halaga.

klase ng diyos

Ang banal na bagay ay isang anti-pattern na karaniwan sa mga developer ng OOP. Ang ganitong bagay ay tumatagal ng napakaraming function at/o nag-iimbak ng halos lahat ng data. Bilang resulta, mayroon kaming isang hindi portable na code, na, bukod dito, ay mahirap maunawaan.

Bilang karagdagan, ang naturang code ay medyo mahirap na mapanatili, dahil ang buong sistema ay nakasalalay halos eksklusibo dito. Mga dahilan para sa error na ito: kawalan ng kakayahan ng developer, isang developer ang kumukuha ng malaking bahagi ng trabaho (lalo na kapag ang dami ng trabaho ay lumampas sa antas ng karanasan ng developer na iyon).

Kinakailangang harapin ang diskarteng ito sa pamamagitan ng paghahati ng mga gawain sa mga subtask na maaaring harapin ng iba't ibang mga developer.

Napaaga ang pag-optimize

Ang napaaga na pag-optimize ay ang pag-optimize na ginagawa bago ang programmer ay magkaroon ng lahat ng impormasyong kailangan upang makagawa ng matalinong mga pagpapasya tungkol sa kung saan at kung paano ito gagawin.

Sa pagsasagawa, mahirap hulaan kung saan magaganap ang isang bottleneck. Ang mga pagtatangkang mag-optimize bago makakuha ng mga empirical na resulta ay hahantong sa pagiging kumplikado ng code at paglitaw ng mga error, ngunit hindi magdadala ng anumang mga benepisyo.

Paano maiiwasan? Una, magsulat ng malinis, nababasa, gumaganang code gamit ang kilalang at napatunayang mga algorithm at tool. Kung kinakailangan, gumamit ng mga tool sa pag-profile upang makahanap ng mga bottleneck. Umasa sa mga sukat, hindi sa mga hula at pagpapalagay.

Mga halimbawa at tampok

Pag-cache bago mag-profile. Paggamit ng masalimuot at hindi napatunayang heuristics sa halip na mga algorithm na tama sa matematika. Isang seleksyon ng mga bago, hindi pa nasusubukang mga framework na maaaring mag-misbehave sa ilalim ng pag-load.

Ano ang hirap

Hindi madaling matukoy kung napaaga ang pag-optimize. Mahalagang mag-iwan ng puwang para sa paglago nang maaga. Kailangan mong pumili ng mga solusyon at platform na nagbibigay-daan sa iyong madaling mag-optimize at lumago. Minsan din ang napaaga na pag-optimize ay ginagamit bilang isang dahilan para sa masamang code. Halimbawa, kumukuha sila ng O(n2) algorithm dahil ang algorithm ay magiging O(n) na mas mahirap.

ang pag-imbento ng bisikleta

Ang kahulugan ng anti-pattern na ito ay ang programmer ay bubuo ng sarili niyang solusyon sa isang problema kung saan mayroon nang mga solusyon, at kadalasan ay mas matagumpay.

Isinasaalang-alang ng developer ang kanyang sarili na mas matalino, kaya sinusubukan niyang makabuo ng kanyang sariling solusyon para sa bawat gawain, sa kabila ng karanasan ng kanyang mga nauna. Kadalasan, humahantong lamang ito sa pagkawala ng oras at pagbaba sa kahusayan ng programmer. Pagkatapos ng lahat, ang solusyon ay malamang na maging suboptimal, kung natagpuan sa lahat.

Siyempre, hindi mo maaaring ganap na itapon ang posibilidad ng isang independiyenteng solusyon, dahil hahantong ito sa copy-paste na programming sa direktang paraan. Dapat na i-navigate ng developer ang mga gawain na maaaring lumitaw sa kanyang harapan upang mahusay na malutas ang mga ito, gamit ang mga handa na solusyon o pag-imbento ng kanyang sarili.

Kadalasan, ang dahilan para sa anti-pattern na ito ay isang simpleng kakulangan ng oras. At ang oras ay pera.

Pag-imbento ng square wheel na bisikleta

Ang anti-pattern na ito ay napakalapit na nauugnay sa simpleng muling pag-imbento ng gulong - paggawa ng sarili mong masamang solusyon kapag may mas magandang solusyon.

Ang anti-pattern na ito ay tumatagal ng dalawang beses sa oras: una, ang oras ay ginugugol sa pag-imbento at pagpapatupad ng iyong sariling solusyon, at pagkatapos ay sa refactoring o pagpapalit nito.

Ang programmer ay dapat magkaroon ng kamalayan sa pagkakaroon ng iba't ibang mga solusyon para sa ilang mga hanay ng mga gawain, na ginagabayan ng kanilang mga pakinabang at disadvantages.

Ang lahat ng mga problema na iyong haharapin bilang isang programmer ay maaaring nahahati sa dalawang bahagi:

• Nalutas ng matatalinong tao ang problemang ito 30 taon na ang nakakaraan
• Nalutas ng matatalinong tao ang problemang ito 50 taon na ang nakakaraan

Karamihan sa mga problema sa programming ay matagumpay na nalutas bago ka pa ipinanganak . Hindi na kailangang mag-imbento ng anuman - pag-aralan lamang ang karanasan ng ibang tao (ito ang para sa mga libro na isinulat).

Sa 2022, maaari nating ipagdiwang ang mga sumusunod na kaarawan:

• Mga wika sa programming
  • Ang wikang C ay naging 50 taong gulang (1972)
  • Ang wikang Java ay naging 27 taong gulang (1995)
  • 31 taong gulang na si Python (1991)
• Koneksyon
  • Ang Internet ay naging 39 (1983)
  • Ang mobile phone ay naging 49 (1973)
  • Ang unang SMS ay ipinadala 30 taon na ang nakakaraan (1992)
• Mga pattern
  • Ang pattern ng MVC ay naging 44 (1978)
  • Ang SQL ay naimbento 48 taon na ang nakakaraan (1974)
  • Ang Java Beans ay naimbento 26 taon na ang nakakaraan (1996)
• Mga aklatan
  • Ang hibernate ay naimbento 21 taon na ang nakakaraan (2001)
  • Ang tagsibol ay naimbento 20 taon na ang nakakaraan (2002)
  • Inilabas ang Tomcat 23 taon na ang nakakaraan (1999)
• OS
  • Ang Unix ay inilabas 51 taon na ang nakakaraan (1971)
  • Nakita ng Windows ang liwanag ng araw 37 taon na ang nakakaraan (1985)
  • Inilabas ang Mac OS 21 taon na ang nakalipas (2001)

At ang lahat ng mga bagay na ito ay hindi lamang naimbento, sila ay binuo bilang mga solusyon sa mga problema na karaniwan at may kaugnayan sa panahong iyon.