Pull to refresh

Comments 32

И каким образом всё это помогает «масштабировать приложения бесконечно»?
Привет! От увеличения размера проектов, работать над ними не становится существенно сложнее: подобная строгая типизация позволяет орудовать сущностями, не ожидая от них подставы и не держа весь код проекта и его взаимосвязи в голове
Всё это понятно. Вопрос в том, как это связано с масштабированием?

Имеется в виду масштабирование кодовой базы — вроде очевидно.

Понимаете, я против размывания терминов. Под масштабированием всю жизнь понимали способность системы справляться с возросшей нагрузкой при добавлении вычислительных мощностей (вертикальном или горизонтальном), как правило, без переписывания кода! Разумеется всё это понималось в отношении бакэнда, а не фронта. И вот внезапно появляется «масштабирование кодовой базы», которое внезапно означает совсем… другое.

Мне нравится статья, она даёт правильные советы, но… заголовок — он какой-то слишком кричащий. «Масштабировать»… «бесконечно». Автору стоило бы уточнить, что речь идёт о совсем другом масштабировании. На мой взгляд, конечно. Что-то вроде «Вы могли бы заниматься масштабированием вашей кодовой базы неограниченно» (оптимизм автора насчёт бесконечного масштабирования мне тоже нравится, да).

Приложение и малого превращается в большое. Это разве не масштабирование? Тут речь идёт не о системе, а о кодовой базе. Автор мог запутать неправильной формулировкой

да, разумеется, под масштабированием имел в виду только увеличение размеров проекта. Я использую слово «масштабировать» довольно часто для всего, что может расти, поэтому для меня оно хорошо воспринимается и вне контекста бэкенда или разговоров о базах данных. Тем не менее, извиняюсь, если кого-то запутал этим :(
Под масштабированием всю жизнь понимали способность системы справляться с возросшей нагрузкой при добавлении вычислительных мощностей (вертикальном или горизонтальном), как правило, без переписывания кода!

Если взять AWSовское определние: "A measurement of a system's ability to grow to accommodate an increase in demand" — про вычислительные мощности нету, есть про увеличение потребностей и про способность расти.

Если взять AWSовское определние: «A measurement of a system's ability to grow to accommodate an increase in demand»
А где там про переписывание кода? AWS — это само по себе про вычислительные мощности.
Вашими молитвами. А почему Вы интересуетесь моей жизнью?

Ну серьёзно — одно и то же определение прочитанное в доках AWS и на порнхабе должно интерпретироваться по-разному?

Не могу сказать. Я слабо знаком проблематикой порнхаба. Что вас заставило сделать такой вывод? Серьёзно, что вас заставляет в этом треде поминать порнхаб?

Это такая эпотажная попытка проиллюстрировать бестолковость вашего подхода. Масштабируемость — это масштабируемость, независимо от того, где используется это слово. То что в "бытовом смысле" под масштабируемостью почти всегда понимается "быстро и много", совершенно не означает, что теперь нельзя говорить про "масштабируемость кода". В быту также слово "программист" означает "может починить компьютер", а "интернет" означает "яндекс". У нас тут хабр, а не посиделки с домохозяйками :-)

Оставлю это здесь. Именно в таком виде этот термин преподавали нам в университете. Лет 20 назад. Или больше, я немного сбился со счёта, но это было еще на ЕС 1045. На счёт бытового смысла или порнхаба ничего не скажу, не знаком с такими трактовками. Что касается «масштабирования кодовой базы», то это несколько более новое веяние и упоминать его желательно именно в такой уточняющей форме. Просто чтобы не путать читателя.

Я и большинство других читателей данной статьи сразу поняли о том что идёт речь про масштабирование (расширение) кодовой базы, но вы не разобравшись начали гнать на автора, что он вводит всех в заблуждение, один термин может пониматься в разных контекстах по разному и в данном случае было вполне очевидно, что речь идёт о кодовой базе, а вы начали токсично высказывать свои претензии.

