Тази статия е продължение на „Погрешностите на „данъка TypeScript““.

Лоши причини да отхвърлите TypeScript

Тестването е по-важно от типовете

Тези две „тестване“ и „типове“ не са в пряка конкуренция.

TypeScript не замества тестването. На практика TypeScript често улеснява писането на тестове, например ако вече имате тип за данните, върнати на компонент от API, вие вече сте трети път в писането на теста, като знаете какво е подреждане част ще бъде (в модел Подреждане-действие-утвърждаване).

Но това е теорията. На практика, когато разработчиците споменават този аргумент, те са наясно, че двете не се изключват взаимно. Това, което те имат предвид, е, че — в конкретния контекст — има натиск (по-високо ръководство, крайни срокове, заинтересовани страни), което означава, че трябва да пожертваме някои мерки за качество в полза на други.

Не мога да споря с това - бил съм там. Затова ще се обърна към прагматичния програмист във вас.

При този тип ситуации и проекти TypeScript е много важен. Защото на практика, когато този натиск се увеличи, първата мярка за качество, която се отнася към изоставането, са „тестовете“. Това се превръща в технологичен дълг, който никога не се разрешава, защото – в този тип организация – натискът никога не спира.

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

Дори ако започнете да имате каквито и да енавсякъде, вие — поне — ще получите лесните типове и някои от предполагаемите типове. И това е страхотно място за начало, като се има предвид, че алтернативата е без тестове и типове.

Допълнителното време за писане и поддръжка на типове

Въпреки че TypeScript прави добавя време, тази цена трябва да се вземе предвид при различни лещи:

Типовете стойност добавят

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

Тестовете също добавят време за писане и поддръжка

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

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

Моделите се появяват бързо в TypeScript

Въпреки че TypeScript е огромен, на практика моделите започват да се появяват бързо за повечето случаи на употреба, когато създавате конкретно приложение. Да кажем, че изграждаме React приложение и не знаете TypeScript, бързо ще научите как да дефинирате подпорите за компонент (и ги намирам за обективно по-лесни за запомняне от синтаксиса на propTypes), ще откриете, че сте винаги може би дефиниране на тип за API отговор, след което го консумира чрез API слой / библиотека в кода, който вече предоставя типове. Като начинаещ, може би ще ви е трудно да разберете използването на генерични средства в useState, но изводът за тип ще ви спести повечето време, след което, след като го направите веднъж, ще повторите.

На практика този разход намалява, когато прекарвате повече време в даден проект. Винаги ще има странен тип, който ще ви затрудни, но това важи и за тестовете: винаги ще има една промяна, при която тестовете отнемат повече време от внедряването.

Други причини

Някои „лоши“ причини се проявяват в общи заключения без много доказателства. Опитайте се да ги разпитате и вижте колко силни са те: Ако някой твърди, че „Рядко имаме типови грешки“, потърсете в историята на ангажиментите си думите „неправилно написано“, „недефинирано ”, “null” или “.legnth” вероятно ще намерите няколко примера – по-добро тестово покритие би ги уловило, но тъй като ние очевидно не Нямам такова покритие, не би ли си струвало да проучим начини за избягване на този тип проблеми. Ако някой твърди, че „изводът на код в IDE е достатъчен“, тогава му покажете разликата в потреблението на компонент на React, написан на Typescript, спрямо такъв, използващ propTypes, и ако последващото действие е, че „Трябва да подобрим документацията“, тогава струва ли наистина по-малко за поддържане на документация, отколкото за поддържане на типове?

Не толкова лоши причини за отхвърляне на TypeScript

Избягване на Hype

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

Пътят на ажиотажа обаче има много спирки преди TypeScript: използване на сложна библиотека за управление на състоянието без причина, натискане на автоматизирани тестове от край до край за всичко (и безкрайна борба с нестабилността и нарастващите разходи), monorepos в името на това, водопад, представен като agile (scrumfall), самият TDD беше голям хайп и BDD все още е, а пътят стига чак до микроуслуги, микрофронтове, kubernetes и други. Всички те имат много по-висока цена от избора на език.

