ES6 предоставя на разработчиците на JavaScript повече начини да правят нещата. Но това не винаги е добро.

Наскоро написах статия за ES6 Tips and Tricks, която има над 17 000 гледания и 4600 хлопки. Един коментар беше от Боб Мък, който каза, че:

Тази статия прави много силен аргумент за избягване на JavaScript като чума при всяка употреба, при която искате дългосрочна надеждност, поддръжка и модифицируемост.

Неговото мнение изглежда е, че ако езикът се променя колкото е възможно, той подписва собствената си смъртна присъда.

Какво ES6, 7 и 8 добавят към JavaScript

Най-новите спецификации добавят много нови функции към езика. Разрушаване, сбито задаване на обекти и символи, за да назовем няколко. Има някои добри неща, които минават, но тази статия има за цел да подчертае проблемите.

Защо това е проблем?

Искате да създадете функция за получаване на обект и да направите някаква логика върху него. Просто нали? Но по какъв начин ще го направите?

var data = {a: "отпечатайте ме"};
метод на функция1 (данни) {
    var a = data.a;
    console.log (а);
}
метод на функция2 (данни) {
    console.log (data.a);
}
метод на функция3 ({a: info}) {
    console.log (информация);
}
метод на функция4 ({a}) {
    console.log (а);
}

Всички тези методи ви дават абсолютно същия резултат. Това е много тривиален пример, но важи за много по-сложни функции.

Как да решите какво да използвате?

Има 3 основни метода за решение за това как да направите това:

  • Оценете и сравнете наличните опции.
  • Просто използвайте каквото искате.
  • Имайте политика за това къде да използвате.

Всяко от тях има своите предимства и недостатъци.

Снимка: pixabay.com

Оценете и сравнете наличните опции

Това изглежда като очевиден избор, но дали е най-добрият? Правенето на това всеки път означава, че трябва да оценявате предимствата и недостатъците на всеки метод ВСЕКИ ВРЕМЕ пишете функция. Това е много мислеща сила, която може да се използва за проблема, който се опитвате да решите.

Вие и всички, с които работите, трябва да знаете предимствата, недостатъците и нюансите на всеки метод. Това не изглежда твърде лошо, има само 4, но какво ще кажете за справяне с асинхронното поведение? Използвате ли обратни обаждания, обещания, генератори или Async / Очаквайте или комбинация от тях?

Това означава, че всеки, с когото работите, трябва да разбира всеки бит на езика. Предполагам според броя на мненията в моята статия в ES6, че много хора все още учат някои от по-основните синтаксиси на езика. Това означава, че са много малко, които разбират сложността на асинхронното поведение (което в момента се опитвам да разбирам добре).

Просто използвайте каквото искате

Това е най-често срещаният подход, както за физически лица, така и за компании. Това може да бъде чудесно, тъй като означава, че не губите време и усилия, изчислявайки най-добрия избор.

Проблемите могат да възникнат, когато някой друг дойде да прочете или поправи вашия код. Може да сте дете на Wiz JavaScript и да знаете всички най-нови методи за всичко. Но следващият човек, който идва да чете или променя работата ви, може да няма представа какво сте направили.

Това също насърчава огромни разлики в стила между компаниите и колегите. Това също може да означава разлики между вас и бъдещето, когато научите нов синтаксис. Това не е чудесно и прави много по-трудно четенето на код, написан от множество разработчици.

Снимка: pixabay.com

политика

Независимо дали става въпрос за фирмена политика или лична политика, това премахва много проблеми с първите два подхода. Не изисква мислене и насърчава последователност в кодовата база. За съжаление, все още има няколко проблема.

С новите версии на спецификациите на ECMAScript редовно излизат, възниква дилема. Трябва ли компанията да промени политиката си, за да бъде в съответствие с най-новите версии? Или да напишете политика и никога да не я променяте - пропускате новите функции? Или трябва да е някъде по средата?

Новите наематели трябва да научат политиката и да знаят как да я използват. Да, може да имате книжка за правилата, но може да отнеме повече време, за да намерите спецификацията, отколкото да напишете реда на кода. Дори и да намерят политиката за асинхронно поведение, тогава трябва да могат да я използват. Това може в крайна сметка да потисне младшите разработчици до простото кодиране, тъй като те не искат да нарушават политиката, като масово ограничават растежа им.

Какво наистина предлага ES6 +?

Каква е реалната разлика между примерите, които дадох по-горе? Новият синтаксис по-лесен ли е за четене или предоставя допълнителна функционалност?

предложенията им трябва да {да} с намаляване на натискане на клавиши и добавяне на трикове, които са "спретнати".

