Pamantayan para sa masamang disenyo
Ang buhay ay gumagana nang simple: madalas, upang maging matalino, kailangan mo lamang na huwag gumawa ng mga hangal na bagay. Nalalapat din ito sa pagbuo ng software: sa karamihan ng mga kaso, upang magawa ang isang bagay nang maayos, kailangan mo lang na huwag gawin ito nang masama.
Karamihan sa mga programmer ay may karanasan sa mga bahagi ng system na hindi maganda ang disenyo. Ngunit ang mas nakakalungkot, karamihan sa inyo ay magkakaroon ng malungkot na karanasan ng mapagtanto na kayo ang may-akda ng naturang sistema. Gusto namin ang pinakamahusay, ngunit ito ay naging tulad ng dati.
Karamihan sa mga developer ay hindi naghahangad ng masamang arkitektura, at para sa maraming mga sistema ay darating ang isang punto kung saan nagsisimula silang sabihin na ang arkitektura nito ay kahila-hilakbot. Bakit ito nangyayari? Masama ba ang disenyo ng arkitektura sa simula, o naging masama ito sa paglipas ng panahon?
Ang ugat ng problemang ito ay ang kakulangan ng kahulugan ng "masamang" disenyo.
Para sa akin, ang pag-unawa sa kalidad ng disenyo at ang mga dahilan para sa "pagkabulok" nito ang pinakamahalagang katangian para sa sinumang programmer. Tulad ng karamihan sa iba pang mga kaso, ang pangunahing bagay ay upang matukoy ang problema, at ito ay isang bagay ng teknolohiya upang malutas ito.
Kahulugan ng "masamang disenyo"
Kung magpasya kang ipagmalaki ang iyong code sa harap ng isang kapwa programmer, malamang na mapapahiya ka bilang tugon: "Sino ang gumagawa nito?", 'Bakit ganoon?' at "Gagawin ko ang mga bagay sa ibang paraan." Ito ay madalas na nangyayari.
Iba-iba ang lahat ng tao, ngunit isinusulat mo pa rin ang code para sa iyong mga kapwa programmer, kaya sa proseso ng pagbuo ng bawat feature, kailangan mo palagi ng yugto ng pagsusuri kapag tinitingnan ng ibang tao ang iyong code.
Ngunit kahit na maraming bagay ang maaaring gawin sa iba't ibang paraan, mayroong isang hanay ng mga pamantayan na sasang-ayon ang lahat ng mga developer. Ang anumang piraso ng code na nakakatugon sa mga kinakailangan nito ngunit nagpapakita pa rin ng isa (o higit pa) na katangian ay masamang disenyo.
Masamang Disenyo:
- Mahirap baguhin dahil ang anumang pagbabago ay nakakaapekto sa napakaraming iba pang bahagi ng system. ( Rigidity , Rigidity).
- Kapag ginawa ang mga pagbabago, ang ibang bahagi ng system ay masira nang hindi inaasahan. ( Fragility , Fragility).
- Ang code ay mahirap gamitin muli sa ibang application dahil napakahirap na alisin ito sa kasalukuyang application. ( Kawalang-kilos , Kawalang-kilos).
At ang nakakatawang bagay ay halos imposible na makahanap ng isang piraso ng system na hindi naglalaman ng alinman sa mga katangiang ito (iyon ay, nababaluktot, maaasahan at magagamit muli), nakakatugon sa kinakailangan, at sa parehong oras ang disenyo nito ay masama. .
Kaya, maaari nating gamitin ang tatlong katangiang ito upang malinaw na matukoy kung ang isang disenyo ay "masama" o "mabuti".
Mga Dahilan ng "Masamang Disenyo"
Ano ang ginagawang matibay, malutong, at hindi natitinag sa disenyo? Matibay na pagkakaisa ng mga module.
Ang isang disenyo ay matibay kung hindi ito madaling baguhin. Ang katigasan na ito ay dahil sa ang katunayan na ang isang solong pagbabago sa isang piraso ng code sa isang pinagtagpi na sistema ay nagreresulta sa mga pagbabago sa cascading sa mga umaasa na module. Palagi itong nangyayari kapag ang isang tao ay nagtatrabaho sa code.
Kaagad nitong ginagawang kumplikado ang buong proseso ng komersyal na pag-unlad: kapag ang bilang ng mga pagbabago sa cascading ay hindi mahulaan ng taga-disenyo o developer, imposibleng tantiyahin ang epekto ng naturang pagbabago. Samakatuwid, sinusubukan nilang ipagpaliban ang gayong mga pagbabago nang walang katiyakan.
At ito naman ay ginagawang hindi mahuhulaan ang halaga ng pagbabago. Nahaharap sa gayong kawalan ng katiyakan, ang mga tagapamahala ay nag-aatubili na gumawa ng mga pagbabago, kaya ang disenyo ay opisyal na nagiging matibay.
Sa ilang mga punto, ang iyong proyekto ay pumasa sa "katapusan ng kaganapan" at tiyak na mahulog sa "itim na butas" ng matibay na arkitektura.
Ang fragility ay ang ugali ng isang sistema na masira sa maraming lugar pagkatapos ng isang pagbabago. Karaniwan ang mga bagong problema ay nangyayari sa mga lugar na hindi nauugnay sa konsepto sa lugar ng pagbabago. Ang ganitong kahinaan ay seryosong sumisira sa tiwala sa disenyo at pagpapanatili ng system.
Ito ay kadalasang nangyayari kapag walang pribadong pamamaraan. Ito ay sapat na upang gawing publiko ang lahat ng mga pamamaraan, at ikaw ay mapapahamak sa hitsura ng isang marupok na arkitektura. Nakakatulong ang encapsulation na harapin ito sa micro level. Ngunit sa antas ng macro, kailangan mo ng isang modular na arkitektura.
Kapag ang isang proyekto ay may marupok na arkitektura, hindi magagarantiyahan ng mga developer ang kalidad ng produkto.
Ang mga simpleng pagbabago sa isang bahagi ng application ay humantong sa mga bug sa iba pang hindi nauugnay na mga bahagi. Ang pagwawasto sa mga error na ito ay humahantong sa higit pang mga problema, at ang proseso ng escort ay nagiging isang sikat na aso na humahabol sa sarili nitong buntot.
Ang disenyo ay hindi kumikibo kapag ang mga kinakailangang bahagi ng system ay mahigpit na nakatali sa iba pang hindi gustong mga detalye. Masyadong marami sa kanilang sariling code, kanilang sariling natatanging diskarte at solusyon.
Naaalala mo ba ang JUL logger, na ang mga developer ay gumawa ng kanilang sariling mga antas ng pag-log nang walang magandang dahilan? Ito lang ang kaso.
Upang bigyan ang isang taga-disenyo ng ideya kung gaano kadaling gamitin muli ang isang umiiral na disenyo, sapat na isipin kung gaano kadaling gamitin ito sa isang bagong application.
Kung ang disenyo ay mahigpit na pinagsama, kung gayon ang taga-disenyo na ito ay matatakot sa dami ng trabaho na kinakailangan upang paghiwalayin ang mga kinakailangang bahagi ng system mula sa mga hindi kinakailangang detalye. Sa karamihan ng mga kaso, ang gayong disenyo ay hindi magagamit muli, dahil ang halaga ng paghihiwalay nito ay mas malaki kaysa sa pagbuo nito mula sa simula.
Kaugnayan
Lahat ay nagbabago, ngunit ang lahat ay nananatiling pareho. (Kasabihang Intsik)
Napakahusay na mga tanong na itinaas sa itaas. Ano ang mga panganib ng marupok at matibay na sistema? Oo, dahil ang proseso ng pamamahala ng naturang proyekto ay nagiging hindi mahuhulaan at hindi makontrol. At ang presyo ay labis na labis.
Paano magbibigay o hindi magbibigay ng go-ahead ang isang manager na magdagdag ng ilang feature kung hindi niya alam kung gaano katagal ang aabutin? Paano i-prioritize ang mga gawain kung hindi mo sapat na matantya ang oras at pagiging kumplikado ng kanilang pagpapatupad?
At paano mababayaran ng mga developer ang parehong teknikal na utang kapag kami ay kukuha sa pagbabayad nito, at hindi namin maintindihan kung magkano ang aming kukunin hanggang kami ay magsaliksik?
Ang mga problema sa muling paggamit ng code o pagsubok ay napaka-kaugnay din. Ang mga pagsusuri sa unit ay nagsisilbi hindi lamang upang subukan ang ilang mga pagpapalagay tungkol sa yunit na sinusuri, kundi pati na rin upang matukoy ang antas ng pagkakaisa nito at maaaring magsilbing tagapagpahiwatig ng muling paggamit.
Narito ang isang quote mula kay Bob Martin para sa kasong ito: "Upang magamit muli ang iyong code, kailangan mong magsikap na muling gamitin ito nang mas mababa kaysa sa gastos ng pagbuo mula sa simula . " Kung hindi, walang sinuman ang mag-abala sa bagay na ito.
Ang paggamit ng mga prinsipyo at pattern ng disenyo ay nagsisilbing isang layunin - upang gawing maganda ang disenyo. Kung ang kanilang paggamit ay hindi nagbibigay sa iyo ng anumang benepisyo (o vice versa, lumalabag sa mga prinsipyo ng "magandang disenyo"), kung gayon ang isang bagay sa iyong konserbatoryo ay hindi tama at, marahil, ang tool ay nagsimulang gamitin para sa iba pang mga layunin.