Тип-пересечение (Intersection Types)

Тип-пересечение, как следует из названия, соответствует пересечению множеств, которые его образуют. Декларируется при помощи оператора &.

type C = A & B

Это видно на картинке: у нас есть два множества, которые пересекаются, и их пересечение образует подмножество. Если два множества не пересекаются, мы все равно можем получить тип-пересечение, но оно будет пустым (never).

type X = string & number // never

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

type Product = { id: number; name: string; }
type Priced = { price: number; }

type PricedProduct = Product & Priced

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

type Product = { id: number; name: string; price: number; }

#typescript

Как я на go в продакшн писала

История была год назад. Нашей команде достался проект с жестким дедлайном. Я уже заканчивала фронтенд, а бекендеры все сдвигали свои сроки и, в конце концов, признались, что не успевают — слишком много задач помимо этого проекта. Тогда я сказала, что я все сделаю сама, только дайте доступ. Лид удивился и возразил мне тем, что в моем резюме написано “frontend-разработчик”. Как вы, наверное, помните, мне в целом не очень импонируют все эти надуманные ограничения вроде “фронтендер не может закрывать таски на бекенде”, тем более я не на лиспе писать собралась, а на еще одном c-like языке. Доступ мне дали. Бекенд оказался на go.

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

После этого меня ждал новый сюрприз: абсолютно пустой readme и огромный makefile с богатым разнообразием команд. Я решила не гадать на кофейной гуще и спросить у лида, как стартануть проект. А никак, — ответил лид, — он локально не запускается, в CI можно стенд собрать. На этом моменте я на все плюнула и пошла в спортзал тягать железки.

День два. Я решила, что даже если я не могу проверить свой код, написать-то я его все равно могу, логично? Начала читать таску и обнаружила, что аналитик любезно все описал, включая таблицы БД, которые нужно добавить/изменить, и какие поля добавить в эндпойнты. Осталось всего лишь перевести это все в код, что, как вы понимаете, изян задача.

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

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

Ну а потом я перешла в другую команду и моя славная карьера go-разработчика закончилась. В новой команде я уже больше полугода пишу на Svelte. Позже расскажу, с какими сложностями я столкнулась после того, как перешла с React на Svelte (спойлер: ни с какими, две недели немножко неудобно, а потом привыкаешь).

Помните, я писала о том, как делать сопроводительные на hh? В общем, можно больше не тратить на это время, смысл сопроводительных окончательно утрачен.

Кхэ-Кхэ ру выкатил обновление для соискателей и представил новую функцию "AI-генерация сопроводительного письма"🤦🏻‍♂️

Вот теперь точно AI будет отбирать AI... а работать-то кто потом будет?🫣

Дублирование на уровне кода - один из основных источников технического долга. Говоришь себе "ну сейчас быстро сделаю копи-паст, а потом на этапе рефакторинга раскидаю как надо".

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

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

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

Может быть, это и к лучшему, потому что мы с вами еще можем научиться красиво и грамотно писать код, проектировать и продумывать наши системы, а ИИ будет продолжать плодить легаси.

Воистину, лень оказалась лучшей инвестицией, которая поможет нам конкурировать с ИИ.

Вот такую вакансию увидела на канале Леси и хочу немного прокомментировать.

За DE не скажу, буду говорить о моей профессиональной сфере — веб-разработке.

“Нужен человек полностью соответствующий нашим ожиданиям, а НЕ который учится на ходу.” — довольно популярная мечта у работодателей. Многих раздражает, что новый сотрудник какое-то время онбордится в проект и разбирается во всех его нюансах, и только потом начинает предлагать какие-то здравые идеи. Отчасти пожелания к годам опыта связаны с этим фактором: работодателям кажется, что если придет опытный специалист, он телепатически разберется в нюансах проекта и вытащит его из кризиса прямзавтра (или ещевчера). По этой же причине не очень любят нанимать джунов: “нужен сотрудник, который сразу приносит пользу, а не которого надо обучать” (с).

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

Самое сложное в коммерческой разработке — это разобраться в нюансах конкретного проекта. Написать код может кто угодно при условии, что известно, как он должен работать. Проблема в том, что в коммерческой разработке никогда не известно, как именно код должен работать и какие ограничения необходимы. Это зависит от конкретного проекта, то есть от особенностей бизнеса, которые определяются текущим законодательством, экономической ситуацией, решением руководства и отношениями между отделами. Разобраться в этом и есть самое сложное, с чем сталкивается рядовой разработчик, приходя на новое место. Именно поэтому, кстати, для разработчиков имеют такое большое значение документация к проекту и читаемость кода.

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

Во фронтенде человек, прошедший обучение по современных технологиям (HTML, JavaScript, TypeScript, какой-нибудь фреймворк) с хорошим знанием CS (профильной вышкой) и математическим мышлением (умением выделять абстракции и оперировать ими) становится полноценным бойцом (то есть миддлом) спустя 3-6 месяцев работы. Что касается ребят, которым программирование дается сложнее (ну, скажем условно, “гуманитариев”) и у которых нет профильной вышки, то такой человек станет полноценным миддлом спустя год, максимум полтора года работы. Я видела десятки таких примеров. И не только я: до повсеместной моды на накрутку опыта большинство компаний искали фронтендеров миддлов с опытом от 1 года, потому что большинству моих коллег известно, что после года опыта 99% фронтендеров становятся полноценными бойцами, даже если у них нет вышки и “математического склада ума”.

Таким образом, для того, чтобы быстро свитчиться между технологиями и проектами, вам не нужно много опыта. Надеюсь, я смогла проиллюстрировать выше, что в коммерческом программировании нет ничего сложного и набивать “опыт” в этом — это то же самое, что набивать опыт в ходьбе по улице. Мы же не говорим, что 30-летние люди лучше ходят по улице, чем 20-летние? Это абсурд. И те и другие вроде не падают :)

Для того, чтобы быстро свитчиться между технологиями и проектами, вам нужна база CS (алгоритмы и структуры данных, паттерны проектирования, операционные системы, сети) и архитектурные навыки. Это научит вас быстро и точно соображать, а это в нашем деле — самое главное.