Frameworks dilema

Kaip kūrėjas, sistemos paprastai yra pirmas dalykas, kurį griebiatės, kai norite pagreitinti darbą ir išlaikyti jų patikimumą. Žmonės dažnai kalba apie sistemas, tarsi jos būtų puikus sprendimas, galintis išspręsti visas jūsų problemas, todėl kūrimas bus greitesnis, lengvesnis ir efektyvesnis. Tačiau, jei turite patirties, žinote, kad karkasai nėra universalus sprendimas. Tinkamas pasirinkimas gali supaprastinti jūsų darbą, tačiau neteisingas pasirinkimas gali sukelti galvos skausmą kelyje ir sulėtinti jus tik tada, kai reikia greitai judėti.

Šiame tinklaraščio įraše pasinersime į tikrus iššūkius ir strategijas, kylančias renkantis ir naudojant sistemas. Išnagrinėsime galimas kliūtis, kaip jų išvengti ir būdus, kaip išlaikyti savo kodų bazę lanksčią – net kai veikia sistema.

Santykiai, kurių jūs nežinojote, kad užmezgate

Įsipareigojimas laikytis sistemos yra panašus į ilgalaikius santykius. Ir į tai neverta žiūrėti lengvabūdiškai. Skirtingai nei paprastoje bibliotekoje ar nedidelėje programinėje įrangoje, sistemos turi nuomonių – jų daug. Jie nustato jūsų paraiškos struktūrą ir metodiką, nesvarbu, jums tai patinka, ar ne.

Labai svarbu atsiminti, kad sistemos kūrėjai turi savo prioritetus. Jie sprendžia SAVO problemas, o ne tavo. Jie jums nieko neskolingi (nebent, žinoma, turite bičiulį vidinės sistemos komandoje, tokiu atveju jums pasisekė). Jei reikalai pakryps į pietus, ypač įsigilinus į jūsų projektą, galite patirti skausmą. Dabar jūs įstrigote jį taisydami arba, dar blogiau, visiškai jį išplėšdami.

Nesmagu, tiesa?

Taigi, prieš prisirišdami prie sistemos, įsitikinkite, kad ji iš tikrųjų atitinka tai, ko jums reikia. Kitu atveju metate kauliuką.

FAANG problemos

Autorius neįsivaizduoja, ar FAANG tapo MAANG, MANGA, ar dabar visi esame anime.

Štai kur patirtis tikrai svarbi. Kai įmonės sparčiai auga, jos dažnai susiduria su iššūkiais, su kuriais negali susidoroti joks paruoštas sprendimas. Šių problemų mastas verčia juos kurti savo įrankius – pasirinktines duomenų bazes, ETL variklius, BI įrankius – jūs tai vadinate. Didieji technologijų milžinai, tokie kaip „Google“, „LinkedIn“, „Spotify“ ir „Netflix“, pirmavo kurdami ir atvirojo šaltinio įrankius, kuriais dabar galime žaisti ir kiti.

Tačiau štai kas: šie įrankiai nebuvo sukurti taip, kad būtų taikomi visuotinai. Jie buvo sukurti siekiant išspręsti konkrečias problemas, su kuriomis dauguma įmonių niekada nesusidurs. Šiose didelėse įmonėse dirbę inžinieriai yra įpratę spręsti tokius iššūkius – jie sukūrė sprendimus, kurie veikia tokiu mastu, kokį dauguma iš mūsų tik įsivaizduoja. Taigi, kai jie pereina į mažesnes įmones, jų priimami sprendimai ir sprendimai yra pagrįsti giliu šių technologijų galios ir spąstų supratimu.

Pushback Against Frameworks

Pastaruoju metu kyla šioks toks maištas – žmonės pavargsta nuo rėmų. Ypač „JavaScript“ pasaulyje kūrėjai pavargo nuo nuolatinio trūkumo. Tikriausiai tai matėte: kiekvieną kartą, kai nukrenta pagrindinis atnaujinimas, turite perrašyti reikšmingas kodų bazės dalis, kad išliktumėte aktualios. Neverskite manęs pradėti nesibaigiančio pokyčių ciklo.

Šis nusivylimas paskatino paprastesnių, stabilesnių stackų atgimimą. Tokie dalykai kaip vanilinis HTML, CSS, jQuery, PHP ir SQLite sugrįžta tarp kūrėjų, kurie teikia pirmenybę tam, kad būtų atliktas darbas, o ne likti pažangioje technologijų srityje. Taip, tai gali jaustis šiek tiek „senosios mokyklos“, bet toli gražu nėra pasenusi. Naudodami paprastesnį krūvą galite greitai kartoti ir išsiųsti dar greičiau. Žinoma, naujesnės sistemos, tokios kaip „React“, „Node.js“ ir „Flask“, turi savo vietą, bet kartais jums nereikia visų įmantrių dalykų. Kartais laikydamiesi to, kas veikia, galite sutaupyti daug galvos skausmo.

„Framework“ pramonės kompleksas?

Ar karkasai tampa... per daug išpūsti? Sunku nepastebėti, kad kai kurios sistemos atrodo labiau kaip įrankiai, skirti pritraukti VC finansavimą, o ne išspręsti tikras kūrėjo problemas. Panašu, kad visa ekosistema stumia kūrėjus į šias sistemas, kad vėliau jie suprastų, kad, kai jie plečiasi, jie yra užrakinti brangiose platformose. Žinoma, tokios sistemos kaip Databricks yra atvirojo kodo ir gali būti nemokamos, tačiau augant esate linkę į jų verslo sprendimus. Ir staiga jūsų prieglobos ir eksploatavimo išlaidos yra be galo didelės, o gali pakakti paprasto VPS.

