Vývoj softvéru je vynikajúci, ale ... Myslím, že všetci môžeme súhlasiť, že to môže byť emotívna horská dráha. Na začiatku je všetko super. Pridajte nové funkcie jednu za druhou v priebehu niekoľkých dní, ak nie hodín. Ste na šťastnej vlne!

Rýchly posun vpred o niekoľko mesiacov a rýchlosť vášho vývoja sa spomalí. Je to preto, že už nepracujete tak tvrdo ako predtým? Nie naozaj. Rýchly posun vpred o niekoľko mesiacov dopredu a rýchlosť vášho vývoja sa ešte spomalí. Práca na tomto projekte už nie je zábavná a stala sa brzdou.

Ale zhoršuje sa to. Začnete objavovať viac chýb vo svojej aplikácii. Riešením jednej chyby sa často vytvoria dve nové. V tomto okamihu môžete začať spievať:

99 malých chýb v kóde. 99 malých chýb. Vezmite si jednu, nalepte na ňu náplasť,

… 127 malých chýb v kóde.

Ako vnímate prácu na tomto projekte teraz? Ak ste ako ja, pravdepodobne začnete strácať motiváciu. Vývoj tejto aplikácie je komplikovaný, pretože každá zmena v existujúcom kóde môže mať nepredvídateľné následky.

Táto skúsenosť je vo svete softvéru bežná a môže vysvetliť, prečo toľko programátorov chce opustiť zdrojový kód a všetko prepísať.

Dôvody, prečo sa vývoj softvéru časom spomalí

Aký je dôvod tohto problému?

Hlavnou príčinou je zvyšujúca sa zložitosť. Z mojej skúsenosti je najväčšou príčinou celkovej zložitosti skutočnosť, že vo veľkej väčšine softvérových projektov je všetko prepojené. Z dôvodu závislostí, ktoré má každá trieda, sa pri zmene kódu v triede, ktorá odosiela e-maily, vaši používatelia zrazu nemôžu zaregistrovať. Prečo? Pretože váš registračný kód závisí od kódu, ktorý odosiela e-maily. Teraz už nemôžete nič meniť bez zavádzania chýb. Je jednoducho nemožné vysledovať všetky závislosti.

Takže tu to máte; skutočnou príčinou našich problémov je zvyšovanie zložitosti pochádzajúcej zo všetkých závislostí, ktoré náš kód má.

Veľký bahenný ples a ako ho znížiť

Zábavné je, že tento problém je známy už roky. Je to bežný antipateriál, ktorý sa nazýva „veľká hlinená guľa“. Tento druh architektúry som videl takmer na každom projekte, na ktorom som v priebehu rokov pracoval, vo viacerých rôznych spoločnostiach.

Čo je to teda za tento anti-vzor? Jednoducho povedané, dostanete veľkú hlinenú guľu, keď je každý predmet závislý od ostatných predmetov. Nižšie vidíte graf závislostí populárneho projektu open source Apache Hadoop. Ak chcete vizualizovať veľkú hlinenú guľu (alebo lepšie povedané veľkú priadzu), nakreslite kruh a rovnomerne do neho vložte projektové triedy. Stačí nakresliť čiaru medzi každou dvojicou tried, ktoré od seba závisia. Teraz môžete vidieť zdroj vašich problémov.

príklady konkurenčnej výhody podnikateľský plán

„Veľká guľa z blata“ od Apache Hadoop

Modulárne kódové riešenie

Položil som si teda otázku: bolo by možné znížiť zložitosť a ešte sa baviť ako na začiatku projektu? Pravdupovediac, nemôžete mazať všetci zložitosť. Ak chcete pridať nové funkcie, budete vždy musieť zvýšiť zložitosť svojho kódu. Zložitosť sa však môže pohybovať a šíriť.

Ako iné odvetvia riešia tento problém

Pomysli na strojársky priemysel. Keď malá dielňa vytvára stroje, kupuje množinu štandardných položiek, vytvára niektoré vlastné položky a kombinuje ich. Môžu tieto komponenty vyrobiť úplne samostatne a zostaviť všetko posledné, čo urobia iba niekoľkými opravami. Ako je to možné? Vedia, ako sa každá položka zmestí na základe priemyselných štandardov, ako je veľkosť skrutky a počiatočné rozhodnutia, ako je veľkosť montážneho otvoru a vzdialenosť medzi skrutkami.

