Jak programista przyzwyczajony do języków statycznych radzi sobie z brakiem narzędzi Javascript

Przez większą część mojej kariery programowałem prawie wyłącznie w językach kompilowanych, szczególnie w Javie. Jedną z moich ulubionych rzeczy w Javie jest to, jak możesz być produktywny i jak mało kodu musisz pisać, używając narzędzi takich jak Eclipse.

Możesz:

• Łatwo i automatycznie refaktoryzuj swoje metody i klasy
• Wyświetl natychmiast wszystkie miejsca, w których wywoływana jest metoda lub używana jest stała (Open Call Hierarchy / Show References)
• Wpisywanie statyczne oznacza, że ​​można użyć uzupełniania kodu, aby wyświetlić wszystkie parametry / funkcje dostępne w obiekcie
• Naciśnij klawisz Control i kliknij nazwę funkcji / członka / klasy, aby przejść bezpośrednio do jej definicji

Wszystkie te udogodnienia sprawiają, że IDE jest moim najlepszym przyjacielem. Pisanie kodu Java, a zwłaszcza zrozumienie programów innych ludzi, staje się znacznie łatwiejsze.

Jednak coraz częściej wzywa mnie do korzystania ze Javascript, a moje dotychczasowe doświadczenia były dość negatywne.

W szczególności:

• Nie ma bezpośredniego sposobu znalezienia punktu wejścia funkcji (innego niż wyszukiwanie tekstowe, co może skutkować kolejnymi poszukiwaniami metod wyższych w hierarchii wywołań, po których dwóch lub trzech zapomniałeś, gdzie zacząłeś)

• Parametry są przekazywane do funkcji, bez możliwości dowiedzenia się, jakie właściwości i funkcje są dostępne w tym parametrze (poza faktycznym uruchomieniem programu, nawigacją do punktu, w którym funkcja jest wywoływana, i użyciem konsoli console.logs do wyprowadzenia wszystkich właściwości dostępny)

• Powszechne stosowanie anonimowych funkcji jako wywołań zwrotnych, które często prowadzi do spaghetti mylących ścieżek kodu, których nie można szybko nawigować.

• I oczywiście JSLint wychwytuje pewne błędy przed uruchomieniem, ale nawet to nie jest tak przydatne jak posiadanie czerwonych falistych linii pod twoim kodem bezpośrednio w przeglądarce.

Rezultatem jest to, że prawie cały czas musisz mieć cały program w głowie. To znacznie zwiększa obciążenie poznawcze podczas pisania złożonych programów. A wszystkie te dodatkowe rzeczy, którymi należy się martwić, pozostawiają mniej miejsca w moim mózgu na rzeczywistą kreatywność i rozwiązywanie problemów.

Jasne, szybciej jest po prostu złożyć obiekt razem niż napisać całą formalną definicję klasy. Ale chociaż programy mogą być nieco łatwiejsze i szybsze w pisaniu, z mojego doświadczenia są znacznie trudniejsze do odczytania i debugowania.

Moje pytanie brzmi: w jaki sposób inni programiści radzą sobie z tymi problemami? JavaScript wyraźnie zyskuje na popularności, a blogi, które czytam, opowiadają o tym, jak produktywni są ludzie, zamiast desperacko próbować znaleźć rozwiązania tych problemów.

GWT pozwala zamiast tego pisać kod dla środowiska JavaScript w Javie, ale wydaje się, że nie jest tak szeroko stosowany, jak bym się spodziewał; ludzie faktycznie wydają się preferować JavaScript dla złożonych programów.

czego mi brakuje?

Elementy oparte na IDE nie są dostępne * w dynamicznym języku, takim jak javascript. Musisz nauczyć się bez nich obchodzić. Będziesz musiał zastąpić wsparcie narzędzi lepszym projektem.

Użyj wzorca modułu - ręcznie lub za pomocą narzędzia takiego jak requjs . Utrzymuj moduły małe, abyś mógł łatwo je zrozumieć.

Nie definiuj tylu typów - używaj anonimowych obiektów utworzonych blisko miejsca połączenia. Następnie możesz spojrzeć na rozmówcę i rozmówcę i wiedzieć, co się dzieje.

