Для наглядности будут показаны примеры конкретных задач для позиции Senior Frontend Developer. Как и в прошлый раз, сама роль и стек технологий не играет большой роли. Если бы я нанимал DevOps или QA - подход был бы примерно тот же.

За начальное условие мы берем уже как-то настроенный процесс найма с воронкой из нескольких этапов, где мы уже отсеяли большую часть входного потока кандидатов на этапе L0 (HR) и L1 (технический скрининг). Если человек не может внятно ответить как работает Event loop в JS и bubbling/capturing DOM-событий - воронка должна это отловить как можно раньше. До того как он попадет на главное 2-3 часовое тех. интервью с самыми экспертными ребятами из вашей команды.

Структура интервью

1. Знакомство. Предыдущий опыт (5-15 минут)

2. Валидация знаний по основному стеку из резюме (10-20 минут)

3. Практические задачи (50-90 минут)

4. System design (15-30 минут)

5. Понимание agile-процессов (10-15 минут)

6. Продаем кандидату нашу вакансию (10-20 минут)

Иметь четкий план на интервью всегда лучше, чем импровизация. Поэтому, перед тем как собеседовать кандидатов, интервьюеру будет полезно проделать определенную домашнюю работу и стандартизировать процесс. Я обычно стараюсь поместить кандидатов в более-менее одинаковые условия по формату, сложности задач, продолжительности интервью. Так легче объективно оценивать уровень экспертности инженеров и сравнивать их между собой.

В целом, все интервью построено по нарастанию сложности вопросов и задач. Это не значит, что в начале мы спрашиваем элементарные вещи из документации или туториалов. Для этого в воронке найма есть предыдущий этап скрининга. На главном техническом интервью не должно быть легких вопросов, которые гуглятся за 5 секунд. Особенно на позицию Senior.

Практические задачи - обязательная и самая важная часть интервью, она же самая стрессовая для кандидата. Поэтому, я подвожу интервью к ней плавно, давая человеку время почувствовать себя в своей тарелке, привыкнуть к обстановке и набрать уверенности.

Знакомство. Предыдущий опыт

Знакомство - процесс обоюдный. Перед тем как начать спрашивать кандидата про его опыт, неплохо хотя бы парой фраз рассказать кто вы и чем занимаетесь в данной компании.

В начале интервью даем кандидату время, чтобы он спокойно без стресса рассказал то, что он точно знает - чем он занимался на последнем месте работы. Меня в первую очередь интересует не стек технологий, проект или архитектурные решения, а такие вещи как: а) Размер команды? б) Роль и зона ответственности кандидата? в) Кто принимал основные технические решения в команде? г) Есть ли менеджерский опыт или только технический? д) Как были устроены процессы внутри команды?

Я считаю это более важным, потому что для человека проще изучить новую библиотеку для state management, чем перейти из микро-стартапа где всего 10 человек в крупную компанию, где 10 человек только коммитят с тобой в одну репу каждый день. Не все готовы работать с огромным объемом чужого кода и искать компромиссы. Не все готовы работать по четким процессам с оценками и сроками. Если для вас это актуально - будет не лишним обратить внимание насколько вы подходите друг другу с кандидатом концептуально.

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

Валидация знаний по основному стеку из резюме

Продолжаем разговор в области, которую кандидат знает хорошо(но это не точно...). Можно довольно быстро померить глубину технических знаний, если начать задавать advanced-вопросы по тому стеку, который человек считает основным для себя. Даже если этот стек не пересекается с нашим. Пример:

У нас на проекте React, но человек больше работал с Angular - не страшно. Я спрошу как работает change detection и zone.js в Angular. Зачем в Angular модули (NgModule) и как работает Dependency Injection. Если человек эксперт в своем текущем стеке - он так же глубоко изучит и новый. Плюс это лучше выявляет синьйорность, чем работал/не работал с библиотекой X.

Так же работает в обратную сторону. Если знания поверхностные даже в технологиях, с которыми человек работает каждый день - половину следующих вопросов из категории "сложные" можно будет даже не задавать и сэкономить себе время.

Другой пример - TypeScript. В резюме есть у каждого frontend-разработчика, но большинство его знают и используют процентов на 30. Затипизировать пропсы в React-компоненте могут многие, но это мало что говорит об уровне знаний языка. Вот пара примеров, как можно быстро определить эксперта в TypeScript.

Пример 1:

const arr1 = [1, 2, null, 3]
const arr2 = arr1.filter((item) => item !== null)

Какой тип arr1? Ответ - (number | null)[]

Какой тип arr2? Ответ - (number | null)[]

Как нам сделать так, чтобы TypeScript понял, что мы отфильтровываем null в рантайме и вывел arr2 тип как number[] в compile-time? А если без кастинга as ?

