Czy mnogość ram nie ogłusza programistów? [Zamknięte]

Biorąc pod uwagę wszystkie dostępne obecnie frameworki, ORM , wstrzykiwanie zależności (DI), odwrócenie kontroli (IoC) itp., Stwierdzam, że wielu programistów traci lub nie ma umiejętności rozwiązywania problemów potrzebnych do rozwiązywania trudnych problemów. Wiele razy widziałem nieoczekiwane zachowanie wkradające się do aplikacji, a programiści nie byli w stanie naprawdę zagłębić się i znaleźć problemów. Wydaje mi się, że gubi się głębokie zrozumienie tego, co dzieje się pod maską.

Nie zrozum mnie źle , nie sugeruję, że te frameworki nie są dobre i nie posunąłem branży do przodu, tylko pytam, czy w wyniku niezamierzonej konsekwencji programiści nie zdobywają wiedzy i umiejętności potrzebnych do głębokiego zrozumienia systemy.

Zgoda. Obecnie pracuję nad pakietem oprogramowania, który jest tak obciążony przez frameworki, że prawie niemożliwe jest zrozumienie biznesu. Kiedy frameworki usuną Cię z rzeczywistego rozwiązywania problemów biznesowych, a nie tylko z MVC , zaszło już za daleko. Jak twierdzisz, wielu programistów IMO próbuje zaprojektować / zaprojektować program, aby rozwiązać ORM i MVC, i rzadko pytają, czy to rzeczywiście pomaga w jakikolwiek sposób rozwiązać problem, na którym polega oprogramowanie.

Tak, wiem, że wyświetlanie surowego SQL na stronie JSP jest „nie-nie”, ale jeśli jesteś konsultantem terenowym, gdzie to pasuje do konkretnego rozwiązania? I nie, to nie znaczy, że framework nie jest odpowiedni, nie wszyscy klienci mają 20 000 $ siedzących na każdym kroku, aby upewnić się, że niewielki punkt danych jest wyświetlany na stronie.

Jest to argument, który pojawia się regularnie, w wielu dziedzinach i w wielu formach.

Ogólna forma tego argumentu to:

Czy posiadanie [x: narzędzie / technologia] pogarsza ludzi w [y: funkcja, na którą wpływa x]?

Na przykład:

• Czy oprogramowanie CAD robi gorszych inżynierów?
• Czy kalkulatory w szkole średniej pogarszają matematykę?
• Czy oprogramowanie społecznościowe ogranicza osobiste umiejętności społeczne?
• Czy oprogramowanie księgowe produkuje gorszych księgowych?

Z pamięci wszechobecna odpowiedź brzmi prawie zawsze: niezupełnie. Zawsze będziesz mieć ludzi, którzy są dobrzy i źli w robieniu [y], ale teraz są po prostu źli w innym aspekcie umiejętności.

Głębsze zrozumienie podstaw każdej pracy pomoże, bez względu na to, co robisz - nawet te, które są uważane za „zaradcze”. Wiedza zawsze pomaga.

Abstrakcja jest kluczową koncepcją programowania komputerowego, a ramy pomagają programistom to osiągnąć. To coś dobrego. Wątpię, aby wielu z nas chciałoby opracować złożone systemy w języku asemblera! Myślę, że problem pojawia się, gdy programiści nie mają pojęcia, co kryje się pod warstwą abstrakcji. Innymi słowy, musisz mieć pojęcie o tym, co dzieje się pod maską, nawet jeśli nie wchodzisz w bezpośrednią interakcję ani nie komunikujesz się z tym.

Pamiętam tworzenie niektórych pierwszych dynamicznych stron internetowych w połowie lat 90. przy użyciu C i CGI (w czasach, gdy większość stron wciąż była statycznym HTML). Tak naprawdę nie było dojrzałych języków skryptowych po stronie serwera (takich jak PHP lub ASP) i bardzo mało bibliotek, więc trzeba było napisać cały strumień odpowiedzi HTTP na serwer z każdą stroną. Analiza parametrów GET i POST wymagała napisania własnej biblioteki. To było nudne, powolne, pracowite i bardzo podatne na błędy. Ani trochę za tym nie tęsknię!