Každú položku vo vyššie uvedenej sade môže poskytnúť nezávislá spoločnosť, ktorá nemá žiadne vedomosti o finálnom produkte alebo jeho ďalších častiach. Pokiaľ je každá modulárna položka vyrobená podľa špecifikácie, môžete vytvoriť konečné zariadenie podľa plánu.

Môžeme to zopakovať v softvérovom priemysle?

Určite áno! Použitím rozhraní a obrátením princípu riadenia; najlepšia časť je skutočnosť, že tento prístup je možné použiť v ľubovoľnom objektovo orientovanom jazyku: Java, C #, Swift, TypeScript, JavaScript, PHP - zoznam pokračuje ďalej a ďalej. Na uplatnenie tejto metódy nepotrebujete žiadny fantazijný rámec. Musíte len dodržiavať niekoľko jednoduchých pravidiel a zostať disciplinovaný.

Investičná kontrola je váš priateľ

Keď som prvýkrát počul o obrátení riadenia, okamžite som si uvedomil, že som našiel riešenie. Je to koncept prevzatia existujúcich závislostí a ich invertovania pomocou rozhraní. Rozhrania sú jednoduché vyhlásenia metód. Neposkytujú žiadnu konkrétnu implementáciu. Vďaka tomu sa dajú použiť ako dohoda medzi dvoma prvkami o tom, ako ich spojiť. Ak je to žiaduce, môžu sa použiť ako modulárne konektory. Pokiaľ jeden prvok poskytuje rozhranie a druhý prvok poskytuje implementáciu, môžu spolupracovať bez toho, aby o sebe niečo vedeli. Je to vynikajúce.

Pozrime sa na jednoduchom príklade, ako môžeme oddeliť náš systém od modulárneho kódu. Nasledujúce diagramy boli implementované ako jednoduché Java aplikácie. Nájdete ich v tomto Úložisko GitHub .

problém

Predpokladajme, že máme veľmi jednoduchú aplikáciu pozostávajúcu iba z jednej triedy Main, troch služieb a jednej triedy Util. Tieto prvky na sebe navzájom závisia rôznymi spôsobmi. Nižšie vidíte implementáciu pomocou prístupu „veľká guľa bahna“. Triedy si proste volajú. Sú úzko prepojené a jednu položku nemôžete len tak vytiahnuť bez toho, aby ste sa dotkli ostatných. Aplikácie vytvorené v tomto štýle vám umožňujú spočiatku rýchly rast. Myslím si, že tento štýl je vhodný pre projekty overujúce koncept, pretože sa dá hrať ľahko. Nie je to však vhodné pre riešenia pripravené na výrobu, pretože aj údržba môže byť nebezpečná a akákoľvek zmena môže spôsobiť nepredvídateľné chyby. Nasledujúci diagram zobrazuje túto veľkú guľu z hlinenej architektúry.

Prečo to injekcia závislostí urobila všetko zle?

Pri hľadaní lepšieho prístupu môžeme použiť techniku ​​nazývanú závislosť injekcie. Táto metóda predpokladá, že všetky komponenty sa musia používať na všetkých rozhraniach. Čítal som tvrdenia, že uvoľňuje položky z doku, ale naozaj to robí? Nie. Pozrite sa na nižšie uvedený diagram.

Jediným rozdielom medzi súčasnou situáciou a veľkou guľou bahna je skutočnosť, že teraz namiesto priameho volania tried ich voláme prostredníctvom ich rozhraní. Mierne vylepšuje oddeľovacie prvky navzájom. Ak napríklad chcete znova použiť Servicio A V inom projekte to môžete urobiť vybratím Servicio A spolu s Interfaz A, ako aj Interfaz B a Interface Útil. Ako vidíte, Servicio A stále to závisí od ďalších prvkov. Vo výsledku máme stále problémy so zmenou kódu na jednom mieste a narušením správania na inom mieste. Stále to vytvára problém, že ak zmeníte Servicio B e Interfaz B, budete musieť zmeniť všetky prvky, ktoré na tom závisia. Tento prístup nič nerieši; podľa môjho názoru iba pridáva vrstvu vrstvy nad prvky. Závislosti by ste nikdy nemali vpichovať, mali by ste sa ich zbaviť raz a navždy. Hurá na nezávislosť!

Riešenie pre modulárny kód