Staraj się unikać łączenia kodu z DOM - Staraj się ograniczać ilość manipulacji DOM wykonywanych w kodzie. Jeśli możesz przekazać selektory lub kolekcje jQuery, zrób to zamiast informować kod o strukturze strony.

* _{Jeśli korzystasz z popularnej biblioteki, możesz uzyskać fałszywe autouzupełnianie, ale bardziej przypomina to „pokaż wszystkie metody jquery” niż „jakie właściwości ma ten obiekt”. Oszczędza pisania, ale nie daje gwarancji poprawności.}

Chciałbym dodać odpowiedź na to pytanie, ponieważ ostatnio przeszedłem przez dobrą, złą, ale przeważnie brzydką Javę i mam całkiem nowe mnóstwo rażących nadmiernych uogólnień na temat Java i deweloperów Java vs. JS i JS devs, które mogą być oparte na czymś nieco przypominającym użyteczną prawdę.

Istnieją IDE, ale pomocne może być zrozumienie, dlaczego nie było ich wielu

Próbowałem Webstorm teraz, kiedy zainteresowałem się tworzeniem Node i nie jest wcale tak źle, że go kupiłem, ale nadal mam tendencję do otwierania plików js w Scite częściej niż WS. Powodem tego jest to, że możesz zrobić o wiele więcej za dużo mniej w JS, ale także dlatego, że praca interfejsu użytkownika daje natychmiastową informację zwrotną, narzędzia programistyczne dla przeglądarki (w szczególności Chrome i Firebug) są naprawdę doskonałe, a (uwzględnianie kontekstów innych niż przeglądarka ) ponowne uruchomienie zmienionego kodu jest szybkie i łatwe bez kroku kompilacji.

Kolejną rzeczą, o której jestem dość przekonany, jest to, że IDE w zasadzie tworzą własne wymagania, włączając niechlujny kod, na który tak naprawdę nie można sobie pozwolić w JavaScript. Chcesz dowiedzieć się, jak zarządzamy w JS? Pomocne może być rozpoczęcie pisania czegoś, co nie jest trywialne w Javie bez IDE, i zwrócenie szczególnej uwagi na rzeczy, które musisz zacząć robić i myśleć o tym, aby faktycznie móc utrzymać / zmodyfikować ten kod bez przenoszenia IDE Naprzód. IMO, te same rzeczy są nadal niezbędne do napisania łatwego do utrzymania kodu, niezależnie od tego, czy masz IDE, czy nie. Gdybym musiał napisać 4-letni program nauczania, nie pozwoliłby ci dotknąć IDE przez pierwsze dwa lata w interesie, aby nie przekreślić narzędzi i zależności.

Struktura

Doświadczeni deweloperzy JS zajmujący się złożonymi aplikacjami mogą i strukturyzują swój kod. W rzeczywistości jest to jedna rzecz, w której musimy być lepsi w początkowej historii, w której brakowało IDE do odczytania dla nas kodu, ale także dlatego, że potężnie ekspresyjne języki mogą bardzo szybko wyrażać całkowicie niemożliwe do utrzymania bazy kodów katastrof, jeśli nie kodujesz w przemyślany sposób.

Właściwie miałem dość stromą krzywą uczenia się w zrozumieniu naszej bazy kodu Java, dopóki w końcu nie zdałem sobie sprawy, że żaden z nich nie był prawidłowym OOP. Zajęcia były niczym więcej jak wiązkami luźno powiązanych metod zmieniających globalnie dostępne dane siedzące w fasoli lub DTO lub statycznych getterach / setterach. To w zasadzie ta sama stara bestia, którą OOP miał zastąpić. Przestałem więc w zasadzie szukać i myśleć o kodzie. Właśnie nauczyłem się klawiszy skrótu i ​​przeszukiwałem mesy, a wszystko poszło znacznie płynniej. Jeśli więc nie masz już nawyku, pomyśl o OOD znacznie intensywniej.

Dobrze zbudowana aplikacja JS na najwyższym poziomie będzie zwykle składać się ze złożonych funkcji (np. JQuery) i obiektów oddziałujących ze sobą. Twierdziłbym, że cechą dobrze skonstruowanej, łatwej w obsłudze aplikacji w dowolnym języku jest to, że jest doskonale czytelna, czy patrzysz na nią za pomocą IDE czy Notepad ++. Jest to jeden z głównych powodów, dla których jestem bardzo krytyczny wobec wstrzykiwania zależności i pierwszego testowego TDD.