везде писать readonly.
Удобнее оборачивать в DeepReadonly, как минимум все аргументы функций/методов/конструкторов. Кроме этого тип NoExtraProps может быть полезен. Этих типов нет в стандартном наборе TS но их легко найти в поисковике или самому написать кто любит задрачивать на TS типы.
DeepReadonly — катастрофически замедляет автокомплит в ide — слишком увлекаться не стоит.
Я бы добавил еще сюда кастомные Type Guard-ы. Сужение типов — это, конечно, близко, но не совсем то же самое. Во всяком случае официальная документация их различает и про guard-ы есть отдельный раздел.

UPD. Перечитал про «сужение» еще раз. Мне показалось, там несколько техник сведены под одним заголовком. Есть пример c «is», но я бы еще добавил пример c «asserts».
Мы используем TypeScript, потому что это делает разработку безопаснее и быстрее.

Безопаснее разработку с тайпскриптом делают Ваши правила, а не сам язык, в котором, позволен изначально делать небезопасно…

Увидев заголовок про масштабирование, как-то ожидал увидеть что-то поинтереснее, чем пару параграфов по базовым возможностям языка

спасибо за статью, почему-то ваши статьи уже 2 или 3 раз не отображаются у меня в ленте на:
habr.com/ru/hub/webdev
Если бы не был подписан — не узнал бы, зато статьи от рувдс никак скрыть не могу(
Спасибо за фидбек! Это из-за того, что я не указал среди хабов «Разработка веб-сайтов» — туда можно указать четыре тематических хаба и я как-то стал забывать про этот, указывая обычно Angular + TS + JS и еще что-нибудь. Похоже, стоит включать :)

Да, было бы здорово, это общий хаб который объединяет все перечисленные)
Спасибо)

Столько желчи в комментариях. Почему просто не пройти мимо, если не узнали что-то новое? Для меня было полезно, спасибо автору!
Видимо не хватает четвёртого варианта:

// four levels
const unsafeArray: number[] = [1, 2, 3]; // bad
const safeArray: readonly number[] = [1, 2, 3]; // good
const verySafeTuple: [number, number, number] = [1, 2, 3]; // awesome
const superSafeTuple: readonly [number, number, number] = [1, 2, 3]; // super
Спасибо вам, это очень полезный комментарий!
Из-за того, что мы нигде ничего не мутируем, в моей команде и не знали, что туплы по дефолту мутабельные и мы можем сделать на тупле в данном случае .pop() пару раз, нагло нарушив контракт переменной

Кстати, у вас есть идеи, для чего может существовать мутабельный «тупл»? (фактически, он и не тупл в таком случае) Сходу выглядит как беда TypeScript, на которую стоит завести issue
К примеру кортежи в TypeScript используются для того чтобы итерировать данные в которых есть ключ и значение (Map, URLSearchParams и т.д). Я встречал подход когда иммутабельность используется не повсеместно а только в публичных методах, это избавляло от избыточного создания одноразовых объектов/массивов. Тут как-раз может пригодиться мутабельность кортежей.

К пункту "не использовать any". Типы можно "доставать" из окружения — переменных, массивов, аргументов функций и их ReturnType. Это конечно не очень красиво, но на порядок лучше any — так что, используйте с умом.


// 1. из переменной
let foo = { foo: 'f' };
let bar: typeof foo = null;
// 2. из массива
let foo = [{ foo: 'f' }];
let bar: (typeof foo)[0] = null;
// 3. из аргументов
function doBar (foo: { foo: string }) {
}
let bar: Parameters<typeof doBar>[0] = null;
// 4. из возврата
function doBar () {
    return { foo: 'f' };
}
let bar: ReturnType<typeof doBar> = null;
Последний вариант уж больно натянутый, да и TypeScript ругается что unknown может и null'ом оказаться. Уж лучше сразу:
const someData = { id: '42', name: 'John' } as User;

и никаких проверок не надо.
Only those users with full accounts are able to leave comments. Log in, please.