Jednak czuję też frameworki, takie jak formularze internetowe ASP.NET, które abstrakują całą bezstanową naturę sieci do tego stopnia, że ​​wielu nowych programistów nie ma pojęcia, co właściwie dzieje się pod maską. Prowadzi to do nieefektywnego, rozdętego kodu, który działa słabo, ponieważ programista łączy elementy razem przy użyciu metod „przeciągnij i upuść”, nie zdając sobie sprawy z tego, co dzieje się na poziomie HTTP.

Uważam więc, że frameworki są niezbędne do tworzenia oprogramowania na wysokim poziomie, ale nie zwalniają programistów z rozumienia tego, co jest abstrakcji. Tak, ramy mogą sprawić, że będziesz głupi, ale tylko jeśli ich nie zrozumiesz.

Czy automatyczna skrzynia biegów lub wycieraczki z czujnikiem deszczu czynią nas gorszymi kierowcami?

Nie sądzę, że kodowanie bez ram musi oznaczać lepsze zrozumienie bazowych systemów. Dowodem na to jest to, że pracodawcy muszą zadawać proste pytania dotyczące kodowania podczas wywiadów, aby upewnić się, że kandydat potrafi połączyć spójną metodę.

Ostatecznie programista musi się uczyć. Dobre robią, złe nie.

I podobnie, wybór frameworka tylko dlatego, że istnieje bez analizy jego możliwości i zalet / wad jest również oznaką złych praktyk rozwojowych.

Myślę, że problem polega na tym, że nowi programiści zaczynają od coraz wyższych poziomów abstrakcji, a zatem nie narażają się na bity i bajty rzeczy „pod maską”. Więc nie uczą się niektórych naprawdę podstawowych podstaw programowania, które byłyby pierwszymi rzeczami, których nauczyłem się w minionych latach.

Kręcę głową za każdym razem, gdy oczywiście nowy programista pyta o coś, powiedzmy, o przechowywanie niektórych danych i wszyscy natychmiast mówią im, aby korzystali z narzędzia ORM . Nie, nie, nie, nie, nie ... najpierw muszą się nauczyć, jak to zrobić.

Być może rozkład „głupoty” tak naprawdę się nie zmienił, a my po prostu proponujemy większe i bardziej skomplikowane sposoby, aby programiści mogli strzelać sobie w stopy?

To nie frameworki ogłuszają programistów. Głupi programiści będą głupi, bez względu na to, czy używają ram, czy nie.

Z pewnością jest prawdą, że zrozumienie niskiego poziomu pracy, jaką narzędzie lub struktura pomaga usprawnić, czyni cię lepszym użytkownikiem narzędzi i struktur. Możesz także łatwiej debugować problemy i obejść nieuniknione luki w funkcjonowaniu narzędzi.

Na przykład wziąłem lekcję z Compiler Design na studiach, gdzie zakodowaliśmy parser LR od zera w C, zanim nauczyłem się korzystać z generatorów parsera, takich jak lex i yacc. To było bardzo edukacyjne i od tego czasu lepiej rozumiem i doceniam wszystkie języki programowania, których używałem.

Ale nie mówię, że każdy programista musi trudzić się woskowanie samochodu pana Miyagi przez wiele lat, zanim będą mogli pracować na wysokim poziomie. Wiele prac programistycznych ma charakter intelektualny, decyduje o tym, jakie oprogramowanie musi zrobić , a nie mechaniczna praca nad kodowaniem w określonym języku lub narzędziu.

Ta praca intelektualna jest tam, gdzie inteligencja kontra głupota jest jeszcze ważniejsza.

Cytując znakomitą „Spending Moore's Dividend” Jamesa Larusa (wyróżnienie dodane):

Trzydzieści lat temu Bill Gates zmienił monit w Altair Basic z „READY” na „OK”, aby zaoszczędzić 5 bajtów pamięci. Dzisiaj nie do pomyślenia jest, aby programiści byli świadomi tego poziomu szczegółowości swojego programu, nie mówiąc już o tym zaniepokojony, i słusznie, ponieważ zmiana tej wielkości jest dziś niezauważalna ... Nie ma mowy abyśmy mogli wyprodukować dzisiejsze systemy przy użyciu rzemieślniczych, ręcznie wykonanych praktyk, które były możliwe (konieczne) na komputerach z pamięcią 4K.