function isNonNullable(value: T | null | undefined): value is T {
  return value !== undefined && value !== null
}
const arr1 = [1, 2, null, 3]
const arr2 = arr1.filter(isNonNullable)

Пример 2:

Написать хелпер, который может из любого интерфейса достать поля определенного типа:

type Project = {
  name: string
  description: string
  start_date: Date
  end_date: Date
}

type ProjectDates = PickByType<Project, Date>
// {
//    start_date: Date;
//    end_date: Date;
// }

type ProjectInputFields = PickByType<Project, string>
// {
//    name: string;
//    description: string;
// }

type PickByType<Target, Condition> = Pick<
  Target,
  { [Key in keyof Target]: Target[Key] extends Condition ? Key : never }[keyof Target]
>

Решение занимает пару строк и пару минут времени. Если кандидат не справляется - пока ничего страшного, идем дальше. Но если справляется - скорее всего перед вами настоящий технарь, который копается в технологиях глубже чем большинство. Хороший знак.

Практические задачи

Существует много хейта в сторону leetcode-задач. Основная претензия - нерелевантность реальным задачам на работе. React-разработчику не нужно знать алгоритмы и т.п. С алгоритмами история отдельная - ты их либо знаешь либо нет, и это действительно не самый лучший показатель для найма. Но если задача универсальная и не требует каких-то специфических знаний кроме знаний языка - это как раз то, что нужно для объективной оценки software-инженера. Причем, как hard, так и soft-навыков. Помимо программирования, кандидат демонстрирует навык обработки и уточнения требований к задаче. Быстро ли он сдается, если что-то не получается. Проявляет ли он раздражение при этом или самоиронию. Все это не менее важно чем скорость и корректность написанного кода.

Я обычно начинаю с задачки на логику, без программирования. Например - Какой угол составляют часовая и минутная стрелка в 15:15? Отличный способ размяться для кандидата и настроиться на практическую часть интервью. Задача совсем не про программирование, но на практике, те кто ее заваливает, так же не блещут и в следующих задачах с кодом. Далее начинаем писать код и постепенно повышаем сложность. Пользоваться гуглом в процессе разрешается.

Задача #1

Реализовать функцию reduce() из стандартной библиотеки JS.

Не должно занимать много времени. Если закапываемся на этом месте - можно досрочно завершать интервью и сэкономить всем полтора часа времени.

После успешной реализации, прошу затипизировать функцию как в стандартной библиотеке TypeScript с выводами типов аргументов и результата. Еще одна проверка на экспертность в TS. Так же не является приговором если человек не справится.

Задача #2

Реализовать функцию throttle() из lodash. Можно без третьего аргумента, чтобы сэкономить время.

Хороший знак, если программист сразу видит решение через рекурсию, а не спустя 30 минут тщетных попыток покрыть все кейсы дополнительными флагами и условиями в коде.

Задача #3

Выполнить code-review уже реализованного, адаптивного React-компонента. Найти проблемы и отрефакторить.

В отличие от предыдущих, данная задача максимально приближена к реалиям. Для меня очень важно под каким углом человек анализирует код на ревью. Если он фокусируется на code-style, названии переменных, замене if/else на тернарный оператор - это скорее тревожный звонок. Синьйор в первую очередь должен найти концептуальную ошибку в данном коде. Если просто представить как мы будем использовать этот компонент в реальном приложении, станет очевидно, что интерфейс компонента некорректный и его нужно полностью менять.

Как всегда, задача со звездочкой - затипизировать компонент как можно универсальней для compile-time на TypeScript.

System design

Опциональная секция. Имеет смысл обсуждать если практическая часть пройдена уверенно.

У frontend-разработчиков я обычно прошу спроектировать небольшое React-приложения, описать его структуру и выделить слои для разделения логики. В React-мире нет какой-то канонической архитектуры, скорей наоборот. Поэтому настоящего синьйора/архитектора определить довольно просто. Если он решает любую задачу по шаблону как в туториалах: компоненты + хуки + Redux - это точно не он. Опытный программист уже видел проекты, которые писались по такому шаблону и у него должен сработать инстинкт самосохранения. Настоящий инженер при проектировании не ищет самый короткий путь как реализовать исходные требования, т.к понимает, что это лишь отправная точка, а, в первую очередь, старается создать благоприятные условия для дальнейших изменения в проекте для себя и коллег по команде. В первую очередь он хочет спокойно спать по ночам при добавлении новой фичи в проект и не гадать, какие модули он мог случайно задеть в процессе.

Когда я собеседовал Golang-разработчиков, просил спроектировать бэкенд архитектуру для сервиса с котировками акций, в который будет ходить фронтенд для отрисовки realtime-графиков. Принцип тот же самый: по туториалу такую задачу не решить, только на опыте.

Понимание agile-процессов

Секция так же опциональная. Актуально для компаний где эти процессы есть)

