Https://Www.Youtube.Com/Watch?V=H9-F8uhKMRk

Супер доклад Крутые данные Умный чел Но он по жизни заблудился Его идея в том, что если ты работаешь на аутсорсе за фикс прайс, то выгодно проект сдавать быстро с минимально допустимым качеством кода. Чем дольше кодишь - тем меньше денег в итоге получишь, ибо цена и проект изначально обговорены. Совсем плохой код не сдашь, заказчик не примет, но можно сдать средненький. Это waterfall разработка Да, в этих условия TS тебе не применсет больше денег, ибо: - он дает на 20-25% меньше дефектов в продакшене - но при этом +50% количество кода Тут все четко. По теории производства: чем на более раннем этапе производства (прикремил скрин) ты поймал дефект, тем дешевле/быстрее его закрыть. В продакшене супер дорго - на этапе дизайна супер легко. Далее чел привел свою статистику, что им удалось больше денег заработать, когда они внедрили контроль качества в самом начале производственной цепочки. Но вопрос в другом: хочешь ли ты работать в компании, которая делает проекты по фикс прайсу? Мне кажется вот это рак, который этот чел не видит. Тут задача не принести больше валуе клиенту, а побыстрее сдать проект и забыть о нем. Причем качество должно быть минимальным. В таких условия рождается токсичная среда: ты и клиент хотите разного. Я бы не стал в таких условиях работать. В современном мире у программистов есть выбор, куда пойти. Минимальное качество кода - баги в продакшене, плохая архитектура, в которую дорого добавлять фичи или менять части. А бизнес постоянно меняет части и добавляет фичи, ибо он сам в начале не знает, чего хочет. Если убрать из уровнения фикс прайс, а работать по часам, прикрепить карьерный рост к росту прибыли компании, то расклад будет совсем другим. Тут уже нужно замерять количество дефектов в продакшене, против скорости выката новых фич. Тут уже можно думать в аджайл фрэйморке. И TS чувствует себя в этой пирамиде прекрасно: - spec ревью - design ревью - ts - tests - code ревью Все пункты важны. Сказать, что тесты отменьшают валую от ts невозможно, они добавляют друг дргуа. TS это огромное количтво халявных тестов в коде. Но чел прав, что нужно сосредоточится на верхних частых пирамиды в начале, потом идни ниже, но все пункты важны. — Отдельный пункт, о котором тот сказал в скользь в конце, TS упрощает/ускоряет design ревью. — Спасибо что пришли на мой ted talk

Спорно про время разработки. TS позволяет отлавливать многие баги раньше. А за фикс-прайс всё равно заставят все мажорные баги фиксить.

Время он замерил говорит, я склонен верить, что он все время учел и мажорные баги после релиза

1) Куда идти работать это личное дело каждого и кто говорил что это плохо работать там где компания сразу даёт фикс цену? И это бизнес теряет в том что вам платят по часам а клиент платит фикс. 2) Вы путаете свои задачи и задачи бизнеса, это разное. То что для вас идеально может не нравится бизнесу и тд. 3) Под минимальным качеством кода вы наверно понимаете что то не рабочее с плохой архитектурой, есть разница в минимальном и фатальном, не путайте. 4) Возможно, писать код и писать тестируемый код это разные вещи

Вот. Сегодня тоже смотрел) Но меня Илья не убедил)) Там вообще клуб хейтеров ТС)))

Там главный поинт, что он этот эксперимент проводил на реакте... Не сказал бы, что это репрезентативно

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

Добрый вечер, Илья, смотрел ваш доклад "Почему я отошел от TypeScript в своих React-проектаx" https://youtu.be/jnSHRPCTFPc?t=729, но момент про "цена ошибки TS" не до конца понял. Я надеюсь, это все таки выдуманная история? Просто в докладе говорится, что из-за бага приложение сломалось и виновником послужил typescript. В итоге, пациенту вкололи не то лекарство и он умер. Однако почему-то не говорится, что мог по той же причине отвалится бэк апи, бд, какая-то неочевидная ошибка на фронте, которая никакой типизацией не покроется. Да даже Интернет мог упасть. В целом, звучит так, что проблема не в тайпскрипте, а нужно было заранее продумать план B для таких ситуаций - возможно второе приложение со старой версией, в которое выгружаются иногда данные, соответственно с отдельной бд, и можно открывать на случай поломки основного. Или хранить данные чисто на телефоне (или где это было?).

нет, не выдуманная

А стало известно, что они сделали с этим? Как теперь стараются избегать подобных ситуаций?

Да, конечно. Там перечень мероприятий на трёх страницах

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

оно так и рухнуло, просто в условном вью/реакте когда компонент падает визуальной коммуникации из коробки нет если об этом заранее не позаботиться

Жоско по идее, так можно и на 0 случайно поделить и все сломается)

Илья, спасибо за упоминание Рескрипт, надеюсь он начнет набирать популярность, и можно будет пересесть на него)

я в это не верю, тайпскрипт останется мейнстримом

Да щас всем чатом заплюсуем ишуе ни гитхабе, и починят. Ток найти не надо сначала

я стараюсь освещать все изменения которые я приветствую в ТС