Prístup, ktorý si myslím, že rieši všetky hlavné bolesti hlavy so závislosťami, robí tak, že závislosti vôbec nepoužívam. Vytvoríte komponent a jeho poslucháč. Poslucháč je jednoduché rozhranie. Kedykoľvek potrebujete zavolať metódu mimo aktuálneho prvku, jednoducho pridajte metódu k poslucháčovi a namiesto toho ju zavolajte. Element môže používať iba súbory, volať metódy v rámci svojho balíka a používať triedy poskytované hlavnou architektúrou alebo inými použitými knižnicami. Nižšie vidíte diagram aplikácie upravenej tak, aby používala architektúru prvkov.

Upozorňujeme, že v tejto architektúre je iba trieda Main má viac závislostí. Prepojte všetky prvky a zapuzdrte obchodnú logiku aplikácie.

Služby sú na druhej strane úplne nezávislé prvky. Teraz môžete z tejto aplikácie vziať každú službu a znova ju použiť inde. Na ničom inom nezávisia. Ale počkajte, bude to lepšie: tieto služby už nemusíte upravovať, pokiaľ nezmeníte ich správanie. Pokiaľ tieto služby robia to, čo majú, môžu zostať nedotknuté až do konca času. Môžu byť vytvorené a profesionálny softvérový inžinier , alebo vôbec prvý kodér, ktorý sa zaviazal dodržiavať najhorší špagetový kód, aký kedy kto uvaril goto zmiešané. To nevadí, pretože vaša logika je zapuzdrená. Akokoľvek je to hrozné, nikdy sa to nerozšíri do iných tried. To vám tiež dáva moc rozdeliť prácu na projekte medzi viacerých vývojárov, kde každý vývojár môže pracovať na svojej vlastnej súčasti nezávisle bez toho, aby musel prerušovať iného alebo dokonca vedieť o existencii ďalších vývojárov.

Nakoniec môžete začať písať samostatný kód ešte raz, rovnako ako na začiatku vášho posledného projektu.

Vzor prvku

Definujme vzor konštrukčného prvku tak, aby sme ho mohli vytvárať opakovane.

Najjednoduchšia verzia prvku pozostáva z dvoch vecí: triedy hlavných prvkov a poslucháča. Ak chcete použiť prvok, musíte implementovať poslucháča a uskutočňovať hovory do hlavnej triedy. Tu je diagram najjednoduchšej konfigurácie:

Je zrejmé, že budete musieť prvku nakoniec pridať viac zložitosti, ale môžete to ľahko urobiť. Len sa uistite, že žiadna z vašich logických tried nezávisí od iných súborov v projekte. V tomto prvku môžu používať iba hlavný rámec, importované knižnice a ďalšie súbory. Pokiaľ ide o súbory aktív, ako sú obrázky, pamiatky, zvuky atď., Mali by byť tiež zapuzdrené v prvkoch, aby sa dali v budúcnosti ľahko znovu použiť. Môžete jednoducho skopírovať celý priečinok do iného projektu a je to!

Nižšie vidíte vzorový graf zobrazujúci pokročilejšiu položku. Pamätajte, že pozostáva z pohľadu, ktorý používate, a nezávisí od žiadnych iných súborov aplikácie. Ak chcete poznať jednoduchý spôsob kontroly závislostí, stačí sa pozrieť do sekcie importu. Existuje nejaký súbor mimo aktuálneho prvku? Ak je to tak, mali by ste tieto závislosti odstrániť ich presunutím do prvku alebo pridaním vhodného volania poslucháčovi.

Pozrime sa na jednoduchý príklad aplikácie „Hello World“ vytvorenej v prostredí Java.