Для таких компаний при найме будет полезно обсудить на берегу с кандидатом, насколько он готов играть по четким правилам и насколько он командный игрок. Есть такой тип инженеров, которые считают любые процессы лишней бюрократией и всячески пытаются их избежать. Вместо этого они хотят писать код без оценок и сроков, по принципу: когда сделаем - тогда сделаем.

Для моей компании процессы и сроки были очень важны, поэтому я прощупывал этот момент на собеседовании. Помимо матчасти про Scrum/Kanban, можно попросить рассказать детально весь цикл разработки от оценки до релиза на прод на текущем месте работы. Очень важно, чтобы горизонт разработчика не ограничивался мержем ветки в master и он понимал весь жизненный цикл разработки продукта.

Продаем кандидату нашу вакансию

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

Осталось рассказать про вашу команду и проекты, делая фокус на том что вас выделяет на фоне остальных. Например, у вас передовые технологии: k8s / GRPC / CI/CD / e2e-тесты / screenshot-тесты / micro-frontends / module-federation и т.д - большой плюс. Если у вас по-настоящему крутые процессы - расскажите про это. Мало у кого они есть. Если у вас подобралась звездная команда - используйте это как рекламу. Люди тянутся к тем у кого можно чему-то научиться.

Но главное - вы сами на протяжении всего интервью должны быть рекламой вашей компании. Нужно показать, что вы компетентны, но не душнить. Задавать сложные вопросы, но на легкой волне, не напрягая излишне обстановку. Не стоит сидеть 3 часа с серьезным лицом и гонять человека по списку вопросов как на экзамене. Харизма, чувство юмора - все можно пустить в ход если для вас это естественно в обычной жизни. Будет лучше, если кандидат в вашем лице увидит живого человека, с которым он с удовольствием пообщался бы после интервью. А не профессора, от которого хочется убежать как только получил зачет.

Заключение

Пишите в комментариях, если интересно продолжение цикла статей. Делитесь своим опытом и подписывайтесь на канал в Telegram.

Что такое фриланс виза в ОАЭ?

Если очень коротко - это просто отдельный вид визы резидента ОАЭ (аналог ВНЖ), выданный на срок от 1 до 2 лет, с возможностью дальнейшего продления неограниченное количество раз.

Виза оформляется на основании Freelance Permit - официальная лицензия на ведение профессиональной деятельности в своей области с территории ОАЭ в качестве фрилансера. Статус лицензированного фрилансера позволяет работать с любыми компаниями внутри и за пределами ОАЭ в рамках своей специальности (IT, маркетинг, дизайн, продажи и т.д). Подтверждать профессию наличием диплома или опытом работы не нужно.

Что дает статус резидента ОАЭ?

1. Право на долгосрочное проживание в стране для себя и семьи

2. Оформление Emirates ID - местное удостоверение личности

3. Возможность открыть личный счет в местном банке

4. Возможность заключать долгосрочный контракт аренды жилья. Не резиденты по закону могут арендовывать только на короткий срок (booking, airbnb и т.д).

5. Доступ к школам и детским садам (на платной основе)

6. Статус налогового резидента ОАЭ после 90 дней проживания в стране

Что нужно для оформления фриланс визы?

Список требований и документов максимально простой:

1. Паспорт и фото в электронном виде

2. Оплатить все сборы за Freelance Permit, Establishment Card и саму визу на 2 года ~3900$. Freelance Permit и Establishment Card придется продлевать каждый год. Стоимость продления на второй год будет ~2600$.

3. Местная сим-карта (можно оформить после подачи заявления)

4. Пройти медосмотр

До прохождения медосмотра все можно делать удаленно. На медосмотр и биометрию нужно уже приехать в Дубай.

Процесс легализации по шагам

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

Весь процесс по стандартной процедуре занимает от 2 месяцев. Находиться в Дубае нужно при этом минимум месяц. Есть вариант доплатить за ускоренный вариант оформления визы, но сроки мне неизвестны.

1. Оформление Freelance Permit онлайн

На данном шаге находиться в ОАЭ необязательно. Все что нужно - зарегистрироваться на сайте https://gofreelance.ae/ и следовать их инструкции. Обязательно указываем, что нам нужно так же сделать Establishment Card. Оплачиваем 2600$ и через несколько дней в личный кабинет приходит ваш Freelance Permit с Establishment Card в электронном виде.

Сроки: до 7 дней

2. Подаем заявку на визу

Все еще необязательно находиться в ОАЭ. В том же личном кабинете подаем заявку на Employee визу на 1 или 2 года. Нюанс в том, что для наемных сотрудников и фрилансеров используется одна форма для подачи заявки. Поэтому там где обычных employee просят загрузить Employment Contract и Degree Certificate - просто загружаем копию своего Freelance Permit. Health insurance оставляем пустым. Страховку можно оформить позже по желанию. Оплачиваем сбор за визу ~1300$ за 2 года. Далее ждем приглашения на медосмотр.