Myślę, że prawdopodobnie mylące jest stwierdzenie, że ramy pozwalają uniknąć umiejętności niezbędnych do rozwiązywania trudnych problemów lub pozwalają uniknąć głębokiego zrozumienia. Zamiast tego jedynym powodem, dla którego jesteśmy w stanie zbudować dzisiejsze złożone systemy (których złożoność może generować trudne problemy i przeciwstawić się głębokiemu zrozumieniu) jest to, że mamy frameworki (i wysokowydajne języki zbierające śmieci OO oraz IDE z kontekstową pomocą i sprawdzanie składni w locie i wszystkie inne postępy w tworzeniu oprogramowania, które czasami są krytykowane jako głupie programistów).

Ramy są świetne. Ale musisz wiedzieć, co jest pod maską. Problem polega na tym, że programiści zbyt mocno polegają na frameworkach, bez wystarczającej wiedzy o podstawowym systemie.

Nieco przestarzały przykład to MFC : programista może zaoszczędzić dużo czasu, używając MFC zamiast Windows API, ale bez znajomości API (co oznacza posiadanie tła prawdziwej pracy z surowym API), często utkną . Prawie nigdy tak się nie stało, ponieważ typowy programista MFC posiadał znajomość Windows API.

Jednak dzięki Windows Forms w .NET , dzięki lepszej enkapsulacji i lepszemu modelowi obiektowemu, programista może prawie zignorować to, że używa tylko innego opakowania Windows API. Tak więc szanse na utknięcie są mniejsze, ale kiedy to się stanie, może to boleć.

Niestety czas wprowadzenia na rynek jest zawsze krótszy, a projekty są coraz bardziej złożone, więc programiści nie mają czasu na głębokie zagłębianie się. To smutny stan branży oprogramowania ...

To stawia inteligentnych tam, gdzie musi być. Nie trzeba rozumieć mechaniki kwantowej i fizyki newtonowskiej, aby stworzyć mechanizm, który upuszcza piłkę ze szczytu budynku. Każda nowa warstwa oprogramowania powinna opierać się na ostatniej i usuwać płytę kotłową z budowy przydatnych aplikacji.

Ci, którzy potrzebują lub chcą poznać „rzeczy” stojące za strukturą, będą studiować i badać metodą haczykowatą lub oszustem.

Nie, absolutnie nie. Podstawą frameworka jest kombinacja biblioteki podprogramów i szablonu, dwóch sprawdzonych narzędzi programistycznych. „To biedny robotnik obwinia swoje narzędzia ...

... i jest wielu biednych robotników używających i obwiniających frameworki.

Podczas tworzenia oprogramowania ramy oszczędzają czas. Ucząc się budować oprogramowanie, ramy przeszkadzają w zrozumieniu.

Myślę, że problem dotyczy głównie komputerów, które stały się zbyt potężne. Dla większości programistów nie ma już żadnego rozsądnego powodu, aby „przejść do podstaw”. Wykonanie tych samych czynności zajmuje więcej czasu, a w czasie wykonywania nie ma znaczącej różnicy. Jedynym sposobem na rozwiązanie tego problemu jest wprowadzenie sztucznych ograniczeń, tak jak robią to zawody takie jak js1k.

Może szkoły powinny mieć dedykowany przedmiot „zoptymalizowany projekt”, w którym musisz budować programy pod silnymi ograniczeniami przestrzennymi i czasowymi?

Nie, nauka ram poprawia umiejętności programisty. Framework jest rozszerzeniem języka programowania. Niektóre języki są już oparte na frameworku. Pracuję zarówno z PHP, jak i Javą. PHP potrzebuje frameworka takiego jak silnik szablonów (czasami). Java nie potrzebuje frameworka (większość razy), ma już wiele metod i bibliotek.

Większość platform ma funkcje, z których programiści korzystają wielokrotnie.

Wydaje mi się, że aby odgrywać tutaj rolę adwokata diabła, ramy (w każdym razie „dobre”) mogą w rzeczywistości przejść długą drogę w kierunku rozwoju edukacji programisty. Dobrze zaprojektowana platforma rozwiąże wiele problemów, a korzystając z niej, programista może zrozumieć, jakie problemy są rozwiązywane i jak. Moim zdaniem platforma jest (powinna być) krystalizacją najlepszych praktyk programistycznych i może uczyć programisty przykładem.