Така че разговорът за TypeScript във вашата организация след реклама ли е или истинско търсене на по-добро качество?

Въпросът — според мен — има философска стойност (и може да е индикация за по-дълбок културен проблем в една организация), но има много малко практическо значение в конкретния разговор за TypeScript.

Ако търсите TypeScript за реклама, това не означава непременно, че вземате грешно решение – грешният подход по своята същност не означава грешно решение. Инженерните решения обикновено започват от определен проблем, ние идентифицираме решенията, сравняваме ги и след това вземаме решение. Но понякога процесът е обратен, необходимо е решение, за да се види проблем. Това се случи например с функционалните компоненти в React, никой не се оплакваше от класовите компоненти преди, но беше необходимо решение (функционални компоненти), за да се видят проблемите и сложността на стария начин на правене на нещата.

В случая с TypeScript може да сте започнали от двата края: като дефинирате проблем и мислите, че TypeScript ще го реши, или като разгледате решението и се чудите какви ползи ще ви донесе (следвайки шума). Не мисля, че нито един от двата подхода е грешен, стига да направите проучване и да анализирате какво означава - за вашия конкретен контекст - да преминете към TypeScript. Прекомерното наблягане върху подхода отвлича вниманието от фокусирането върху анализирането на ROI на TypeScript, което трябва да бъде основният проблем.

Решението да преминете към TypeScript е широкообхватно

Това е полуистина.

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

Има много далечни последици за преминаването към TypeScript, но техническите не са непременно най-критичните. Причината е, че разходите за отказ от TypeScript - ако не се получи - са незначителни. TypeScript е надмножество на JavaScript и ще е необходима буквално една команда, за да се върнете към страната без тип на JavaScript. Сравнете това с преминаването от Redux към друга библиотека за управление на състоянието и може да осъзнаете, че от гледна точка на кода, TypeScript далеч не е най-обхватното решение във вашия стек от технологии.

Влизането е трудно

От гледна точка на кодирането, най-трудното внедряване, което имах, беше да се присъединя към компания, където основният стек от технологии беше Vue с TypeScript. И аз не знаех и беше трудно.

„Гледната точка на кодирането“ обаче е само едната страна на внедряването и въпреки че първоначално тази роля беше трудна технически, това далеч не беше най-трудното преживяване, което съм имал като цяло. Най-трудните преживявания включват еднорог, където буквално никой не говори с мен през първите четири дни, или корпоративното, където не получих лаптоп през първите десет дни, след което ми беше отхвърлено, че многократно го искам.

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

Става дума и за това да имате ясен набор от очаквания за това какво трябва да направите и кога трябва да го направите.

За тази роля на Vue и TypeScript се очакваше да ги науча по време на работа. Получих време и подкрепа да науча и двете технологии. Ако се очакваше да бъда 100% продуктивен от първата си седмица, тогава щях да се проваля. И вината щеше да бъде тяхна.

Това се отнася за TypeScript, но и за всяка друга технология. Борих се първия път, когато трябваше да работя с кодова база, използвайки redux, борих се (и все още се боря) с redux-saga, react-query. Aвсяка библиотека с мнение или нова технология има крива на учене и отнема време за ефективна работа. Не мисля, че внедряването на TypeScript е особено по-трудно от тези други технологии ако (и това е голямо Ако) всеки получава подкрепа и време да го научи.

Синтактичният шум

Идвам от опит в C# / Java и моят умствен модел за изразяване на тип беше първо да декларирам типа, след това името на променливата Име на низ;. Нещо толкова просто като обръщане на този ред, за да се каже let name: String; в TypeScript беше много трудно за приемане. Бях изненадан как сравнително малък детайл беше толкова вкоренен в главата ми, че през първите няколко седмици, когато погледнах кода на TypeScript, всичко, което видях, беше визуален шум.