Срок ожидания: 7-14 дней

3. Медосмотр и получение визы

С этого момента нужно уже находиться в Дубае. Медосмотр занимает 30 минут. Результат подгружается в личный кабинет автоматически после прохождения. Никаких дополнительных действий не требуется. Просто ждем результатов и приглашения на биометрию.

В течение недели после прохождения медосмотра вы уже получаете визу в электронном виде. Вклеивать визу в паспорт не нужно, она будет прикреплена к Emirates ID.

Сроки: ~7 дней

4. Получение Emirates ID

Без EID, даже будучи резидентом, нельзя полноценно пользоваться банковскими или другими гос. услугами. После получения визы в личном кабинете автоматически создастся заявка на EID и будет назначена дата для сбора биометрии. После чего в течение недели EID доставляют курьерской службой по адресу проживания.

Важный момент - у вас может смениться адрес проживания в Дубае или номер телефона с момента подачи заявки на визу. Поэтому после биометрии, как только получаете трекинговый номер доставки, сразу можно позвонить в курьерскую службу и актуализировать номер телефона и адрес доставки. А еще лучше приехать к ним в офис и забрать EID лично, предварительно предупредив по телефону. Это самый быстрый способ на практике.

Сроки: ~2-4 недели

5. Банки

После получения EID можно открывать счета в банках. Для того, чтобы закрыть все свои возможные потребности для комфортного проживания в ОАЭ, вам понадобится:

1. Счет + банковская карта в местной валюте AED для повседневных трат

2. Счета в USD / EUR если получаете доход в этой валюте из другой страны и хотите платить с него налоги (а точнее не платить) в ОАЭ

3. Чековая книжка. В Дубае при заключении контракта на аренду жилья нужно выписывать чеки

Этап открытия счета в банке немного сложнее чем все предыдущие. По состоянию на начало 2023 года, несмотря на полную легализацию, наличие резидентства и EID, банки не очень охотно открывают счета клиентам с комбинацией: гражданин РФ + фрилансер. Причины, в целом, понятны. Вот два банка, в которых я в итоге открыл счета:

1. https://www.bankfab.com/

   Подавать заявку нужно в мобильном приложении. Если придти в отделение с паспортом РФ - фрилансеру скорее всего откажут. Если просят salary certificate - скачиваем его из личного кабинета, где оформляли freelance permit. Стоит 60 AED.

   Открывают счет AED, debit card и чековую книжку. Валютные счета не открывают.

2. https://www.emiratesnbd.com/

   Тут все наоборот. Заявку в мобильном приложении могут обрабатывать пару недель, а потом сказать, что фрилансерам счета открывают только в отделении. В отделениях есть некий рандом. В один день могут попросить огромную стопку документов с подтверждением адреса проживания, utility bills, bank statement и т.д. В другой день в этом же отделении достаточно показать EID и salary certificate из личного кабинета.

   Открывают счет AED + debit card, чековую книжку и валютные счета без пластиковых карт. Можно конвертировать валюту в мобильном приложении. Swift будет работать, но только не в РФ.

апдейт от 01.12.2023:

Теперь открыть мультивалютную карту и чековую книжку можно очень просто в необанке https://wio.io . Все в приложении, нужен только Emirates ID без каких-либо справок.

6. Налоги

В ОАЭ с налогами все очень просто. Если ты обычный employee в местной компании - налог 0% на любую сумму дохода. Если ты фрилансер - у тебя мини-компания с единственным сотрудником, поэтому доход может облагаться в теории VAT(НДС) 5% и Corporate Tax 9%. Если мы работаем с иностранными заказчиками и не продаем услуги внутри ОАЭ - VAT будет 0%. Для Corporate Tax есть правило Small Business Relief, которое освобождает от налога если суммарная выручка в год не превышает AED 3 000 000 (~$817 000). До оборота 100 000$ в год никакую отчетность можно вообще не подавать в налоговые органы. Если получаем доход на счет в ОАЭ, имеем разрешение на работу и можем обосновать поступления рабочими контрактами или инвойсами - эти деньги уже ваши и полностью белые.

Есть так же документ - сертификат налогового резидента ОАЭ. Выдается по запросу. Местным налоговым органам он не нужен, но может понадобится по месту гражданства. Если вы, например, начнете переводить деньги в РФ (через банки в странах СНГ или другим способом) и у местных органов в РФ возникнут вопросы по происходжению этих денег и уплате налогов, т.к вы не живете в РФ и не являетесь налоговым резидентом там, нужно будет просто предъявить тот самый сертификат налогового резидента ОАЭ, который докажет, что с этих денег вы уже заплатили налоги в другой стране.

Можно ли жить вне ОАЭ сохраняя статус резидента?

