Комментарии 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 и на порнхабе должно интерпретироваться по-разному?
Это такая эпотажная попытка проиллюстрировать бестолковость вашего подхода. Масштабируемость — это масштабируемость, независимо от того, где используется это слово. То что в "бытовом смысле" под масштабируемостью почти всегда понимается "быстро и много", совершенно не означает, что теперь нельзя говорить про "масштабируемость кода". В быту также слово "программист" означает "может починить компьютер", а "интернет" означает "яндекс". У нас тут хабр, а не посиделки с домохозяйками :-)
Я и большинство других читателей данной статьи сразу поняли о том что идёт речь про масштабирование (расширение) кодовой базы, но вы не разобравшись начали гнать на автора, что он вводит всех в заблуждение, один термин может пониматься в разных контекстах по разному и в данном случае было вполне очевидно, что речь идёт о кодовой базе, а вы начали токсично высказывать свои претензии.
везде писать readonly.Удобнее оборачивать в DeepReadonly, как минимум все аргументы функций/методов/конструкторов. Кроме этого тип NoExtraProps может быть полезен. Этих типов нет в стандартном наборе TS но их легко найти в поисковике или самому написать кто любит задрачивать на TS типы.
UPD. Перечитал про «сужение» еще раз. Мне показалось, там несколько техник сведены под одним заголовком. Есть пример c «is», но я бы еще добавил пример c «asserts».
Мы используем TypeScript, потому что это делает разработку безопаснее и быстрее.
Безопаснее разработку с тайпскриптом делают Ваши правила, а не сам язык, в котором, позволен изначально делать небезопасно…
Увидев заголовок про масштабирование, как-то ожидал увидеть что-то поинтереснее, чем пару параграфов по базовым возможностям языка
habr.com/ru/hub/webdev
Если бы не был подписан — не узнал бы, зато статьи от рувдс никак скрыть не могу(
// 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
К пункту "не использовать 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;
const someData = { id: '42', name: 'John' } as User;и никаких проверок не надо.
Простые TypeScript-хитрости, которые позволят масштабировать ваши приложения бесконечно