melikhov.dev

«Я не могу тратить много времени на ревью, потому что у меня есть своя работа, вообще-то».

Очень распространённое, очень популярное и в корне, как мне кажется, неверное мнение. Ревью чужого кода это точно такая же часть работы, как и написание собственного. Золотое правило Гитлаба, которым стоит руководствоваться (сам не проверял, но точно слышал от Ильи Климова, что оно существует) — сначала разблокируй других, потом занимайся своими делами.

Стараюсь раза три в день минимум заглядывать в колокольчик гитхаба и очищать инбокс. А лучше, конечно, почаще. Большой минус, что не выходит работать в режиме «сегодня встреч нет, днём погуляю, а вечером всё сделаю». Свою задачу сделаю, а чужие заблокирую. И QA не помогу. И команде на вопросы не отвечу.

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

Есть у нас один важный эндпоинт, общий для фронт-бэк и для сервер-сервер взаимодействия. Вот только принимает он форму с файлами. Ну вы понимаете, да? Multipart/form-data и, что хуже, никаких контрактов. А уж как приятно тесты на это писать с парсилками текстовых строк в моках.
Разделяйте интерфейсы, господа и дамы, зря вам дядя Боб про ISP рассказывает что ли. Пойду фасады напилю что ли.

Пока цены упали, обновил домашнюю машинку с M1 13” на MBP14 M1 Pro 10c 16gb 1Tb (вот такой вот набор цифр и букв). Бомба, конечно. Размер классный, экран запредельный, портов раздолье. Очень хотел 32gb, но их не днём с огнём не отыщешь, а те, что есть, стоят страшно. Благо и на этом летает всё, что нужно.

А зачем обновлял — ну, прежде всего, 2 type-c мне мало. 3 вот прямо на пределе, но уже можно жить. 14 дюймов, опять же, больше, чем 13”, но ещё не такой гроб, как 16”.

Глеб Михеев в докладе про contract first упомянул, что этот подход позволяет одновременно стартовать работу фронта и бэка, на что получил резонный комментарий из зала, что важней не начать, а закончить вместе. А чтобы закончить вместе, нужно:
а) точнее прогнозировать
б) устранить узкие места

Как уже ранее писал, одним из наиболее узких мест является тестирование, которое, как правило, начинается когда все компоненты системы готовы. И вот тут нам на помощь приходит статегия тестирования Shift-left. Идея простая — мы должны начасть тестировать как можно раньше. В идеально мире даже раньше разработки. Как это так? Ну так же как мы делаем TDD — разработка ещё не началась, а тесты написаны.

Так-то и TDD, и BDD, и линтеры, и статический анализ, и contract-first и автотесты — всё это вписывается в стратегию shift-left. Мы должны отловить максимум возможных проблем до того как код будет финализирован перед релизом.

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

Для раскрашивания кода на слайдах пользуюсь консольной утилитой highlight. Классно, здорово, но иногда её нет под рукой. Ну и не хватает наглядности. А тут Семён Левенсон подсказал SlidesCodeHighlighter . Неплохо, неплохо.

Пользуйтесь и не вставляйте на слайды скриншоты из IDE. И портянки кода не вставляйте, никто в зале их читать не будет. Мой выбор — verdana 36pt отступ 1.5. Не только видно с последнего ряда, но и не даёт засунуть в слайд слишком много кода.

Ну и какой язык у нас более объектно-ориентированный — тот, где объект можно создать литералом, забрать деструктуризаций и накинуть дефолтные параметры (решение в одну строчку) или тот, где для решения этой базовой задачи целый паттерн придумали, который без код комплишена руки устанут набирать? Синк эбаут ит

Ребят, я неожиданно в Омске, в гостях на небольшой местной конференции, которая очень некоммерческая, с близкими мне ценностями и хочет случиться ещё раз. Если вы рядом — то приходите завтра и послезавтра обязательно, поболтаем о жизни.

Важная вещь в планировании работы платформенной команды — её циклы разработки не должны совпадать с циклами бизнесовых команд. Если вы живёте двухнедельными спринтами, то пусть спринт платформенной команды идёт со сдвигом в неделю. Если кварталами, то сдвиньте хотя бы на месяц. Понимаю, сложно, особенно если на это завязаны защиты DoD (Definition of Done) и OKR (Objectives and Key Results) у топов и прочие премии. Но необходимо.

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

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

В канале Максима Соснова увидел ссылку на статью — размышления одного из разработчиков из инфраструктурной команды DigitalOcean о принципах и подходах, применяемых при разработке ui-кита. И в ней автор тоже пинает spread-оператор за неявность. А именно, JSX-конструкцию {…props}
—
Отказ от использования в JSX spread для внешних данных спасает от появления странных багов.

Т.е. я избегают использования любых spread-операторов при обработке внешних данных. Да, я не хочу иметь возможность прокидывать вслепую пропсы из одного компонента в другой (если быть честным, мне кажется что это отличное общее правило при работе с пропсами)
1. Может быть непонятно, откуда неожиданно прилетело значение конкретного атрибута (пропа). И поиск тут не поможет.
2. Это позволяет переслать неожиданные атрибуты и TypeScript тут ничего не поймает

Рекомендация — делать деструктуризацию и честно пересылать атрибуты, выкидывая заодно мусор.

Примеры в статье, ищите по фразе «Avoiding JSX spread»

о я про это рассказывал давно еще)
https://youtu.be/dCXvQkvSyQg?t=1424

Чинил сегодня багу на проде, которая прошла через казалось бы имеющуюся типизацию и юнит-тесты как горячий нож сквозь масло. E2E бы спасли, но их там не было. А разгадка одна — безблагодатность.
А дело было в том, что входящий DTO превращался в исходящий не путём честного маппинга, а путём выкидывания ненужного через деструктуризацию и приведение …rest остатка через as в тип выходного DTO. Ну и появление новых полей во входящей DTO строгий валидатор на бэке уже не переварил.

Не экономьте строчки, пишите мапперы в явном виде. И не кастуйте.

Самые добрые ведущие для самых непростых времён

Трём за будущее

Вспоминаем лучшие времена

Утром выдвигаюсь на Holy.js. Посмотрим, кто тут ещё остался, кажется получается такой небольшой междусобойчик. К осени ещё меньше останется, кажется.

Есть план на лайтнингах утопить Nest.js

И тут же письмо от GitHub — мол бета Copilot заканчивается, несите ваши денежки

Прилетела бета нового UI для WebStorm — ну красиво же!

Мы немножко воскресли, потому-что потому, там в начале выпуска всё сказано.