Примеры не корректные. В первом примере код на js присваивает getUsers асинхронную лямбду, а код на ts присваивает getUsers сихронную лямбду возвращающую асинхронную лямбду.
Второй пример ещё более не корректен, ts не заставляет переписывать код на классы, наоборот ts стремиться поддерживать все паттерны распространенные для js.
В таком случае код каждой функции (код которой вы не помните наизусть) перед использованием нужно обязательно тщательно изучить. Даже если это стандартная библиотека и функция выглядит как identity(v: T) => T, нужно обязательно проверить не эксплуатирует ли она баг в рантайме и не запускает ли ракету на Марс?
Вряд ли вы так делаете для всех функций которые явно не подозреваете во вредительских намерениях?
Здесь речь о том что для чистых функций предположения о их работе по сигнатуре можно делать легче и с большей степенью вероятности они будут подтверждаться.
Ну а если всё же ракета на Марс запустится, то поможет «многочасовая отладка». Но вероятность что к ней придётся прибегнуть будет меньше.
А теперь представим если бы ФСБ арестовало российского программиста давно живущего в Болгарии за лекцию на Украине, на тему криптовалюты которую он разрабатывает, обвинив в нарушении режима санкций.
Какой бы срач и вой поднялся. Акции протеста, обвинения в тоталитаризме и прочии бурления говн…
А если ФБР арестовало, то все ок. Пара редких комментариев, но в целом он сам виноват :)
Согласен с предыдущим комментатором, если джуниоров больше 2-х, то это многовато.
Кроме того, по опыту знаю что иногда у ревьювера может быть синдром «если код написан не так как написал бы я, то это плохой код». Иногда нужно чуть расслабиться и принять, что способов решить задачу много и код не плохой, а просто не привычный.
Ещё я не понял, привлекаете ли вы сеньёра к review? Если нет, то стоит. Например на задачу назначается два человека: джуниор (который будет делать здачу) и сеньёр который будет его ревьювить. Если потом выясниться что задача сделана косячно, то в первую очередь вопросы к сеньёру.
Так же, вы пишите что не можете позволить им писать плохой код из-за того потенциальных проблем с производительностью. Почему бы при постановке задачи, вместе с ней не поставлять набор перфоманс тестов для неё? Тогда пусть пишут как угодно, но перфоманс-тесты должны пройти. Если нет времени писать, то можно их же заставить писать такие тесты. Тогда вам нужно будет проверить только корректность тестов.
Ну и в конце концов если молодой специалист систематически косячит, не прогрессируют (и может быть при этом перечит), то почему бы его просто не уволить?
К этому надо относиться спокойно. Должность младшего специалиста это фильтр который не все проходят.
После прочтения статьи появляется вопрос, почему для телевизоров пишут на web-технологиях, если там так мало ресурсов? Больше подошло бы что-то вроде Qt.
Ну а втор вроде четко проговорил это в статье, что это нужно чтоб знать сколько ты стоишь :)
А во вторых чтоб не чувствовать не себя самозванцем, синдром самозванца штука не самая приятная.
Ну и кроме того, на сколько я понимаю человеческую природу, для людей характерно стремление проранжировать себя и окружающих в рамках какой-то иерархии.
Но ведь большинство собеседований предполагают тестовое задание, причём периодически его просят сделать до интервью, а не после. А на 10 тестовых заданий нужна прорва времени.
Как вы это перевариваете?
Кроме того если собеседование успешного, то работодатель обычно хочет чтоб ты вышел как можно быстрее и главное ждёт твоего твёрдого да (или обоснованного нет). Что вы делали в такой ситуации, говорили мне нужно месяц подумать? Или у вас было иначе?
Язык разработан с оглядкой на типичный рантайм (например в C# есть такие вещи как volatile и lock, имеющие смысл только в многопоточном рантайме). Так и же и async/await разработан с учётом того что таски могут выполняться в разных нитях: ConfigureAwait(). От этого может меняться тактика работы с async/await, например в C# async await может использоваться для распараллеливания cpu intensive задач, а в js в этом смысла нет.
Ещё один отличием является то обстоятельство что Promise`ы и Task`и не эквиваленты по фичам. Task`и подразумевают отмену операции, соответственно в месте await`а можно получить OperationCanceledException, в js ничего похоже в стандартизированного нет.
В C# таски могут выполняться в другой нити, а в js все асинхронные задачи выполняются в одной единственной нити.
Например поэтому в C# есть такой твик как ConfigureAwait()
Это не путаница, а совмещение
Вы в курсе что ts это js superset?
Уже не надо
Второй пример ещё более не корректен, ts не заставляет переписывать код на классы, наоборот ts стремиться поддерживать все паттерны распространенные для js.
Вряд ли вы так делаете для всех функций которые явно не подозреваете во вредительских намерениях?
Здесь речь о том что для чистых функций предположения о их работе по сигнатуре можно делать легче и с большей степенью вероятности они будут подтверждаться.
Ну а если всё же ракета на Марс запустится, то поможет «многочасовая отладка». Но вероятность что к ней придётся прибегнуть будет меньше.
А теперь представим если бы ФСБ арестовало российского программиста давно живущего в Болгарии за лекцию на Украине, на тему криптовалюты которую он разрабатывает, обвинив в нарушении режима санкций.
Какой бы срач и вой поднялся. Акции протеста, обвинения в тоталитаризме и прочии бурления говн…
А если ФБР арестовало, то все ок. Пара редких комментариев, но в целом он сам виноват :)
Кроме того, по опыту знаю что иногда у ревьювера может быть синдром «если код написан не так как написал бы я, то это плохой код». Иногда нужно чуть расслабиться и принять, что способов решить задачу много и код не плохой, а просто не привычный.
Ещё я не понял, привлекаете ли вы сеньёра к review? Если нет, то стоит. Например на задачу назначается два человека: джуниор (который будет делать здачу) и сеньёр который будет его ревьювить. Если потом выясниться что задача сделана косячно, то в первую очередь вопросы к сеньёру.
Так же, вы пишите что не можете позволить им писать плохой код из-за того потенциальных проблем с производительностью. Почему бы при постановке задачи, вместе с ней не поставлять набор перфоманс тестов для неё? Тогда пусть пишут как угодно, но перфоманс-тесты должны пройти. Если нет времени писать, то можно их же заставить писать такие тесты. Тогда вам нужно будет проверить только корректность тестов.
Ну и в конце концов если молодой специалист систематически косячит, не прогрессируют (и может быть при этом перечит), то почему бы его просто не уволить?
К этому надо относиться спокойно. Должность младшего специалиста это фильтр который не все проходят.
Ну в плане потребности в иерархии, собаки от волков как раз мало отличаются:)
А во вторых чтоб не чувствовать не себя самозванцем, синдром самозванца штука не самая приятная.
Ну и кроме того, на сколько я понимаю человеческую природу, для людей характерно стремление проранжировать себя и окружающих в рамках какой-то иерархии.
Как вы это перевариваете?
Кроме того если собеседование успешного, то работодатель обычно хочет чтоб ты вышел как можно быстрее и главное ждёт твоего твёрдого да (или обоснованного нет). Что вы делали в такой ситуации, говорили мне нужно месяц подумать? Или у вас было иначе?
Ещё один отличием является то обстоятельство что Promise`ы и Task`и не эквиваленты по фичам. Task`и подразумевают отмену операции, соответственно в месте await`а можно получить OperationCanceledException, в js ничего похоже в стандартизированного нет.
Например поэтому в C# есть такой твик как ConfigureAwait()