I w końcu puść lekcje. Dowiedz się dziedziczenia prototypowego. W rzeczywistości jest dość elegancki i łatwy do wdrożenia, gdy rzeczywiście potrzebujesz dziedziczenia. Uważam jednak, że metody kompozycyjne działają znacznie lepiej w JS i osobiście zaczynam chorować i mam nocne lęki EXTJS za każdym razem, gdy widzę więcej niż jeden lub dwa poziomy dziedziczenia w dowolnym języku.

Najpierw podstawowe zasady

Mówię o podstawowych rzeczach, z których powinny wynikać wszystkie inne dobre praktyki: SUCHE, YAGNI, zasada najmniejszego zdziwienia, czyste oddzielenie problematycznych domen, pisanie do interfejsu i pisanie czytelnego kodu to mój rdzeń osobisty. Coś nieco bardziej złożonego, co przemawia za porzuceniem tych praktyk, powinno być uważane za Kool Aid w dowolnym języku, ale szczególnie w języku takim jak JavaScript, w którym niezwykle łatwo jest pozostawić dziedzictwo bardzo mylącego kodu dla następnego faceta. Luźne sprzężenie, na przykład, jest świetnym rozwiązaniem, dopóki nie posuniesz się tak daleko, że nie możesz nawet powiedzieć, gdzie zachodzi interakcja między obiektami.

Nie bój się pisania dynamicznego

W JavaScript nie ma wielu podstawowych typów. W przeważającej części zasady dynamicznego rzutowania są praktyczne i proste, ale warto się ich nauczyć, abyś mógł lepiej nauczyć się zarządzać przepływem danych bez zbędnych rzutowań i bezcelowych procedur sprawdzania poprawności. Zaufaj mi. Typy ścisłe doskonale nadają się do problemów z wydajnością i wykrywaniem problemów podczas kompilacji, ale nie chronią cię przed niczym.

Poznaj bzdury dzięki funkcjom i zamknięciom JS

Pierwszorzędne funkcje JS są prawdopodobnie głównym powodem, dla którego JS wygrał nagrodę „Jedyny język warty dotarcia z nagrodą po stronie klienta”. I tak, faktycznie była konkurencja. Są także centralną cechą JS. Konstruujemy z nimi obiekty. Wszystko ma zakres funkcji. I mają przydatne funkcje. Możemy badać parametry za pomocą słowa kluczowego arguments. Możemy tymczasowo dołączyć i odpalić je w kontekście bycia metodami innych obiektów. I sprawiają, że podejście do rzeczy jest nieprzyzwoicie łatwe do wdrożenia. W skrócie, sprawili, że JS była absolutną bestią w zmniejszaniu złożoności i dostosowywaniu różnych implementacji samego JS (ale głównie DOM API) bezpośrednio u źródła.

Ponownie oceń wzorce / praktyki przed przyjęciem

Funkcje pierwszej klasy i typy dynamiczne sprawiają, że wiele bardziej złożonych wzorców projektowych jest całkowicie bezcelowe i niewygodne w JS. Niektóre prostsze wzorce są jednak niezwykle przydatne i łatwe do wdrożenia, biorąc pod uwagę bardzo elastyczny charakter JS. Adaptery i dekoratory są szczególnie przydatne i znalazłem singletony pomocne w złożonych fabrykach widgetów interfejsu użytkownika, które działają również jako menedżery zdarzeń dla elementów interfejsu użytkownika, które budują.

Podążaj za wiodącym językiem i rób więcej za mniej

