Дылема рамак

Як распрацоўшчык, фрэймворк - гэта звычайна першае, за што вы хапаецеся, калі хочаце паскорыць працу і захаваць надзейнасць. Людзі часта кажуць пра фрэймворкі так, быццам гэта ідэальнае рашэнне, якое можа вырашыць усе вашы праблемы, робячы распрацоўку больш хуткай, прасцейшай і больш эфектыўнай. Тым не менш, калі ў вас быў пэўны вопыт, вы ведаеце, што рамкі не з'яўляюцца універсальным рашэннем. Выбар правільнага можа спрасціць вашу працу, але няправільны выбар можа прывесці да галаўнога болю ў далейшым, запавольваючы вас, калі вам трэба рухацца хутка.

У гэтым паведамленні ў блогу мы збіраемся паглыбіцца ў рэальныя праблемы і стратэгіі, звязаныя з выбарам і выкарыстаннем фрэймворкаў. Мы разгледзім патэнцыйныя падводныя камяні, як іх пазбегнуць і спосабы захаваць вашу кодавую базу гнуткай - нават калі фрэймворк дзейнічае.

Адносіны, у якія вы не ведалі, што ўступаеце

Прыняцце рамак падобна на ўступленне ў доўгатэрміновыя адносіны. І гэта не тое, што трэба ўспрымаць легкадумна. У адрозненне ад простай бібліятэкі або невялікай утыліты, фрэймворкі пастаўляюцца з меркаваннямі - іх шмат. Яны навязваюць структуру і метадалогію вашай заяўцы, падабаецца вам гэта ці не.

Вельмі важна памятаць, што ў стваральнікаў фрэймворкаў ёсць свае прыярытэты. Яны вырашаюць СВАЕ праблемы, а не вашыя. Яны вам нічога не павінны (калі, вядома, у вас няма прыяцеля ва ўнутранай камандзе фрэймворка, у такім выпадку вам пашанцавала). Калі справы пойдуць на поўдзень, асабліва ўглыб вашага праекта, вас можа чакаць свет крыўды. Цяпер вы затрымаліся, выпраўляючы яго, ці, што яшчэ горш, цалкам яго выдзіраеце.

Не весела, праўда?

Такім чынам, перш чым прывязваць сябе да каркаса, пераканайцеся, што ён сапраўды адпавядае таму, што вам трэба. У адваротным выпадку вы кідаеце косці.

Праблемы FAANG

Аўтар паняцця не мае, ці стаў FAANG MAANG, MANGA, ці мы ўсе цяпер проста ў анімэ.

Тут вопыт сапраўды мае значэнне. Калі кампаніі хутка растуць, яны часта сутыкаюцца з праблемамі, з якімі не справіцца ніякае стандартнае рашэнне. Маштаб гэтых праблем прымушае іх ствараць уласныя інструменты — карыстальніцкія базы даных, механізмы ETL, інструменты BI — што заўгодна. Такія буйныя тэхналагічныя гіганты, як Google, LinkedIn, Spotify і Netflix, сталі лідэрамі, ствараючы інструменты з адкрытым зыходным кодам, з якімі ўсе мы цяпер можам гуляць.

Але вось што: гэтыя інструменты не былі створаны для ўніверсальнага прымянення. Яны былі створаны для вырашэння канкрэтных праблем, з якімі большасць кампаній ніколі не сутыкнецца. Інжынеры, якія працавалі ў гэтых буйных кампаніях, прывыклі вырашаць такія праблемы - яны стварылі рашэнні, якія працуюць у маштабе, які большасць з нас можа толькі ўявіць. Такім чынам, калі яны пераходзяць у меншыя кампаніі, рашэнні аб асновах і інструментах, якія яны прымаюць, грунтуюцца на глыбокім разуменні магутнасці і недахопаў гэтых тэхналогій.

Адпор супраць Frameworks

Апошнім часам наспявае нейкі бунт — людзі стамляюцца ад рамак. Асабліва ў свеце JavaScript, распрацоўшчыкам надакучыў пастаянны адток. Вы, напэўна, гэта бачылі: кожны раз, калі выходзіць сур'ёзнае абнаўленне, вам трэба перапісаць значныя кавалкі кодавай базы, каб заставацца актуальным. І не прымушайце мяне пачынаць бясконцы цыкл рэзкіх змяненняў.

Гэта расчараванне прывяло да адраджэння больш простых, больш стабільных стэкаў. Такія рэчы, як банальны HTML, CSS, jQuery, PHP і SQLite, вяртаюцца сярод распрацоўшчыкаў, якія аддаюць перавагу выкананню задач, а не знаходжанню на перадавых тэхналогіях. Так, гэта можа здацца "старой школай", але яно далёка не састарэла. З больш простым стэкам вы можаце хутка выконваць ітэрацыі і пастаўляць яшчэ хутчэй. Безумоўна, новыя фрэймворкі, такія як React, Node.js і Flask, маюць месца, але часам вам не патрэбныя ўсе мудрагелістыя рэчы. Часам захаванне таго, што працуе, можа пазбавіць вас ад мноства галаўных боляў.

Прамысловы комплекс Framework?