Това се отнася до следващата точка от кривата на обучение. Но tldr; е, че ще свикнете с допълнителния „шум“. Но ако вие — като мен — само сте използвали други строго типизирани C-подобни езици преди, тогава прекарайте известно време в четене на Ръководството за TypeScript за Java/C# и това ще улесни значително пътуването ви до приемане на TypeScript по-лесно.

Добрите причини да отхвърлите TypeScript

Кривата на обучение

Признавам, че TypeScript има значителна крива на обучение.

Преди отбелязах, че на практика подмножеството на TypeScript, което бихте използвали в проект, има тенденция да се повтаря и следва определени модели, така че малко информирано копиране/поставяне може да ви помогне да заобиколите TypeScript първоначално.

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

За мен това е подобно на времето, когато JavaScript и SPA ставаха популярни. Дойдох от C# фон и години наред предполагах, че мога да кодирам JavaScript само защото изглежда малко като C#. Използвах модели и знания от C# и постоянно се оплаквах от JavaScript. След това прочетох JavaScript: добрите частии разбрах, че кодирам JavaScript, без наистина да познавам JavaScript.

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

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

Липса на план за преминаване към TypeScript

„Сега прехвърляме всичко към TypeScript“ не е план за действие. Основната точка на разговора за възвръщаемост на инвестицията е, че контекстът има значение. Този контекст обхваща отделни проекти, а не само отделни организации.

В организация със среден размер обикновено може да имате различни проекти:

  • Обществени проекти
  • Вътрешни проекти
  • Вътрешни UI библиотеки
  • Споделени помощни библиотеки
  • Вътрешни инструменти
  • Greenfield, Brownfield и Proof of Concepts проекти

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

Планът също така трябва да включва хората:Как да преодолеем разликата в знанията между тези, които знаят TypeScript, и тези, които не знаят.

Цифровото разделение

Без план за преминаване към TypeScript може да се окажете с двустепенна организация: някои са „първокласни граждани“, които познават TypeScript и могат да създават всички нови лъскави неща, а други са изоставени.

Това често е страничен ефект от непланирането на преминаването към TypeScript и човешката страна на това. Това може да остави екипа разделен, хората да се почувстват изоставени, неоценени и разочаровани.

Според мен възприемането на дадена технология е толкова проблем на хората, колкото и технически. Така че, ако възнамерявате да възприемете нова технология, тогава инвестирайте във вашите хора – всички тях – за да сте сигурни, че ще получат подкрепата и наставничеството, за да бъдат в крак с TypeScript.

Тази поддръжка, в контекста на TypeScript, изглежда така:

  • Дайте време, ресурси и пространство за учене: в моя случай това включваше компанията да получи копие от книга, но можеше да бъде достъп до сайт за обучение или просто малко време за експериментиране – хората учат по различен начин, така че се адаптирайте към това.
  • Създайте канал/група за TypeScript: Освен основите, понякога е трудно да знаете как да изразите идея в TypeScript или дори как да зададете въпроса на Google. Често е по-ефективно да попитате колеги, а една проста показалка може да ви спести часове.
  • Прегледи на кода: Добрите прегледи на кода бяха ключови за изучаването на TypeScript. Създайте си навик да маркирате хора, които знаят малко повече за това, това помага и на двама ви да станете по-добри.
  • Програмиране по двойки: Дори и да не сте фен на програмирането по двойки, струва си да се сдвоите с други разработчици, особено в началото.
  • Шампион на TS: В моя случай това беше един колега от работата — Хуан Карлос Ароча — който пое отговорността да защити TypeScript и да помогне на другите да го приемат и след това да го прегърнат. Ролята му беше неофициална, но той често преглеждаше PR-ите, скачаше на импровизирани обаждания, за да обясни нещо, пишеше публикации и бележки за новите си знания и правеше всичко това с емпатия и търпение. Това в моя екип оказа най-голямо влияние за ефективното преминаване към TypeScript. Това не винаги е възможно и е голяма молба от всеки. Но ако имате Хуан,тогава им дайте време и пространство да свършат работата си и това ще ви се отплати.

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