Uważam, że jeden z głównych honorów Javy argumentuje gdzieś, że gadatliwość jest w rzeczywistości pozytywną cechą, która ułatwia zrozumienie kodu dla wszystkich stron. Bzdury. Gdyby tak było, łatwiej byłoby czytać w języku legalnym. Tylko pisarz może ułatwić zrozumienie tego, co napisali, i możesz to zrobić tylko od czasu do czasu wrzucając się do butów drugiego faceta. Przyjmij więc te dwie zasady. 1. Bądź tak bezpośredni i jasny, jak to możliwe. 2. Dotrzyj już do tego cholernego punktu. Zwycięstwo polega na tym, że czysty, zwięzły kod to rzędy wielkości łatwiejsze do zrozumienia i utrzymania niż coś, w którym trzeba przejść dwadzieścia pięć warstw, aby przejść od wyzwalacza do faktycznie pożądanego działania. Większość wzorców, które opowiadają się za tego rodzaju rzeczami w bardziej rygorystycznych językach, są w rzeczywistości obejściem ograniczeń, których nie ma JavaScript.

Wszystko jest plastyczne i to jest w porządku

JS jest prawdopodobnie jednym z najmniej protekcjonistycznych języków w popularnym użyciu. Przyjmij to. To działa dobrze. Na przykład możesz pisać obiekty z niedostępnymi trwałymi „prywatnymi” zmiennymi, po prostu deklarując zwykłe zmienne w funkcji konstruktora, i robię to często. Ale to nie ma na celu ochrony mojego kodu ani jego użytkowników „przed sobą” (mogliby po prostu zastąpić go własną wersją w czasie wykonywania). Ale raczej ma to zasygnalizować zamiar, ponieważ założeniem jest, że ten drugi facet jest wystarczająco kompetentny, aby nie chcieć rozplątywać żadnych zależności i zobaczy, że nie powinieneś bezpośrednio się do tego zwracać, być może z ważnego powodu.

Nie ma ograniczeń wielkości, tylko problematyczne domeny

Największym problemem, jaki mam ze wszystkimi bazami kodów Java, które widziałem, jest nadmiar plików klasowych. Przede wszystkim SOLID to tylko mylące powtórzenie tego, co powinieneś już wiedzieć o OOP. Klasa powinna obsługiwać określony zestaw powiązanych problemów. Nie ma jednego problemu z jedną metodą. To po prostu bierze zły stary łańcuch C func-spaghetti tylko z dodatkiem całej bezcelowej składni klasy do rozruchu. Nie ma limitu rozmiaru ani metody. Jeśli dodanie czegoś do już długiej funkcji, klasy lub konstruktora ma sens, ma sens. Weź jQuery. Jest to zestaw narzędzi o długości całej biblioteki w jednej funkcji i nie ma w tym nic złego. To, czy nadal potrzebujemy jQuery, wymaga rozsądnej debaty, ale jeśli chodzi o design,

Jeśli Java jest wszystkim, co wiesz, zagłębiaj się w coś ze składnią inną niż C

Kiedy zacząłem zadzierać z Pythonem, ponieważ podobało mi się to, co słyszałem o Django, nauczyłem się oddzielać składnię od projektowania języka. W rezultacie łatwiej było zrozumieć Javę i C jako sumę ich części do projektowania języka, a nie sumę rzeczy, które robią inaczej z tą samą składnią. Przyjemnym efektem ubocznym jest to, że im lepiej rozumiesz inne języki w zakresie projektowania, tym lepiej rozumiesz mocne i słabe strony tego, który znasz najlepiej dzięki kontrastowi.

Wniosek

Teraz, biorąc to wszystko pod uwagę, trafmy wszystkie twoje problemy:

• Nie ma bezpośredniego sposobu znalezienia punktu wejścia funkcji (innego niż wyszukiwanie tekstowe, co może skutkować kolejnymi poszukiwaniami metod wyższych w hierarchii wywołań, po których dwóch lub trzech zapomniałeś, gdzie zacząłeś)

Chrome i Firebug faktycznie mają funkcję śledzenia połączeń. Ale zobacz także moje uwagi na temat struktury i zachowania zwięzłości i bezpośredniości. Im więcej możesz pomyśleć o swojej aplikacji jako o większych, dobrze zamkniętych konstrukcjach oddziałujących na siebie, tym łatwiej jest ustalić, czyja to wina, gdy coś pójdzie nie tak. Powiedziałbym, że dotyczy to również Javy. Posiadamy klasyczne konstruktory funkcji, które doskonale nadają się do obsługi tradycyjnych problemów OOP.

