Kiedy NIE należy używać frameworka [zamknięty]

Dzisiaj można znaleźć ramy dla dowolnego języka, które pasują do każdego projektu. Większość współczesnych frameworków jest dość solidna (ogólnie rzecz biorąc), z godzinnymi testami, recenzowanym kodem i doskonałą rozszerzalnością.

Myślę jednak, że istnieje jakaś wada DOWOLNEJ struktury, w której programiści, jako społeczność, mogą stać się tak zależni od wybranych przez siebie struktur, że nie rozumieją już podstawowych zasad działania, aw przypadku nowszych programistów nigdy nie uczą się podstawowych zasad działania zaczynać się. Łatwo jest się wyspecjalizować do tego stopnia, że ​​nie jesteś już „programistą PHP” (na przykład), ale „programistą Drupal”, z wyłączeniem wszystkiego innego.

Kogo to obchodzi, prawda? Mamy ramy! Nie musimy wiedzieć, jak „zrobić to ręcznie”! Dobrze?

Rezultatem utraty podstawowych umiejętności (czasami do tego stopnia, że ​​programiści, którzy nie używają frameworków, są postrzegani jako „przestarzałe”) jest to, że powszechną praktyką jest używanie frameworków tam, gdzie nie jest to wymagane lub odpowiednie. Dysponuje się Ułatwia ramowe skończyć mylić z tym, co język bazowy jest zdolny. Deweloperzy zaczynają używać frameworków do realizacji nawet najbardziej podstawowych zadań, tak że to, co kiedyś uważano za podstawowy proces, teraz obejmuje duże biblioteki z własnymi dziwactwami, błędami i zależnościami. To, co kiedyś osiągnięto w 20 liniach, teraz osiąga się poprzez włączenie 20 000 linii frameworku ORAZ napisanie 20 linii w celu użycia frameworka.

I odwrotnie, nie chce się wymyślać koła na nowo. Jeśli piszę kod, aby wykonać podstawowe, zwykłe małe zadanie, mogę mieć wrażenie, że tracę czas, gdy wiem, że framework XYZ oferuje wszystkie funkcje, których szukam, i wiele więcej. Część „o wiele więcej” wciąż mnie martwi, ale wydaje się, że wielu nawet już tego nie rozważa.

Musi istnieć dobra metryka, aby określić, kiedy właściwe jest użycie frameworka. Co uważa Pan za próg być, w jaki sposób możesz zdecydować, kiedy użyć ramy, albo kiedy nie.

„Musi istnieć dobra miara, aby określić, kiedy należy zastosować strukturę”.

Nie całkiem. Gdyby istniały dobre wskaźniki pozwalające określić właściwe użycie jakiejkolwiek technologii, nie zobaczylibyście świętych wojen języka, edytora i metodologii.

Grupy, z którymi współpracowałem, robią to samo - zgadnij koszty i korzyści, wybierz najbardziej produktywną trasę i miej nadzieję, że mają rację. To nie jest strasznie naukowe - jedna część intuicji, trzy części doświadczenia, jedna część podatności na marketing, jedna część sprytu i pięć części rangi opinii.

Ramy to tylko narzędzia. Nie sądzę, że jest to wina frameworka, jeśli jest nadużywany, a nie osoby, która go nadużywa. Stare powiedzenie „jeśli masz młotek, wszystko wygląda jak gwóźdź” pokazuje, że ten sposób myślenia istniał na długo przed nawet komputerami.

Stawanie się zbyt wyspecjalizowanym może rzeczywiście stać się problemem w perspektywie długoterminowej - zarówno dla dewelopera, jak i dla gatunków biologicznych. Aby przetrwać w perspektywie długoterminowej, należy starannie zrównoważyć wysiłek na rzecz rozwijania umiejętności w wielu obszarach.

Aby odpowiedzieć na twoje konkretne pytanie, nie sądzę, aby istniały jakieś dane. Wolę używać frameworka, gdy upraszcza on rozwiązywanie problemów. Jeśli użycie frameworka pomoże mi rozwiązać problem z 2 liniami kodu zamiast 20, oczywiście go użyję. Ale nawet jeśli ma 20 linii w stosunku do 20, mógłbym zdecydować się na użycie frameworka, jeśli da mi to lepsze abstrakty, bliższe problematycznej dziedzinie, ułatwiając zrozumienie i utrzymanie kodu.