Ответ - да. Для того, чтобы сохранять статус резидента ОАЭ по фриланс визе нужно выполнять одно простое условие - не находиться за пределами страны дольше 6 месяцев подряд. Другими словами, если вам не очень нравится местная жара или хочется попутешествовать - можно просто посещать ОАЭ раз в 5 месяцев на пару недель и работать удаленно из любой другой страны большую часть года.

Пока вы не стали налоговым резидентом в другой стране (как правило после суммарного проживания > 183 дней в году в одном месте), ваши доходы в ОАЭ по прежнему облагаются только местными налогами: 0% НДФЛ, 0% или 5% VAT в зависимости от суммы дохода.

Заключение

Спасибо, что дочитали. Надеюсь сэкономил кому-то время на поиск информации. Если остались вопросы по теме - пишите в комментариях под этим постом или в Телеграм канале. Всем удачной релокации)

Далеко не все осознают насколько мощный инструмент достался frontend-сообществу и какие он открывает возможности для того, чтобы писать удобный, выразительный и супер-надежный код. Особенно это актуально в больших проектах. По моим ощущениям, большинство разработчиков используют TS процентов на 30% от его потенциала. Надеюсь данный цикл статей поможет немного исправить ситуацию.

Вводный пример

Мы хотим использовать в своем приложении API с данными о погоде за определенные даты. URL Get-запроса выглядит так - https://archive-api.open-meteo.com/v1/era5?latitude=52.52&longitude=13.41&start_date=2021-01-01&end_date=2021-01-03&hourly=temperature_2m. Как мы можем описать в TS интерфейс функции, которая будет выполнять этот запрос? Обычно это делают следующим образом:

// Объявляем функцию и тип параметров
type GetWeatherRequestParams = {
  latitude: number
  longitude: number
  start_date: string
  end_date: string
  hourly: 'temperature_2m' | 'windspeed_10m'
}

export function getWeather({ longitude, latitude, start_date, end_date, hourly }: GetWeatherRequestParams) {
  const baseUrl = 'https://archive-api.open-meteo.com/v1/era5'
  return fetch(`${baseUrl}?latitude=${latitude}&longitude=${longitude}&start_date=${start_date}&end_date=${end_date}&hourly=${hourly}`)
}

// Вызываем функцию где-то в нашем приложении
const response = getWeather({
  latitude: 52.52,
  longitude: 13.41,
  hourly: 'temperature_2m',
  start_date: '2021-01-01',
  end_date: '2021-01-03',
})

Все работает, мы получили данные в ответе. Теперь другая ситуация. Мы интегрируем эту функцию с виджетом календаря, который возвращает нам две даты типа Date.

function onDateChange(start_date: Date, end_date: Date) {
  const response = getWeather({
    latitude: 52.52,
    longitude: 13.41,
    hourly: 'temperature_2m',
    start_date: start_date.toISOString(), // приводим Date к строковому представлению, в соответствии объявленному типу выше
    end_date: end_date.toISOString(),
  })

  console.log(response)
}

Запускаем, наш код выполняет запрос https://archive-api.open-meteo.com/v1/era5?latitude=52.52&longitude=13.41&start_date=2023-01-01T20:00:00.000Z&end_date=2023-01-07T20:00:00.000Z&hourly=temperature_2m, и мы получаем ответ с ошибкой из API - {"error":true,"reason":"Invalid date format. Make sure to use 'YYYY-MM-DD'"}. Оказывается, нужно передавать дату в строгом формате YYYY-MM-DD, но наш тип start_date: string, end_date: string пропускает любую строку. В этом месте у нас runtime разошелся с compile-time. Для компилятора, передача любой строки в функцию getWeather считается корректной, но в реальной жизни это не так. Как мы можем решить эту проблему?

Сразу скажу, что вариант писать комментарии к функции или к отдельным ее аргументам, показывая пример какой именно формат даты можно передавать - плохая идея. Мы полностью доверяемся человеческому фактору и начинаем общаться внутри команды некими "тайными записками", в надежде, что их кто-нибудь прочитает. Поэтому нам нужна статическая проверка в compile-time, которая будет отличать разные форматы внутри одного примитивного типа (String) и обрабатывать их как несовместимые.

Мы хотим чтобы все даты в формате YYYY-MM-DD были отдельным типом, который был бы не равен типу string, но в то же время вел себя как string, если мы хотим использовать его для конкатенации строк или приведению в lower или upper-case.

Номинальные типы

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

type DateString = string

type GetWeatherRequestParams = {
  ...
  start_date: DateString
  end_date: DateString
}

...

function onDateChange(start_date: Date, end_date: Date) {
  const response = getWeather({
    ...
    start_date: start_date.toISOString(), // Все еще нет ошибки в compile-time
    end_date: end_date.toISOString(),
  })
}

Чтобы сделать тип DateString несовместимым с типом string, нужно подмешать в него что-то уникальное, например вот так:

