О, там тоже посмотрели это видео. Только дочитал. Мнение одного чувака из ТС чата:

Супер доклад
Крутые данные
Умный чел
Но он по жизни заблудился

Его идея в том, что если ты работаешь на аутсорсе за фикс прайс, то выгодно проект сдавать быстро с минимально допустимым качеством кода. Чем дольше кодишь - тем меньше денег в итоге получишь, ибо цена и проект изначально обговорены. Совсем плохой код не сдашь, заказчик не примет, но можно сдать средненький.

Это waterfall разработка

Да, в этих условия TS тебе не применсет больше денег, ибо:
- он дает на 20-25% меньше дефектов в продакшене
- но при этом +50% количество кода

Тут все четко. По теории производства: чем на более раннем этапе производства (прикремил скрин) ты поймал дефект, тем дешевле/быстрее его закрыть. В продакшене супер дорго - на этапе дизайна супер легко.

Далее чел привел свою статистику, что им удалось больше денег заработать, когда они внедрили контроль качества в самом начале производственной цепочки.

Но вопрос в другом: хочешь ли ты работать в компании, которая делает проекты по фикс прайсу? Мне кажется вот это рак, который этот чел не видит.
Тут задача не принести больше валуе клиенту, а побыстрее сдать проект и забыть о нем. Причем качество должно быть минимальным. В таких условия рождается токсичная среда: ты и клиент хотите разного. Я бы не стал в таких условиях работать. В современном мире у программистов есть выбор, куда пойти.

Минимальное качество кода - баги в продакшене, плохая архитектура, в которую дорого добавлять фичи или менять части. А бизнес постоянно меняет части и добавляет фичи, ибо он сам в начале не знает, чего хочет.

Если убрать из уровнения фикс прайс, а работать по часам, прикрепить карьерный рост к росту прибыли компании, то расклад будет совсем другим.

Тут уже нужно замерять количество дефектов в продакшене, против скорости выката новых фич. Тут уже можно думать в аджайл фрэйморке. И TS чувствует себя в этой пирамиде прекрасно:
- spec ревью
- design ревью
- ts
- tests
- code ревью

Все пункты важны. Сказать, что тесты отменьшают валую от ts невозможно, они добавляют друг дргуа. TS это огромное количтво халявных тестов в коде.

Но чел прав, что нужно сосредоточится на верхних частых пирамиды в начале, потом идни ниже, но все пункты важны.

—

Отдельный пункт, о котором тот сказал в скользь в конце, TS упрощает/ускоряет design ревью.

А например если мне нужно передать объект с опциями, то как лучше это сделать по канону?

Я исходниках impress видел
function a (b, s = {})

О, человек исходит из ложного предположения - из утверждения что ТС невыгоден в контексте фикс-прайсов делает вывод, что ТС выгоден в других ситуациях

Люблю такие абберации восприятия

Я с удовольствием послушаю ваш доклад про ТС в других моделях прайсов

У меня нет таких данных в данный момент

И жаль, что по беку данных тоже нет ((

мне это неинтересно )

Чёт кек какой-то

ну конфиг может быть опциональным, если есть значения по умолчанию, могут быть какие-то временные объекты, но инстансы классов с опциональными полями это зло

Ну, имхо, всё верно. Особенно, если писать с нуля и фреймворк-агностик, то с ТС даже быстрее получается

Я предлагаю любому инженеру взять ТЗ условно "на день" и попробовать обогнать меня на ТС :) а я буду писать на JS + тесты ) И в конце дня сравнить результат по количеству ошибок

Мою либу используем и на беке и на фронте - больше года полёт нормальный

Пока никто не согласился )

Я тесты не отменяю. В моей либе 100% покрытие

Из доки


The library does not use the above interfaces but uses read-only (immutable) variants for each of them.

For example, instead of type Item = { id: string }, library uses type ItemRO = { readonly id: string }.

The full list of immutable types could be found in readonly interfaces. This proves the immutability of types used in the library.

Tests do not use read-only types. This proves that functions could be used with mutable variables as well. The immutability in tests is proved by deepFreeze (which is based on Object.freeze)

мб предложи это java, c#, scala, haskell деву?
Думаю ты их тоже легко обгонишь. Только они построят каркас из типов, который им в будующем поможет избежать ошибок.
А на js действительно очень быстро пишется.

Это же провокация, по большому счету

структурная типизация позволяет легко писать тесты, передавая только часть структуры. Но не уверен, что это хорошо

Максимум что докажите что ктото делает быстрее и все