function ObjectConstructor(){
    //No need for an init method.
    //Just pass in params and do stuff inside for instantiation behavior

    var privateAndPersistent = true;

    //I like to take advantage of function hoisting for a nice concise interface listing
    this.publicAndPointlessEncapsulationMurderingGetterSetter
    = publicAndPointlessEncapsulationMurderingGetterSetter;
    //Seriously though Java/C# folks, stop with the pointless getter/setters already

    function publicAndPointlessEncapsulationMurderingGetterSetter(arg){
        if(arg === undefined){
            return privateAndPersistent;
        }
        privateAndPersistent = arg;
    }

}

ObjectConstructor.staticLikeNonInstanceProperty = true;

var instance = new ObjectConstructor();//Convention is to  capitalize constructors

W moim kodzie prawie nigdy nie używam literałów obiektowych {}jako strukturalnych komponentów aplikacji, ponieważ nie mogą one mieć wewnętrznych (prywatnych) zmiennych i wolę zamiast tego zarezerwować je do wykorzystania jako struktury danych. Pomaga to ustalić oczekiwania, które zachowają jasność intencji. (jeśli widzisz curlies, to dane, a nie element architektury aplikacji).

• Parametry są przekazywane do funkcji, bez możliwości dowiedzenia się, jakie właściwości i funkcje są dostępne w tym parametrze (poza faktycznym uruchomieniem programu, nawigacją do punktu, w którym funkcja jest wywoływana, i użyciem konsoli console.logs do wyprowadzenia wszystkich właściwości dostępny)

Ponownie zobacz nowoczesne narzędzia przeglądarki. Ale także, dlaczego ponowne uruchomienie programu jest takie bezproblemowe? Przeładowanie jest czymś, co deweloper sieciowy po stronie klienta zwykle uderza co kilka minut, ponieważ nie kosztuje to absolutnie nic. Jest to kolejny punkt, w którym struktura aplikacji może być pomocna, ale jest to jeden niekorzystny kompromis JS, który musisz uruchomić własną weryfikację, gdy egzekwowanie umów jest krytyczne (coś, co robię tylko w punktach końcowych narażonych na inne rzeczy, których moja baza kodów nie robi kontrola). IMO, kompromis jest wart korzyści.

• Powszechne stosowanie anonimowych funkcji jako wywołań zwrotnych, które często prowadzi do spaghetti mylących ścieżek kodu, których nie można szybko nawigować.

Tak, to źle na wszystko, co nie jest trywialne. Nie rób tego Nazwij swoje funkcje, dzieci. Łatwiej jest też prześledzić różne rzeczy. Możesz zdefiniować, ocenić (wymagane do przypisania) i przypisać prostą, trywialną funkcję zgodnie z:

doSomethingWithCallback( (function callBack(){}) );

Teraz Chrome będzie miał dla ciebie nazwę, gdy śledzisz połączenia. Dla nietrywialnej funkcji zdefiniowałbym ją poza wywołaniem. Zauważ też, że anonimowe funkcje przypisane do zmiennej są nadal anonimowe.

• I oczywiście JSLint wychwytuje pewne błędy przed uruchomieniem, ale nawet to nie jest tak przydatne jak posiadanie czerwonych falistych linii pod twoim kodem bezpośrednio w przeglądarce.

Nigdy nie dotykam tego. Crockford podarował społeczności pewne dobre rzeczy, ale JSLint przekracza linię w preferencjach stylistycznych i sugeruje, że pewne elementy JavaScript są złymi elementami bez szczególnie dobrego powodu, IMO. Zdecydowanie zignoruj ​​tę jedną rzecz dotyczącą klas regEx i klas negacji, po których następuje * lub +. Symbole wieloznaczne działają słabiej i możesz łatwo ograniczyć powtarzanie za pomocą {}. Zignoruj ​​także wszystko, co mówi o konstruktorach funkcji. Możesz łatwo owinąć je fabryką, jeśli nowe słowo kluczowe Ci przeszkadza. CSSLint (nie Crockforda) jest jeszcze gorszy na froncie złych rad. Zawsze bierz ludzi, którzy wykonują wiele mówień z odrobiną soli. Czasami przysięgam, że po prostu chcą ustanowić autorytet lub wygenerować nowy materiał.