declare const NominalType: unique symbol
type DateString = string & { readonly [NominalType]: 'DateString' }

...

function onDateChange(start_date: Date, end_date: Date) {
  const response = getWeather({
    ...
    start_date: start_date.toISOString(), // TS падает с ошибкой в compile-time - `Тип "string" не может быть назначен для типа "DateString"`
    end_date: end_date.toISOString(),
  })
}

Мы создали номинальный тип DateString, который является уникальным по отношению к базовому типу string. Теперь в функцию getWeather() нельзя передать в качестве дат случайные строки. Но где нам теперь брать даты в нужном формате и с нужным типом?

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

// Объявляем общий хелпер
function dateToDateString(date: Date): DateString {
  const year = date.getFullYear()
  const month = date.getMonth().toString().padStart(2, '0')
  const day = date.getDate().toString().padStart(2, '0')

  return `${year}-${month}-${day}` as DateString // это будет единственное место в нашем проекте, где мы используем кастинг as DateString
}

...

function onDateChange(start_date: Date, end_date: Date) {
  const response = getWeather({
    ...
    start_date: dateToDateString(start_date), // преобразуем Date в DateString - нет ошибки в compile-time
    end_date: dateToDateString(end_date),
  })
}

Теперь у нас есть прочный мост между compile-time и runtime. Если мы где-то в приложении ожидаем в runtime дату строго в формате YYYY-MM-DD - компилятор не позволит нам собрать проект, пока мы не убедимся при помощи хелпера dateToDateString(), что мы преобразовали дату в нужный формат.

Другие примеры

1. Добавляем номинальные типы в стандартную библиотеку TS или внешние пакеты

export type ISODateString = string & { readonly [NominalType]: 'ISODateString' } // объявляем отдельный тип для дат в формате 2023-01-07T20:00:00.000Z

declare global {
  interface Date {
    toISOString(): ISODateString // типизируем стандартный класс Date как источник дат в формате ISODateString
  }
}

declare module 'moment' {
  interface Moment {
    toISOString(keepOffset?: boolean): ISODateString // типизируем библиотеку moment.js
  }
}

const date3: ISODateString = new Date().toString() // TS Error - Тип "string" не может быть назначен для типа "ISODateString"
const date2: ISODateString = new Date().toDateString() // TS Error - Тип "string" не может быть назначен для типа "ISODateString"
const date1: ISODateString = new Date().toISOString() // корректно

const date4: ISODateString = moment().toString() // TS Error - Тип "string" не может быть назначен для типа "ISODateString"
const date5: ISODateString = moment().toISOString() // корректно

1. Делаем id разных сущностей уникальными, чтобы нельзя было по ошибке передать id от одной сущности в функцию, которая ожидает id совершенно другой сущности.

declare const NominalType: unique symbol
type NominalString<TypeIdentifier> = string & { readonly [NominalType]: TypeIdentifier }

type ProjectId = NominalString<'ProjectId'>
type Project = {
  id: ProjectId
  name: string
}

type ProductId = NominalString<'ProductId'>
type Product = {
  id: ProductId
  description: string
}

function getProductPhotos(id: ProductId) {...}

const project: Project = {...} // сокращаю детали для наглядности
const product: Product = {...}

const photos1 = getProductPhotos(project.id) // TS Error: Аргумент типа "ProjectId" нельзя назначить параметру типа "ProductId".

const photos2 = getProductPhotos(product.id) // ошибки нет, тип соответствует

1. Делаем работу с JSON-сроками более безопасной.

type JSONstring<T extends unknown> = NominalString<'JSONstring'>

function encodeJSON<T extends unknown>(data: T) {
  return JSON.stringify(data) as JSONstring<T>
}
function parseJSON<T extends unknown>(string: JSONstring<T>) {
  return JSON.parse(string) as T
}

...

const productJSON = encodeJSON(product) // Тип productJSON автоматически вывелся как JSONstring<Product>. Это уже строка, но TS будет помнить что в ней закодирован объект типа Product

const parsedProduct = parseJSON(productJSON) // Тип parsedProduct автоматически вывелся как Product, что полностью соответствует рантайму.

Теперь нам не нужно делать кастинг as при вызовах encodeJSON() и parseJSON(). Для encodeJSON() источником правды является исходный тип, который мы в него передаем. Для parseJSON() источником правды является результат encodeJSON(), который запомнил исходный тип структуры, которую он кодировал.

Заключение

Таким образом, использование номинальных типов позволяет нам сократить разрыв между runtime и compile time в тех местах, где мы обычно оставляем пространство для ошибок и надеемся на человеческий фактор. Это дешевый и довольно эффективный способ перенести дополнительные проверки на TS, сделав кодовую базу чище и надежней.

Пишите в комментариях свое мнение на данную тему и насколько вам в целом интересно продолжение цикла статей про TypeScript.

