Zalety i wady wynikające z korzystania z frameworka internetowego? [Zamknięte]

16

To pytanie koncentruje się na wyodrębnieniu zalet i wad korzystania ze struktur opartych na sieci Web : takich jak Cake PHP, Zend, jQuery, ASP.NET). To pytanie jest całkowicie niezależne od języka . Zacznę od pojęcia „Stanie na ramionach gigantów ”.

Zalety:

  • Wspiera programistów - dzięki funkcjom, które wcześniej zajęłyby setki wierszy kodu i kompresji ich w jednym prostym wywołaniu funkcji, umożliwia programistom integrację bardziej złożonych funkcji w ich witrynach internetowych.
  • Pozwól na szybsze tworzenie aplikacji - jest to bardzo istotne dla osób, które potrzebują stron internetowych utworzonych w bardzo małym oknie (czy ktoś ma tego przykłady?)
  • Niższe koszty - umożliwia programistom przeniesienie oszczędności na klienta, generuje zupełnie nową grupę klientów, którzy chcieli mieć stronę internetową, ale wcześniej nie mogli sobie pozwolić na wyższe koszty rozwoju.

Niedogodności:

  • Utracone zrozumienie - opierając się na funkcjach frameworka, deweloperowi grozi utrata zrozumienia tego, jak rzeczy działają (pod maską).
  • Klif konfiguracji - jeśli pójdziesz dalej niż konfiguracja swojego frameworka, Twoja produktywność spada, może być trudno wdrożyć funkcje poza konfiguracją frameworka.
  • Ścieżki dla programistów - ty (programista) musisz robić rzeczy w sposób, w jaki programista chce, abyś to robił.

Zastanawiam się, co ludzie sądzą o moich opiniach i czy ktoś się z nimi nie zgadza? Również jeśli ludzie mają dodatkowe punkty, byłbym wdzięczny.

JHarley1
źródło

Odpowiedzi:

12

Oto sedno: wdrożenie funkcji poza konfiguracją frameworków może być trudne.

Przejdźmy przez to założenie przez założenie.

Utracone zrozumienie - polegając na funkcjach frameworka, programista może stracić zrozumienie tego, jak działa (pod maską).

Fałszywy. Nigdy nie stracisz zrozumienia, jak to działa. Ramy nie są magiczne. To po prostu przydatny kod, którego nie musisz pisać sam.

Wierzcie lub nie, popełniacie błędy przy użyciu frameworka. Będziesz musiał debugować aż do najniższych poziomów HTTP, aby zrozumieć, co zrobiłeś źle.

Nigdy nie stracisz z oczu tego, co dzieje się pod maską. Chyba że twoje środowisko jest tak epickie i idealne, że nigdy nie będziesz mieć problemu.

Klif konfiguracji - jeśli pójdziesz dalej niż konfiguracja swojego frameworka, Twoja produktywność spada, może być trudno wdrożyć funkcje poza konfiguracją frameworka.

To bezcenne ma sens.

Pierwszy. Budowanie bez frameworka może sprawić, że banalne zadanie stanie się dużym zadaniem programistycznym, które obejmuje testowanie jednostki, debugowanie, diagnostykę, kontrolę konfiguracji i całą resztę pracy bez wartości, odkrywając na nowo to, co znajduje się w frameworku. Jaka jest ta „produktywność”?

Druga. Wdrażanie rzeczy poza frameworkiem jest zawsze dużo pracy, ponieważ - hm - wdrażanie czegokolwiek poza frameworkiem jest zawsze dużo pracy. Nie ma to nic wspólnego z czasem poświęconym na naukę i konfigurowanie frameworka. Wdrażanie czegokolwiek poza ramami jest z natury trudne.

Ścieżki dla programistów - ty (programista) musisz robić rzeczy w sposób, w jaki twórca [frameworku] chce, abyś to robił.

Poprawny. I to często jest dobra rzecz. Robienie rzeczy w sposób konsekwentny jest cenniejsze niż robienie ich według własnych preferencji. Może wymagać „nauki” i „zrozumienia”, ale mają one wartość.

Kwestie bezpieczeństwa - udostępnienie ludziom tych narzędzi do szybkiego tworzenia profesjonalnie wyglądających stron internetowych stanowi potencjalne ryzyko, ludzie mogą szybko tworzyć profesjonalnie wyglądające strony internetowe dla nieuczciwych firm.

Co? To nie ma nic wspólnego z frameworkiem. Oszustwo to oszustwo, niezależnie od użytych narzędzi.