public class Main { interface ElementListener { void printOutput(String message); } static class Element { private ElementListener listener; public Element(ElementListener listener) { this.listener = listener; } public void sayHello() { String message = 'Hello World of Elements!'; this.listener.printOutput(message); } } static class App { public App() { } public void start() { // Build listener ElementListener elementListener = message -> System.out.println(message); // Assemble element Element element = new Element(elementListener); element.sayHello(); } } public static void main(String[] args) { App app = new App(); app.start(); } }

Spočiatku definujeme ElementListener určiť metódu, ktorá vytlačí výstup. Samotný prvok je definovaný nižšie. Volá sa sayHello na element stačí vytlačiť správu pomocou ElementListener. Upozorňujeme, že prvok je úplne nezávislý od implementácie metódy printOutput. Môže byť vytlačený na konzole, fyzickej tlačiarni alebo na fantastickom používateľskom rozhraní. Prvok nezávisí od tejto implementácie. Vďaka tejto abstrakcii možno tento prvok ľahko znovu použiť v rôznych aplikáciách.

Teraz sa pozrite na hlavnú triedu App. Implementujte poslucháča a zostavte prvok spolu s konkrétnou implementáciou. Teraz ho môžeme začať používať.

Tento príklad môžete tiež spustiť v JavaScripte tu

Elementová architektúra

Poďme sa pozrieť na použitie vzoru prvkov vo veľkých aplikáciách. Jedna vec je predviesť sa na malom projekte; ďalším je jeho použitie v skutočnom svete.

Štruktúra webovej aplikácie s úplným zásobníkom, ktorú rád používam, vyzerá takto:

src ├── client │ ├── app │ └── elements │ └── server ├── app └── elements

V priečinku so zdrojovým kódom sme pôvodne rozdelili súbory klienta a servera. Je rozumné to urobiť, pretože fungujú v dvoch rôznych prostrediach: prehľadávač a server typu back-end.

Potom rozdelíme kód v každej vrstve do priečinkov nazývaných aplikácie a položky. Položky pozostávajú z priečinkov so samostatnými súčasťami, zatiaľ čo priečinok aplikácie spája všetky položky a ukladá všetku obchodnú logiku.

Týmto spôsobom môžu byť prvky znova použité medzi rôznymi projektmi, zatiaľ čo všetka zložitosť konkrétnej aplikácie je zapuzdrená do jedného priečinka a často sa redukuje na jednoduché volania prvkov.

Praktické príklady

Ak veríme, že prax vždy zvíťazí nad teóriou, poďme sa pozrieť na príklad z reálneho života vytvorený v jazykoch Node.js a TypeScript.

Príklady zo skutočného života

Je to veľmi jednoduchá webová aplikácia, ktorú je možné použiť ako východiskový bod pre pokročilejšie riešenia. Sleduje architektúru prvkov a využíva značne štruktúrovaný vzor prvkov.

Z najdôležitejších položiek vidíte, že hlavná stránka bola rozlíšená ako položka. Táto stránka obsahuje vlastné zobrazenie. Takže keď ho napríklad chcete znova použiť, stačí skopírovať celý priečinok a vložiť ho do iného projektu. Stačí všetko prepojiť a môžete vyraziť.

Je to základný príklad, ktorý demonštruje, že už dnes môžete začať zavádzať položky do svojej vlastnej aplikácie. Môžete začať rozlišovať nezávislé komponenty a oddeľovať ich logiku. Nezáleží na tom, aký chaotický je kód, na ktorom momentálne pracujete.

Vyvíjajte sa rýchlejšie, opakované použitie častejšie!

Dúfam, že s touto novou sadou nástrojov môžete ľahšie vyvíjať kód, ktorý sa ľahšie udržiava. Predtým, ako sa v praxi pustíme do používania vzoru prvkov, poďme si rýchlo prejsť všetky hlavné body:

• V softvéri sa vyskytuje veľa problémov v dôsledku závislostí medzi rôznymi komponentmi.

• Vykonaním zmeny na jednom mieste môžete zaviesť nepredvídateľné správanie na inom mieste.

Tri bežné architektonické prístupy sú:

• Veľká hlinená guľa. Je vynikajúci pre rýchly vývoj, ale nie taký vhodný pre stabilné výrobné účely.

• Injekcia závislostí. Je to polovičné riešenie, ktorému by ste sa mali vyhnúť.

• Elementová architektúra. Toto riešenie vám umožňuje vytvárať nezávislé komponenty a opakovane ich používať v iných projektoch. Je udržiavateľný a jasný pre stabilné vydania výroby.

Vzor základného prvku pozostáva z hlavnej triedy, ktorá má všetky hlavné metódy, ako aj z poslucháča, ktorý predstavuje jednoduché rozhranie umožňujúce komunikáciu s vonkajším svetom.

Na dosiahnutie architektúry elementov s úplným zásobníkom je front-end najskôr oddelený od back-endového kódu. Potom v každom vytvorte priečinok pre aplikáciu a položky. Priečinok items sa skladá zo všetkých samostatných položiek, zatiaľ čo priečinok s aplikáciami spája všetko dohromady.

Teraz môžete začať vytvárať a zdieľať svoje vlastné položky. Z dlhodobého hľadiska vám pomôže pri vytváraní produktov, ktoré sa ľahko udržiavajú. Veľa šťastia a dajte mi vedieť, čo ste vytvorili!

Ak tiež zistíte, že svoj kód predčasne optimalizujete, prečítajte si _ Ako sa vyhnúť kliatbe predčasnej optimalizácie_ od môjho partnera ApeeScape Kevina Blocha.