Те же самые принципы актуальны для зрелой компании, которая смогла занять свою нишу на рынке. Особенно если компания на волне успеха начинает бесконтрольно масштабироваться, раздувает штат и становится неповоротливой. В конечном итоге она может проиграть конкуренцию более молодым игрокам, которым удается быстрее развивать свой продукт под потребности рынка или сделать его дешевле, за счет более эффективной разработки.

Главное заблуждение разработчиков

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

К сожалению, очень часто я вижу одну и ту же ошибку, которую совершают люди, с техническим складом ума, излишне фокусируясь на одном аспекте, кажущемся им решающим. На практике же, он может не давать никакого эффекта кроме психологического, оставляя все вышеперечисленные проблемы нерешенными. Начнем с самого яркого примера.

Выбор стека технологий

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

Ruby on Rails - MVC фреймворк нового поколения, где обо всем подумали за разработчика. Функциональное программирование (Clojure как пример) - отдельный мир для избранных, где не нужно страдать. TDD - максимальное покрытие кода тестами, ошибки отлавливаем раньше. Test First помогает лучше проектировать модули. NoSQL - гибкость и масштабируемость. GraphQL - не нужно тратить время на новые ручки API, фронтенд сам заберет все, что ему нужно. Знакомо? Можно продолжить. React.js - спаситель фронтенда, на который нужно срочно перейти с любого другого фреймворка и забыть о проблемах на клиенте. Redux - теперь уже точно на фронтенде полное счастье. По другому быть просто не может.

Неужели это все неправда? И да и нет. Технологии могут быть прекрасными, но они сами по себе не решают изначальную проблему эффективности разработки продукта, т.к это всего-лишь инструменты. Представьте, что вы строите многоэтажное здание в суровом климате с непростым природным ландшафтом и капризной почвой. У вас есть современные краны, пневмонагнетатели, лазеры для установки уровней и весь необходимый инструментарий в руках рабочих. Достаточно ли этого, чтобы построить устойчивое здание, которое простоит десятки лет и не разрушится под воздействием переменчивой окружающей среды? Очевидно, что нет. Ключевым фактором будет точный расчет архитекторов и инженеров нагрузки на опоры, исследование почвы на предмет пригодности к возведению высотных зданий и учет перепада температуры в зимнее и летнее время.

В разработке программного продукта ситуация примерно такая же. Что приводит нас к следующему фактору эффективности.

Архитектура

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

Короткий пример из мира фронтенда: популярная связка React.js + Redux. В какой-то момент хайп достиг такого уровня, что все новые проекты использовали данный стек, в полной уверенности в своем успехе. Проблема в том, что React это всего лишь view-библиотека для отрисовки компонентов, а Redux не умеет ничего, кроме сохранения состояния в один громадный глобальный стор. Эти две библиотеки, в теории, давали возможность написать что угодно, но не предлагали никаких идей по организации структуры приложения, модульности, разделению логики по слоям (view, business логика, application логика, API), выделению доменов и bounded contexts. В результате каждый React-проект был велосипедом, рандомно структурированным, с огромнымным скоплением логики на View-уровне или в Redux-сторе.

Какой можно сделать из этого вывод? В первую очередь нужно позаботиться о том, чтобы в долгоживущем проекте на старте было достаточно экспертизы для создания надежной архитектуры, и только потом выбирать инструменты. Подчеркну - именно экспертизы. Какую должность занимает человек при этом не так важно.

Но достаточно ли этого, чтобы вывести разработку на максимальные обороты, или есть еще что-то важнее архитектуры и инструментов? Кажется, что есть.

Управление и процессы

Этот пункт менее актуален в микро-проектах на старте, когда вся команда помещается в один опенспейс или в один daily-синк в Zoom. Но это не значит, что им можно пренебрегать. У нас есть архитектура и мощный стек, который помогает инженерам закрывать задачи быстро и с хорошим качеством. Но как организован процесс разработки? Проводит ли команда оценку перед тем как начать разработку? Распараллелен ли процесс разработки или все блокируют всех? В какой момент задаются неудобные вопросы по требованиям: в момент когда уже разработка началась или перед тем как дать оценку? Как распределяются задачи внутри команды? Нет ли дисбаланса, когда одна часть команды перегружена, а другая скучает? Рассмотрим пример:

Нужно добавить в продукт новый раздел с отзывами или комментариями, например, на товар. Эта фича включает в себя: новый дизайн, новое API, новый экран или виджет на фронте.

Вариант №1 - берем и делаем

1. Ждем дизайн (2 дня)

2. Посмотрели - вроде все хорошо. Начинаем делать API (4 дня)

3. API готово. Начинаем делать фронтенд (еще 4 дня). В конце сами себя спрашиваем "А должны новые отзывы появляться автоматически после загрузки или только при следующем заходе на страницу? Кажется мы это в API не предусмотрели...". Потратили еще 1 день на обсуждения и дополнительный костыль в виде периодического передергивания ручки с фронта. Параллельно уже боимся, что на проде API может стать плохо от такого объема запросов, но переделывать уже времени нет.