S.Lott
źródło
3
Nie zgadzam się z tobą w sprawie „Lost Understanding”. Jeśli weźmiesz jQuery jako przykład, wystarczy spojrzeć na dziesiątki pytań na temat przepełnienia stosu, gdzie jest oczywiste, że pytający nie może odróżnić jQuery, JavaScript i DOM.
RoToRa
5
@RoToRa: Jeśli spojrzysz na jakiś konkretny temat dotyczący SO (tj. Programowania C), zobaczysz dużą liczbę ludzi, którzy nie mogą zrozumieć, co się dzieje. Rzeczywiście, niektórzy ludzie nawet nie rozumieją, co to jest liczba zmiennoprzecinkowa. Nie sądzę, że to ramy. Myślę, że są ludzie, którzy mają ograniczone możliwości zrozumienia technologii.
S.Lott,
Naprawdę dobre punkty, Scott, podkreśliłeś wiele problemów. Miałem na myśli frameworki i oszustwa, które sprawiły, że szybko stworzyłem profesjonalnie wyglądającą stronę internetową, ale było to bardzo oddalone od tematu (dobra uwaga).
JHarley1
@ JHarley1: „ale to było o wiele mil od tematu”. Możesz zaktualizować pytanie, aby to naprawić.
S.Lott,
1
„Lost Understanding” zakłada, że ​​ludzie rozumieją, co się dzieje, gdy używają np. Zwykłej Java. Ale sama Java robi wiele rzeczy pod maską i tak naprawdę nie możesz wiedzieć na pewno, co dzieje się na niskim poziomie, chyba że wiesz dokładnie, co JVM na której platformie będzie używany; ale nie przejmowanie się takimi szczegółami jest jedną z zalet takich języków i to samo można powiedzieć o frameworkach.
user281377,
3

Con: Ewentualny możliwy spadek wsparcia / utrata popularności

  • Jeśli istnieją dwa frameworki, które robią to samo, a twój nie wygrywa, istnieje szansa, że ​​projekt umrze. W tej sytuacji możesz samodzielnie utrzymywać framework (open source), przepisać aplikację lub kontynuować bez aktualizacji (zamknięte źródło).
  • W zależności od frameworka może być konieczne uaktualnienie aplikacji zgodnie z harmonogramem jego wydania. Pozostawanie zbyt daleko w tyle może uniemożliwić uzyskanie wsparcia. Bez ram możesz pracować zgodnie z harmonogramem. (Zależy to od tego, czy potrzebujesz wsparcia, czy nie).

Pro: Kod dla biznesu

  • Szkielety pozwalają ci nie martwić się o cholerną pracę i skupiają się na kodzie, który bezpośrednio wnosi wartość dla biznesu.
  • Czasami aktualizacje frameworku, które (po prostu działają) umożliwiają dostarczanie użytkownikom nowych funkcji praktycznie „za darmo”. Zwłaszcza w ramach dostarczanych z niestandardowymi kontrolkami (jak siatka, że ​​nowa wersja może oferować pewien rodzaj wyszukiwania / filtrowania).
Ryan Hayes
źródło
Pozdrawiam Ryan, jest tu kilka dobrych punktów. Nigdy nie uważałem, że Framework jest upuszczany / spada z łaski.
JHarley1 10.01.11
Czy mogę uzyskać informacje zwrotne na temat recenzji?
Ryan Hayes,
Uznałem, że jest to przydatne - głosowałem za.
JHarley1
3

Zalety

  • Szybszy czas programowania
  • Mniej błędów
  • Szybszy wspólny rozwój
  • Obsługa bibliotek
  • Łatwa interakcja DB

Niedogodności

  • „Zapakowane” w ramy
  • Często nieelastyczny, gdy chce się rozszerzyć lub zmodyfikować podstawowe zachowanie
  • „Błędy zguby” - błędy, które powstają z rdzenia lub podstawowej architektury bez dobrego prześledzenia źródła. Doskonałym przykładem są błędy wiosenne podczas korzystania z Grails.

Opowiadam się za stosowaniem ram do wszystkich projektów oprócz najprostszych. Jeśli chcesz dodać formularz kontaktowy do istniejącej witryny HTML, możesz użyć jednego pliku PHP zamiast przejść do frameworka.

Josh K.
źródło
2

Przypomina mi się kilka rzeczy ...

Zalety

  • Ponowne użycie kodu - używając frameworka, ponownie wykorzystujesz sprawdzony i prawdziwy kod.
  • Szybki rozwój / prototypowanie.
  • (często) zintegrowane sprawdzanie poprawności danych wejściowych, które można uznać za bezpieczne (pod warunkiem, że programista używa go poprawnie)

Niedogodności

  • Utrata wsparcia. Przychodzi na myśl Symfony 1.4. Wyobrażam sobie, że Symfony będzie obsługiwać 1.4 przez dłuższy czas, ale wiedząc, że 2.0 nie jest kompatybilny wstecz, 1.4 wydaje się być ślepym wsparciem w nadchodzących latach.
  • Nad głową; Korzystając z frameworka, uruchomisz tysiące linii, które mogą nie mieć zastosowania do konkretnej aplikacji, ale dotyczą innych. Niektórzy uważają to za rozsądny kompromis, a niektórzy decydują się napisać swój kod od podstaw dla wydajności.
  • Używanie niewłaściwych ram dla konkretnych potrzeb. Nie wszystkie frameworki są tworzone jednakowo.