Myślę, że ramy mogą być nadużywane w niektórych kontekstach, tak. Ramy to tylko narzędzie, tak. Framework pozwala bardzo szybko uruchomić coś, a zatem jest doskonałym narzędziem do prototypowania.

Wydaje mi się, że gdzieś wzdłuż linii, kiedy twoja aplikacja osiąga pewien poziom złożoności, ograniczenia związane z ramami zaczynają hamować dalszy rozwój. Sztuką jest rozpoznanie, kiedy napotkałeś taki punkt krytyczny, a następnie podjęcie decyzji, co zamierzasz z tym zrobić.

Najczęściej pracuję z aplikacjami internetowymi i chociaż staram się być ogólny, moja odpowiedź może nie dotyczyć twojego obszaru programowania.

Zamierzam również używać „frameworka” jako synonimu „biblioteki”.

Przed wdrożeniem frameworka należy wziąć pod uwagę kilka rzeczy, oto kilka ogólnych przykładów.

# 1. Czy ramy pozwolą zaoszczędzić czas i wysiłek?

Odpowiedź na to pytanie jest prawie zawsze tak . Ramy są zwykle budowane w celu rozwiązywania konkretnych problemów i rozwiązywania ich bardzo dobrze. Na przykład frameworki takie jak EntityFramework mogą całkowicie uratować Cię przed pisaniem kodu SQL. Co może być fantastyczne, jeśli Twój zespół programistów nie mówi płynnie po SQL.

Szkielety są budowane w celu: a) dodania przyjaznego dla programisty interfejsu do innych złożonych komponentów lub b) dodania abstrakcji do już dobrze znanych (lub ustalonych) komponentów.

Ta ostatnia (lub nawet pierwsza w niektórych przypadkach) może faktycznie przeszkadzać w rozwoju. Dotyczy to zwłaszcza sytuacji, gdy Ty lub Twój zespół programistów zamierzacie wdrożyć nową platformę, w której nigdy wcześniej nie pracowali.

Może to potencjalnie spowolnić proces programowania, co może być kosztowne.

# 2 Skala Twojej aplikacji

Mówi się, że „wszystko, co warto zrobić, jest warte przesadzenia” , ale zwykle tak nie jest. Prawdopodobnie nie ma dobrego powodu, aby zaimplementować szkielet o dużych rozmiarach, jeśli celem twojej aplikacji jest wydrukowanie „ziemniaka” .

Gdy opracowujesz aplikację (internetową, stacjonarną, mobilną lub inną możliwą do wyobrażenia) - jeśli uważasz, że rozmiar twojej struktury „krasnoluduje” twoją (być może w przyszłości) jej implementację, może to być duża znak ostrzegawczy, że twoja platforma może po prostu nadąć twoją aplikację. Dobrą anegdotą byłoby dołączenie jQuery, aby dodać „załadowaną” klasę do tagu body, gdy dokument będzie gotowy. Robienie tego przy użyciu tylko natywnego JavaScript może być nieco trudniejsze , ale nie powoduje wzdęcia Twojej aplikacji.

Z drugiej strony, jeśli framework wykonuje wiele brudnych zadań wewnątrz (tj. Frameworki baz danych), wdrożenie go może być opłacalne, nawet jeśli używa się go tylko „częściowo”. Dobrą anegdotą byłoby nie budowanie własnego sterownika ADO.NET lub MongoDB tylko dlatego, że nie trzeba wykorzystywać całej biblioteki.

Czasami frameworki są dostępne jako oprogramowanie typu open source (z licencjami typu „rób, co chcesz”). Otwiera to nową możliwość, w której zespół programistów może wybrać tylko części frameworka.

To ostatecznie wiąże się z pytaniem nr 1 i nr 3.

# 3 Wpływ.

Czasami wdrożenie frameworka może bezpośrednio wpłynąć na użytkownika końcowego. Jest to szczególnie prawdziwe w przypadku aplikacji internetowych, ponieważ posiadanie dużych struktur po stronie klienta może negatywnie wpłynąć na wrażenia użytkownika końcowego. Użytkownicy wolniejszych komputerów mogą napotkać powolne renderowanie, problemy z wydajnością javascript lub podobne problemy spowodowane przez maszyny słabszej jakości. Użytkownik z powolnymi połączeniami może mieć wolne (przynajmniej początkowe) czasy ładowania.