4. Отдаем в тестирование, фиксим баги (еще 3 дня).

5. Все протестировано можно мержить в мастер. Создаем огромный Merge Request, начинается код-ревью остальными участниками команды. Замечаний очень много, исправлять их долго и страшно т.к фича уже протестирована. Внесение серьезных изменений потребует повторного тестирования. (еще +3 дня)

   Итого - 17 дней, уже имеем техдолг, а мы еще не на проде.

Вариант №2 - оценка, контракты, параллельная разработка

1. Дизайн не зависит от занятости команды, поэтому он рисуется заранее по первому запросу от бизнеса "в стол". На момент, когда команда готова взять новую фичу, дизайн уже готов.

2. Смотрим дизайн, задаем вопросы (в том числе про автоматическое появление новых отзывов). Описываем контракты для нового API, шарим их с фронтенд командой. Тратим дополнительно на эту подготовку 1 день.

3. Стартуем разработку бэкенд/фронтенд параллельно по контрактам, договорившись какие ручки API нужно выдать в первую очередь для интеграции. Как только появляются первые рабочие end to end-сценарии, QA начинает их тестировать и репортить баги, которые закрываются параллельно с разработкой. Декомпозируем фичу на мелкие задачи и выкладываем их на код ревью атомарно, по мере готовности. Оперативно ревьюим и правим замечания мелкими порциями (5 дней на все).

4. На этом этапе у нас уже закончена разработка и исправлена большая часть багов. Исправляем то, что осталось. (2 день)

5. Весь код уже прошел ревью на предыдущих этапах. Можно мержить в мастер.

   Итого: 8 дней, без техдолга, с предварительной оценкой и пониманием когда фича будет готова к релизу на прод, с точностью до пары дней.

Кто за это отвечает? Чаще всего - тимлид. Хотя, как и в прошлом пункте, должность тут вторична.

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

Кадры и найм

Ингридиент, который я субъективно считаю самым важным из всех. Он может на практике, как нивелировать отсутствие любого из вышеперечисленных пунктов, так и не позволить им заработать уже на начальном этапе. То, с чего нужно начинать разработку любого серьезного продукта. Найм и формирование профессиональной команды.

Данная тема настолько обширная, что заслуживает отдельной статьи. Сейчас же, я лишь сформулирую основные тезисы:

1. Профессионализм и ответственность - качество номер один.

2. Проактивность. Человек на любой позиции в команде чувствует неудовлетворенность если видит какую-то нерешенную проблему. Он не ждет задачи сверху, а проявляет инициативу сам.

3. Soft-skills так же ценны как hard-skills, иногда даже ценнее.

4. Умение работать на команду. Довольно сложно проверить на этапе интервью, но возможно.

Почему это так важно? Это не всегда очевидно, но самая дорогая часть разработки это не сам процесс написания кода, тестирования или баг-фикса. Дороже всего обходятся лишние итерации на стыке разных стадий разработки и разных ролей в команде. С какого раза бэкенд-инженер выдаст по-настоящему рабочее API фронтенд-команде? Сколько раз нужно будет тестировщику перепроверять и возвращать на доработку одну и ту же задачу, перед тем как она будет пригодна для продакшна? Можем ли мы закрыть все вопросы по требованиям за одну встречу перед стартом разработки или будем постоянно стопориться в процессе спринта и на ходу додумывать корнер-кейсы?

Профессионалы, обладающие всеми перечисленными качествами, будут интуитивно экономить вам время на каждом из этапов, и их об этом даже не придется просить. Им небезразличен результат. Такая команда может эффективно деливерить даже с неидеальной архитектурой, не самым мощным стеком и даже без выверенных процессов. Поэтому, я считаю, что кадры - это самый главный фактор успеха эффективной разработки, на основе которого строится все остальное.

Заключение

Мой топ по мере важности выглядит так:

1. Кадры и найм

2. Управление и процессы

3. Архитектура

4. Стек технологий

В этой иерархии бывают исключения. Иногда выбор стека может существенно повлиять на структуру команды и процессы разработки. Например, кроссплатформенный фреймворк для мобильного приложения, как альтернатива отдельным командам iOS + Android, позволяет существенно сократить time to market в мобильном продукте, одновременно снизив стоимость разработки и тестирования. Об этом, возможно, будет отдельный пост. Но даже в этом случае, расставить приоритеты в предложенном порядке, с моей точки зрения, не будет ошибкой.

Спасибо всем, кто дочитал до конца. Надеюсь, материал оказался вам чем-то полезен. Данный пост носит сугубо обзорный характер. В будущих статьях планирую раскрыть каждый пункт более подробно. Оставайтесь на связи.