Наистина не мога да видя много, ако има такава, полза от използването на разрушаване или сбит синтаксис на обект, освен от запазване на натискания на клавиши. Възможно е да има ползи от изпълнението или някаква специална магия, която не знам или разбирам, но:

Никоя от тази разлика в представянето няма никакво значение! - YDKJS

снимка: pixabay.com

Този цитат е вид изваден от контекста, така че ще обясня. Да предположим, че метод X изпълнява 1 000 000 операции / секунда, а метод Y изпълнява 500 000 операции / секунда. Това означава, че X е два пъти по-бърз от Y. Но разликата в времето на изпълнение е само 1 микросекунда. Това е 100 000 пъти по-бавно от това, което човешкото око може да възприеме. Така че никоя от разликите в производителността няма никакво значение!

Спестяванията, направени чрез използване на различни методи, вероятно ще бъдат толкова малки, че няма значение. Ако се опитвате да напишете възможно най-бързия код, защо го пишете в JavaScript?

Какво предоставя и ES6

Объркване, сложност и опции.

По-късно в дискусията с Боб той каза това за JavaScript:

Трябва да го декодирате, за да разберете какво прави. Синтаксисът и семантиката на езика са сложни, сложни, объркани. Програмистите, които отстраняват грешки, поддържат, подобряват и преразглеждат кода ви на следващия ден или десетилетие по-късно, ще имат проблеми с разбирането му. Ще се чудят дали нещо, което сте направили, е невероятно умно или невероятно глупаво.

Това звънене толкова вярно с мен. Открих кода, който съм написал, озадачавайки да разбера какво направих и защо го направих. Въпреки че можете да пишете сложен и объркващ код на който и да е език, JavaScript ви дава много възможности да се извадите.

Направих това на себе си в статията на ES6. При 4000 души, които прочетоха цялата статия, само 5 успяха да намерят грешката ми, преди да я поправя. Кое от тях е правилно?

нека човек = {
    име: "Джон",
    възраст: 36,
    работа: {компания: "Tesco", роля: "Помощник в магазина"}
}
метод на функцияA ({name: driverName, age, job.company: company}) {...}
метод на функцияB ({име: driverName, възраст, работа: {company}) {...}

Използвах грешна и повечето хора не забелязаха. Само малцината, които го изпробваха, успяха да намерят грешката.

Какво всъщност осигуряват тези два метода, за да оправдаят допълнителното объркване и сложност? Много хора могат да четат, пишат и разбират функция като тази:

метод на функцияC (лице) {
    var driverName = person.name,
        age = person.age,
        company = person.job.company;
    ...
}

Да, трябваше да напиша 32 допълнителни знака, но тъй като по-голямата част от програмирането мисли, а не пише, спестяваме ли време да пишете само, за да прекарваме повече от това в мислене?

Това не е просто допълнителното време, което авторът прекарва да мисли за това, а всеки човек чете този код след тази точка (често авторът отново). Сложният код има „данъка върху мисленето“ всеки път, когато се чете и ние, като хора, имаме само ограничен запас от мислеща сила всеки ден.

Не всичко е лошо

Въпреки че изглежда, че тази статия наклонява ES6, има някои неща, които увеличават четимостта и поддръжността. Обещания, функции на асинхронизация и асинхронизиране / очакване всички помагат за абстрахиране на сложността на асинхронното поведение, което прави кода по-логичен и по-лесен за четене. Това е, което според мен трябва да се съсредоточи върху триковете за спестяване на клавиши.

Дългосрочни ефекти

Въпреки че това вероятно няма да има значение за вас като разработчик, компаниите с много разработчици може да почувстват въздействието. Първо трябва да разберете какво прави синтаксисът, преди да разберете какво прави кодът води до ненадежден и не поддържан код.

Това може да доведе до загуба на JavaScript за всичко, което е голямо, сложно, критично или се развива. Това би бил масивен пазар на JavaScript, който да се изгуби.

резюме

  • ES6 ни дава още повече начини да свършим същата задача.
  • Можете да изчислите кое е най-доброто, да направите каквото искате или да имате политика.
  • ES6 ни дава нови трикове, за да запишем някои натискания на клавиши.
  • Тези нови трикове увеличават сложността и шансовете за грешка, като същевременно намаляват четливостта.
  • Има някои добри битове на ES6, които увеличават четимостта.
  • Възможно ли е повишената сложност и намалената четимост да направят по-малко вероятно компаниите да я използват в сложни, критични или постоянно развиващи се решения?
Какво мислиш? Уведомете ме в коментарите. Ако ви е харесало, кажете го и следвайте ме за още статии в JavaScript.