I znowu, musisz nauczyć się tego, czego nauczyłeś się z tej troski związanej z czasem pracy. (jest to częsty przypadek, gdy widziałem wielu deweloperów Java / C #) Jeśli dwa lata później przeszkadzają ci błędy w czasie wykonywania, chcę, abyś usiadł i spam przeładował się w przeglądarce, dopóki się nie zatopi. nie ma podziału na czas kompilacji / czas działania (zresztą i tak nie jest widoczny - JS działa teraz na JIT). Wykrywanie błędów w czasie wykonywania jest nie tylko w porządku, ale niezwykle korzystne jest tak tanie i łatwe przeładowywanie spamu oraz wykrywanie błędów w każdym punkcie zatrzymania, do którego dojdziesz.

I daj się nabrać na te narzędzia programistyczne Chrome. Są wbudowane bezpośrednio w webkit. Kliknij prawym przyciskiem myszy w Chrome. Sprawdź element. Przeglądaj zakładki. Dużo mocy debugowania z możliwością zmiany kodu w konsoli w czasie wykonywania jest jedną z najpotężniejszych, ale mniej oczywistych opcji. Świetny również do testowania.

W powiązanej notatce błędy są Twoimi przyjaciółmi. Nigdy nie pisz pustej instrukcji catch. W JS nie ukrywamy ani nie chowamy błędów (a przynajmniej nie powinniśmy kaszleć YUI / kaszlu ). Zajmujemy się nimi. Cokolwiek mniej spowoduje ból debugowania. A jeśli napiszesz instrukcję catch, aby ukryć potencjalne błędy produkcyjne, przynajmniej po cichu zaloguj błąd i udokumentuj, jak uzyskać dostęp do dziennika.

To, co mówisz, jest zwykłą przeszkodą dla osoby myślącej w Javie, która patrzy na JavaScript.

Najpierw odpowiedzmy na twoje pytanie ...

... moje pytanie brzmi, jak inni programiści radzą sobie z tymi problemami ...

Odpowiedź: NIE. Uczą się filozofii JavaScript, najpierw porzucając kult Javy.

Musisz zrozumieć to założenie ... JavaScript nie jest Javą. Nie chodzi tylko o składnię - chodzi o filozofię.

Teraz zajmiemy się niektórymi z nich ...

• Wyświetl natychmiast wszystkie miejsca, w których wywoływana jest metoda lub używana jest stała (Open Call Hierarchy / Show References)

  Naciśnij klawisz Control i kliknij nazwę funkcji / członka / klasy, aby przejść bezpośrednio do jej definicji

  Wszystkie są dostępne - wystarczy wybrać porządne IDE.

• Wpisywanie statyczne oznacza, że ​​można użyć uzupełniania kodu, aby wyświetlić wszystkie parametry / funkcje dostępne w obiekcie

  Z tym problemem sobie nie radzisz . Jest to coś, co wymaga zmiany twojego spojrzenia na programowanie. System typu luźnego jest jedną z mocnych stron JavaScript. Zrozum luźne pisanie - i naucz się to doceniać. Poza tym uzupełnianie kodu działa bardzo dobrze z JS.

• I oczywiście JSLint wychwytuje pewne błędy przed uruchomieniem, ale nawet to nie jest tak przydatne jak posiadanie czerwonych falistych linii pod twoim kodem bezpośrednio w przeglądarce.

  Firebug, konsola Chrome / Safari, a nawet IDE to wszystko i WIĘCEJ.

  Jest JSHint, który może wykonać sprytną analizę statyczną, do której przywykli programiści Java.

• Rezultatem jest to, że prawie cały czas musisz mieć cały program w głowie. To znacznie zwiększa obciążenie poznawcze podczas pisania złożonych programów.

  Źle! Przeciwnie, JavaScript jest „lekkim” językiem programowania - i zachęca do posiadania prostszych programów. Jak mówi Doug Crockford ... „ukarze” cię, jeśli spróbujesz napisać programy oparte na modelach w JavaScript.

• podczas gdy programy mogą być nieco łatwiejsze i szybsze w pisaniu, z mojego doświadczenia są znacznie trudniejsze do odczytania i debugowania.

  Totalnie źle! Jak decydujesz o czytelności w oparciu o język programowania? Programy są czytelne (lub nie) - NIE języki. Dodatkowo JavaScript ma fantastyczne debuggery.

Wybacz mi, jeśli zabrzmiało to trochę niegrzecznie - ale prawda jest taka, że ​​musisz zmienić swoje nastawienie Java, aby zrozumieć JavaScript.

Tylko „dojrzali” programiści Java potrafią docenić JavaScript - i nie możesz opanować tego, czego nie doceniasz. Jeszcze raz przepraszam, że jestem tępy.

Ogólnie rzecz biorąc, trudno jest mieć wspomniane narzędzia do dynamicznego języka (chyba że IDE jest częścią środowiska wykonawczego - tj. Smalltalk). To powiedziawszy, kiedy nauczysz się naprawdę dobrego edytora tekstu, większość IDE wygląda mniej atrakcyjnie - przynajmniej tak sądzę.

To cena, jaką płacimy za używanie źle napisanych języków. Można się tylko zastanawiać, dlaczego ta obrzydliwość stała się tak popularna. Wady znacznie przewyższają zalety źle napisanych języków.

Być może powinniśmy zastosować zasadę braku współpracy do tego śmiecia, aby odejść.

Kiedyś nie lubiłem javascript (i jego dynamicznego pisania), ale doceniłem jego orientację obiektową, zamykanie i programowanie funkcjonalne . Również jego globalne obiekty i usunięcie konwersji typu cichego były powiewem świeżego powietrza, gdy je znalazłem.

Moją preferowaną ideą dla javascript jest webstorm, ponieważ łatwo jest uruchomić jQuery intellitext (szkoda, że ​​nie jest darmowy).

Nie powiedziałbym też, że rośnie - jest już wszechobecny.

Twoje konkretne punkty:

Brak bezpośredniego sposobu znalezienia punktu wejścia funkcji

Nie rozumiem tego, jak to może być prostsze?

Parametry są przekazywane do funkcji, bez możliwości dowiedzenia się, jakie właściwości i funkcje są dostępne dla tego parametru

Jeśli skonfigurujesz ide tak, aby zawierał definicję obiektów, właściwości obiektu będą dostępne za pośrednictwem intellitext (ale mogłem tutaj nie zauważyć).

Powszechne stosowanie anonimowych funkcji jako wywołań zwrotnych, które często prowadzi do spaghetti mylących ścieżek kodu, których nie można szybko nawigować.

Wspólne użycie? Jeśli nie lubisz anonimowych funkcji, nie używaj ich. A może masz na myśli jQuery, który z nich korzysta? jQuery jest prawdopodobnie uważany przez większość twórców stron internetowych za jedno największe oszczędności czasu w historii tworzenia stron internetowych .

JSLint wyłapuje niektóre błędy przed uruchomieniem

Łapie je wszystkie, możesz włączyć to do swojego pomysłu . Lub Webstorm zawiera to domyślnie (tak myślę).

czego mi brakuje?

Brakuje dwóch ogromnych zalet JavaScript w stosunku do Javy:

• Kod JavaScript ma około jednej czwartej rozmiaru równoważnego kodu Java.
• Nigdy nie musisz czekać na kompilację i restart serwera.

Pracuję inaczej w JavaScript. Dodaję trochę kodu na raz, tak mało, jak tylko mogę, testuję, odświeżam przeglądarkę i testuję ją. W jQuery potrzebuję większości linii JavaScript.

Odkryłem, że programowanie w Javie jest stosunkowo bezproduktywne i teraz piszę cały mój kod po stronie serwera w Groovy, z tych samych dwóch powodów.

Wiem, że to pytanie jest stare, ale jako programista C ++ / C #, który miał takie same odczucia, ale teraz robił wiele skryptów JavaScript przez ostatnie 10 lat, moją pierwszą rekomendacją byłoby wypróbowanie Visual Studio Code .

Oczywiście nie może oferować wszystkich funkcji, które można dodać za pomocą silnie napisanego języka, ale jest dość zbliżony.

Może również pobierać informacje o typie z maszynopisu i stosować je w JavaScript. Nawet jeśli nigdy nie używasz maszynopisu, podczas pisania w JavaScript możesz uzyskać kod i dokumentację dotyczącą wielu interfejsów API.

Więc na twoje pytania

• Nie ma bezpośredniego sposobu znalezienia punktu wejścia funkcji (innego niż wyszukiwanie tekstowe, co może skutkować kolejnymi poszukiwaniami metod wyższych w hierarchii wywołań, po których dwóch lub trzech zapomniałeś, gdzie zacząłeś)

Wydaje się, że najczęściej rozwiązany w VSCode?

• Parametry są przekazywane do funkcji, bez możliwości dowiedzenia się, jakie właściwości i funkcje są dostępne dla tego parametru

Rozwiązuje to wiele IDE, dokumentując kod przy pomocy komentarzy lub maszynopisu w stylu JSDoc. Redakcja przeczyta komentarze i da ci takie same uzupełnienie, do jakiego jesteś przyzwyczajony

Powszechne stosowanie anonimowych funkcji jako wywołań zwrotnych, które często prowadzi do spaghetti mylących ścieżek kodu, których nie można szybko nawigować.

Jako programista w języku C # również tam często występują anonimowe funkcje, które zostały dodane do C ++. Myślę, że jest to coś, do czego musisz się przyzwyczaić.

Również, jeśli wywołania zwrotne zostały w większości zastąpione obietnicami i asynchronicznie / oczekuj, a jeśli masz interfejs API, który korzysta z wywołania zwrotnego, możesz szybko go zawinąć, aby użyć obietnicy, a następnie użyć asynchronizacji / oczekiwania, aby problem zniknął.

I oczywiście JSLint wychwytuje pewne błędy przed uruchomieniem, ale nawet to nie jest tak przydatne jak posiadanie czerwonych falistych linii pod twoim kodem bezpośrednio w przeglądarce.

Otrzymasz faliste linie w programie Visual Studio Code. Nie tylko to, ale jeśli włączysz integrację ESLint, otrzymasz mnóstwo niesamowitych ostrzeżeń i / lub błędów wyróżnionych w edytorze. Więcej niż widziałem dla innych języków. Z moich doświadczeń wynika, że ​​napisy do C / C # / Java zostały dość mocno zakodowane, ponieważ ESLint jest zarówno masywnie konfigurowalny, jak i masowo rozszerzalny, a takie popularne biblioteki mogą się nawet integrować, aby udzielać porad i ostrzeżeń dotyczących określonego użycia biblioteki w edytorze. Coś, czego osobiście nie widziałem w innych językach (choć może teraz jest to również powszechne w innych językach?)

Jest również rok 2018, a ES7 to nowa norma, więc dostaniesz class. Zawsze używasz trybu ścisłego. Nigdy nie używasz vari zawsze używasz constoraz letwielu rzeczy, z którymi programiści C ++ / C # / Java mieli trudności z przyzwyczajeniem się do znikania. Włącz no-undefregułę w ESLint i jeszcze więcej problemów zniknie

To powiedz, dowiedz się, jak thisnaprawdę działa i jak działają funkcje i metody, ponieważ to nie to samo, co C ++ / C # / Java.

Moje pierwsze 2-3 lata JavaScript były frustracją. W pewnym momencie jednak kliknęło. Przestałem próbować zmusić go do stworzenia C ++ / C # / Java i teraz denerwuję się, gdy wracam, gdy rzeczy, które wymagałyby 15 wierszy w JavaScript, zajmują 150 w innych językach.

Jeśli lubisz IDE i jesteś przyzwyczajony do zaćmienia, sprawdź Aptana jako IDE dla JavaScript. Myślę, że może zrobić wiele z tego, co chcesz. (Ja osobiście nienawidzę IDE, ale to inna rozmowa).

Jeśli chodzi o funkcje anonimowe, uważam, że są one najpotężniejszą funkcją JavaScript, a próba pracy w języku, który ich nie ma, jest w tym momencie dość bolesna.

Jeśli chcesz czegoś innego, co może skompilować się w JavaScript, istnieje wiele opcji, CofffeeScript, Clojure i GWT wszystkie przychodzą na myśl, ale są też inne.

Jeszcze go nie używałem, ale widziałem kilka wersji demonstracyjnych i jestem pod wrażeniem Cloud 9 jako IDE JavaScript.

Możesz wybrać zarówno model usługi online, jak i pobrać go z GitHub.

Jako dowód na to, że jest IDE, Cloud9 został napisany przy użyciu ... Cloud9!