Nawet w aplikacjach innych typów zależność od aplikacji może negatywnie wpłynąć na użytkowników końcowych. Ramy przynajmniej zawsze zajmują trochę miejsca na dysku, a jeśli tworzysz aplikację mobilną (lub nawet aplikację komputerową), może to być konieczne do wzięcia pod uwagę.

Struktury po stronie serwera (nawet bardziej specyficzne dla sieci) najprawdopodobniej nie wpłyną na użytkowników końcowych, ale wpłyną na twoją infrastrukturę . Niektóre frameworki mają same zależności , które mogą wymagać ponownego uruchomienia serwera WWW, albo tylko usługi, albo serwera całkowicie.

Niektóre frameworki mogą być również bardzo obciążające zasoby.

To oczywiście wiąże się z punktami 1 i 2.

To wszystko jest po prostu dużym „kręgiem rozważań” i nie ma prawdziwej naukowej metody decydowania o tym, czy powinieneś wdrożyć ramy, czy nie.

Corbin March bardzo dobrze to podsumował:

Grupy, z którymi współpracowałem, robią to samo - zgadnij koszty i korzyści, wybierz najbardziej produktywną trasę i miej nadzieję, że mają rację. To nie jest strasznie naukowe - jedna część intuicji, trzy części doświadczenia, jedna część podatności na marketing, jedna część sprytu i pięć części rangi opinii.

Ważne jest również, aby nie być elitarnym . Ramy są narzędziami, które mają być używane. Znam ludzi obu skrajności; z jednej strony masz faceta, który bardzo utrudnia życie, z drugiej strony masz faceta, który tworzy powolne, rozdęte aplikacje.

Wszystkie frameworki mają przypadki użycia, to tylko kwestia ich wdrożenia we właściwych celach.

Czy inni programiści znają platformę?

Jeśli wszyscy programiści znają framework X, to biorąc pod uwagę wszystkie inne powody korzystania z frameworka, są realne, idź! Dla mnie nie ma sensu wymuszanie uczenia się konkretnego frameworka, gdy większość czasu poświęcanego na programowanie zostanie poświęcona na naukę zawiłości frameworka.

Jeśli chodzi o twoją wypowiedź na temat nowszych programistów, którzy nie znają podstaw, jesteś o wiele bardziej współczujący niż ja! Tak, szkoda, ale czy mam zamiar spędzać czas martwiąc się o czyjąś nieudolność? Nie. (Na podstawie założenia, że ​​ci nowi członkowie społeczności nie współpracują od razu z tobą).

Użyłbym frameworka, jeśli (i TYLKO jeśli) spełnione są następujące warunki:

Ramy wydają się być wspierane przez jakiś czas. Już wcześniej miałem na nich koniec życia i to jest NAPRAWDĘ denerwujące. Zwłaszcza, gdy masz 9 miesięcy na swój projekt, a zmiana nie jest już opcją. A jeśli framework już JUŻ nie jest obsługiwany, pomyśl trzy razy, zanim napiszesz coś nowego za pomocą tego frameworka. Nie ważne jak dobrze to wiesz.

Projekt faktycznie pasuje do frameworka. Jako dość stary przykład, czy widziałeś rzeczy, które zostały stworzone do MFC? Ludzie nie mieli końca dziwnymi rzeczami, aby działały w aplikacjach, w których to po prostu nie miało sensu. Zwykle spędzają więcej czasu na pobijaniu MFC niż na pisaniu aplikacji, którą chcieli od razu.

Zespół projektowy jest zdolny do pracy w ramach. Niektórzy ludzie nie potrafią lub nie mogą poświęcić czasu na zrozumienie, w jaki sposób aplikacja powinna być napisana w danym frameworku, i zamiast tego piszą to, co zwykle robią, zamiast tego, czego potrzebuje framework. Takie niedopasowanie kodu i frameworka zwykle kosztuje wszystkich dużo czasu i wysiłku.