Tai atrodo kaip spąstai, ar ne?

Pamatinio sprendimo atidėjimas

Štai patarimas, kuriuo prisiekiu: neskubėkite rinkdamiesi karkaso . Neįsipareigokite, kol jūsų architektūra nebus visiškai suformuluota.

Karkasas turėtų būti paskutinis dalykas, dėl kurio nerimaujate, o ne pirmas.

Pirmiausia įsitikinkite, kad jūsų architektūra yra tvirta. Žinokite savo pagrindinius komponentus ir kaip jie sąveikaus. Kai tai padarysite, galėsite įvertinti sistemas aiškiai suprasdami, kur jos gali tikti – ar iš viso jos tinka.

Šis metodas užtikrina, kad jūsų dizainas būtų tvirtas ir atitiktų jūsų konkrečius poreikius. Kai ateis laikas apsvarstyti sistemą, galėsite aiškiai matyti, kur ji gali pagerinti jūsų architektūrą jos neapribodama.

Prieš pradėdami naudoti bet kokią sistemą, paklauskite savęs: ar jums to tikrai reikia? Žinoma, sistemos gali papildyti automatizavimo ir patogumo sluoksnius, tačiau jos taip pat turi savo apribojimų. Jei jūsų programai keliami unikalūs reikalavimai, sistemos gali būti netinkamos.

Ilgai ir kruopščiai pagalvokite apie ilgalaikę naudą prieš apribojimus.

Padaryti rėmus išnaudojamus

Jei nuspręsite, kad karkasas vertas rizikos, įsitikinkite, kad jį lengva pakeisti. Taip, girdėjote teisingai. Sukurkite šiek tiek lankstumo, kad jei vėliau prireiktų jo atsisakyti, tai nebūtų didžiulė užduotis. Štai kaip:

Apibendrinkite savo priklausomybes

Saugokite, kad sistemos nešvarios rankos nepatektų į pagrindinį kodą. Naudokite sąsajas, kad abstrahuotų sistemos funkcijas, kad jūsų verslo logika tiesiogiai nepriklausytų nuo sistemos.

Tarkime, kad mašininiam mokymuisi naudojate „TensorFlow“. Užuot įdėję TensorFlow kodą visoje programoje, apibrėžkite sąsajas, kad viskas būtų tvarkinga ir abstrakčiai:

 from abc import ABC, abstractmethod import tensorflow as tf class ModelTrainer(ABC): @abstractmethod def train(self, data): pass class TensorFlowTrainer(ModelTrainer): def train(self, data): # TensorFlow-specific training logic model = tf.keras.models.Sequential([...]) model.compile(optimizer='adam', loss='sparse_categorical_crossentropy') model.fit(data, epochs=5) return model

Tai darant, jūsų pagrindinė logika nėra glaudžiai susieta su „TensorFlow“. Jei reikia pereiti prie kitos mašininio mokymosi sistemos, tereikia pakeisti diegimą.

Priklausomybės injekcija (DI) yra jūsų draugas

Toliau pakalbėkime apie priklausomybės injekciją (DI). Ši technika leidžia į klases įtraukti konkrečius sąsajų diegimus, išlaikant kodų bazę atsietą ir modulinę.

 class TrainingPipeline: def __init__(self, trainer: ModelTrainer): self.trainer = trainer def execute(self, data): return self.trainer.train(data) # Inject the TensorFlowTrainer implementation pipeline = TrainingPipeline(TensorFlowTrainer())

Dabar jūsų kodas yra lankstus, lengvai išbandomas ir paruoštas viskam, kas nutiks ateityje.

Apimkite valdymo inversiją (IoC)

Siekdami maksimalaus lankstumo, patobulinkite viską naudodami valdymo inversiją (IoC). Šis modelis leidžia nurodyti diegimus konfigūracijos faile arba centralizuotoje kodo vietoje. Tai vyšnia ant jūsų sistemos agnostinės architektūros.

Štai pavyzdys, kaip tai gali veikti naudojant konfigūracija pagrįstą metodą:

 # config.py class Config: TRAINER = 'my_project.trainers.TensorFlowTrainer' # main.py import importlib class TrainingPipeline: def __init__(self, trainer_class: str): module_name, class_name = trainer_class.rsplit('.', 1) module = importlib.import_module(module_name) trainer_cls = getattr(module, class_name) self.trainer = trainer_cls() def execute(self, data): return self.trainer.train(data) # Inject the trainer specified in the configuration from config import Config pipeline = TrainingPipeline(Config.TRAINER)

Dabar, jei kada nors reikės pakeisti TensorFlow kita mašininio mokymosi sistema, tiesiog atnaujinkite konfigūraciją ir tęskite. Jokio vargo, jokios dramos.

Išvada

Atminkite, kad karkasai turi tarnauti JŪSŲ architektūrai, o ne ją diktuoti. Kruopštus planavimas ir strateginis abstrakcija, galite pasinaudoti sistemomis, neįstrigdami ilgalaikėse priklausomybėse. Triukas yra išlaikyti kontrolę. Taigi kitą kartą, kai ketinate pasinerti į sistemą, ženkite žingsnį atgal ir priminkite sau: čia skambinkite.

Ačiū, kad skaitėte!

Kyla klausimų? Palikite savo komentarą žemiau, kad pradėtumėte nuostabias diskusijas!

Peržiūrėkite arba ateikite pasisveikinti 👋 arba užsiprenumeruokite . Suplanuokite savo geriausia!