Craige
źródło
1

Wszystko zależy od używanego frameworka.

Jeśli korzystasz z ASP.NET, masz wadę: w najlepszym razie jest to nieszczelna abstrakcja , aw najgorszym przypadku robienie rzeczy, które są trywialne w innych ramach, nie ukrywają faktu, że jesteś praca w sieci.

ASP.NET MVC stara się rozwiązać ten problem i robi to dobrze.

Ramy istnieją, abyśmy mogli spędzać więcej czasu na wykonywaniu pracy, a mniej na budowaniu rusztowań. Pod tym względem nie widzę żadnych wad, chyba że naprawdę chcesz spędzać czas na budowaniu rusztowań.

George Stocker
źródło
Widzisz mój problem z ASP.NET MVC polegał na tym, że musiałem oduczyć się niektórych pojęć i robić rzeczy, które zajmował ASP.NET MVC, co zajęło mi trochę czasu. Być może można powiedzieć, że wadą frameworka byłby spadek produktywności, gdy się z nim uporamy.
JHarley1
1

Chciałbym dodać kilka punktów.

  • Jednym z największych problemów z frameworkami, które znalazłem, jest to, że ludzie przestają myśleć. Chcą tylko użyć frameworka, ponieważ jest fajny lub ponieważ zawsze używają frameworka. Nie przestają myśleć, czy użycie jest uzasadnione.
  • Licencjonowanie, ludzie po prostu wydają się korzystać z frameworków, nie patrząc na licencje. Może to mieć implikacje, że nie są świadomi. Lub zastanów się, co się stanie, gdy zmieni się licencja.
  • Korzystanie z wielu tego samego rodzaju ram. Czasami mogą to być różne frameworki, które w rzeczywistości robią prawie to samo. Jako firma dokonujesz świadomych wyborów i nie masz innych ram dla każdego projektu.
  • Nadążanie za nowymi wersjami może być wyzwaniem

Nadal uważam, że włożenie nieco więcej wysiłku w ocenę ram, ocenę licencji, utrzymywanie czystej listy ram dla każdego zastosowania i inteligentną strategię wersjonowania są tego warte, jeśli weźmiemy pod uwagę zalety.

Zalety:

  • kiedy konsekwentnie używasz ram, czas nauki dla projektów zmniejsza się dla osób, które już pracowały nad twoimi projektami.
  • twój własny szybszy rozwój
  • twoi programiści
KeesDijk
źródło
@Keedijk: Nigdy nie zastanawiam się nad licencjonowaniem, czy są jakieś przykłady płatnych ram?
JHarley1 10.01.11
@ JHarley1 oakleafsd.com Nie wiem, czy nazwałbym to „frameworkiem sieciowym”, ale Mere Mortals .NET ma rozszerzenia, które pomagają szybciej tworzyć aplikacje internetowe. Jednak sam .NET Framework sprawia, że ​​większość tych ram staje się przestarzała.
Ryan Hayes,
@Jarley Być może trochę uogólniłem w swojej odpowiedzi, ale myślałem o takich rzeczach jak telerik webcontrols lub itext itextpdf.com/terms-of-use/index.php . Pracowałem również w firmie, w której zmiana licencji ExtJs była problemem sencha.com/forum/showthread.php?33096-License-Change
KeesDijk
-2

Mówię z własnego doświadczenia w ciągu ostatnich 13 lat. W mojej firmie zastosowaliśmy rozpórki, po krótkim zakręcie było świetnie. W mojej następnej zastosowaliśmy architekturę, która była w większości nieprzezroczysta, nieco rozpięta, ale wyhodowana, mogliśmy ją rozszerzyć, ale podstawowy kod to tylko słoiki. I tak dalej. w ciągu ostatnich 3 lat pracowałem w małej firmie (liczba deweloperów <30) i to były wszystkie nasze jsp, serwlety i ejbs. Patrząc na wielu naszych klientów i powtarzanie plików JSP, w 2012 roku stworzyliśmy filtr j2ee, który naśladował 20% struts2. Dlaczego nie użyć stuts 2? Szkoda, że ​​nie mieliśmy, ale: nie mogliśmy tego przekazać naszemu głównemu architektowi; za mało doświadczenia lub czasu.

Więc mieliśmy przechwytujące niektóre typowe pliki JSP, których używał nasz mini framework. Teraz, kiedy miałem czas przejść książkę „Struts 2”, widzę, że tak bardzo za nami tęskniliśmy!

Używamy świetnych algorytmów, pamięci podręcznych i interfejsu użytkownika, ale straciliśmy wiele godzin i obciążono dużą ilością kodu, który planujemy wycofać na 3 lata.

tgkprog
źródło