Фрэймворкі становяцца... празмерна раскручанымі? Цяжка не заўважыць, што некаторыя фрэймворкі больш падобныя на інструменты, прызначаныя для прыцягнення венчурнага фінансавання, чым для вырашэння рэальных праблем распрацоўшчыкаў. Падобна на тое, што існуе цэлая экасістэма, якая падштурхоўвае распрацоўшчыкаў да гэтых фрэймворкаў, каб потым яны зразумелі, што пасля маштабавання яны аказваюцца зачыненымі на дарагіх платформах. Безумоўна, фрэймворкі, такія як Databricks, з адкрытым зыходным кодам і бясплатныя для пачатку, але па меры росту вас падштурхоўваюць да іх карпаратыўных рашэнняў. І раптам вашы выдаткі на хостынг і эксплуатацыю зашкальваюць, у той час як простага VPS можа быць дастаткова.

Гэта крыху падобна на пастку, ці не так?

Затрымка Рамачнага рашэння

Вось парада, якой я клянуся: не спяшайцеся з выбарам рамкі . Не бярыце на сябе абавязацельствы, пакуль ваша архітэктура не будзе цалкам распрацавана.

Рамка павінна быць апошнім, пра што вы турбуецеся, а не першым.

Па-першае, пераканайцеся, што ваша архітэктура трывалая. Ведайце свае асноўныя кампаненты і тое, як яны будуць узаемадзейнічаць. Пасля таго, як вы гэта атрымаеце, вы можаце ацэньваць фрэймворкі з дакладным разуменнем таго, дзе яны могуць адпавядаць — ці падыходзяць яны ўвогуле.

Такі падыход гарантуе, што ваш дызайн будзе надзейным і адпавядае вашым канкрэтным патрэбам. Калі прыйдзе час разглядаць фрэймворк, вы зможаце ясна ўбачыць, дзе ён можа палепшыць вашу архітэктуру, не абмяжоўваючы яе.

Перш чым прыступіць да выкарыстання якой-небудзь структуры, спытаеце сябе: ці сапраўды яна вам патрэбна? Безумоўна, фрэймворкі могуць дадаць ўзроўні аўтаматызацыі і зручнасці, але яны таксама маюць уласны набор абмежаванняў. Калі ваша праграма мае ўнікальныя патрабаванні, фрэймворкі могуць не падысці з імі.

Доўга думайце аб доўгатэрміновых перавагах супраць абмежаванняў.

Стварэнне Frameworks Expendable

Калі вы вырашылі, што фрэймворк варты рызыкі, пераканайцеся, што яго лёгка замяніць. Так, вы правільна пачулі. Забяспечце некаторую гнуткасць, каб, калі вам спатрэбіцца адмовіцца ад гэтага пазней, гэта не была манументальнай задачай. Вось як:

Абстрагуйце свае залежнасці

Трымайце брудныя ручкі фрэймворка далей ад вашага асноўнага кода. Выкарыстоўвайце інтэрфейсы для абстрагавання функцыянальнасці фрэймворка, каб ваша бізнес-логіка не залежала ад фрэймворка напрамую.

Дапусцім, вы выкарыстоўваеце TensorFlow для машыннага навучання. Замест таго, каб убудоўваць код TensorFlow ва ўсё ваша прыкладанне, вызначце інтэрфейсы, каб усё было акуратна і абстрактна:

 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

Робячы гэта, ваша асноўная логіка не будзе цесна звязана з TensorFlow. Калі вам трэба перайсці на іншую структуру машыннага навучання, трэба проста замяніць рэалізацыю.

Ін'екцыя залежнасці (DI) - ваш сябар

Далей пагаворым пра ін'екцыю залежнасці (DI). Гэтая тэхніка дазваляе ўводзіць пэўныя рэалізацыі вашых інтэрфейсаў у вашыя класы, захоўваючы вашу кодавую базу раз'яднанай і модульнай.

 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())

Цяпер ваш код гнуткі, просты ў тэсціраванні і гатовы да таго, што чакае яго ў будучыні.

Прыміце інверсію кантролю (IoC)

Каб атрымаць максімальную гнуткасць, падніміце рэчы на прыступку з Inversion of Control (IoC). Гэты шаблон дазваляе вам вызначаць рэалізацыі ў файле канфігурацыі або ў цэнтралізаваным месцы ў вашым кодзе. Гэта вішанька на вяршыні вашай фрэймворка-агностычнай архітэктуры.

Вось прыклад таго, як гэта можа працаваць з падыходам на аснове канфігурацыі:

 # 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)

Цяпер, калі вам калі-небудзь спатрэбіцца замяніць TensorFlow на іншую структуру машыннага навучання, вы проста абновіце канфігурацыю і працягнеце. Без клопатаў, без драмы.

Заключэнне

Памятайце, фрэймворкі павінны служыць ВАШАЙ архітэктуры, а не дыктаваць яе. Пры ўважлівым планаванні і стратэгічнай абстракцыі вы можаце скарыстацца перавагамі фрэймворкаў, не трапляючы ў пастку доўгатэрміновых залежнасцей. Хітрасць у тым, каб заставацца пад кантролем. Так што ў наступны раз, калі вы збіраецеся акунуцца ў рамкі, зрабіце крок назад і нагадайце сабе: тут вы вырашаеце.

Дзякуй за чытанне!

Ёсць пытанні? Пакіньце свой каментарый ніжэй, каб пачаць фантастычныя дыскусіі!

Зазірніце ў мой блог або прыходзьце павітацца 👋 у Twitter або падпішыцеся на мой тэлеграм-канал . Плануйце лепшае!