Development

Mind-map - мощный инструмент для организации знаний с доказанной эффективностью. Статья посвящена хорошим практикам по работе с mind-map в целом, а также тому, как применять mind-map в тестировании

Статья про технику коммандного обучения "Xtrem reading" Коротко: - Собираем людей на час вместе - Каждый из людей приносит какую-то непрочтенную им книгу и высказывает свое предположение о чем эта книга - Люди обьединяются в группы по 2-3 человека и их задача за 25-30 минут "прочесть книгу". Не нужно на самом деле читать книгу, нужно пробежаться по ней и понять о чем она - Затем участники делятся друг с другом фидбеком по книгам и оценивают их С одной стороны - читать книги параллельно с кем нибудь очень полезно (хоть 1 книгу, хоть 2 разных). В этом случае получается рефлексия материала через обсуждение. Поэтому я уверен что можно сделать Team Learning на основе чтения книг С другой стороны - практика из статьи очень странная. Не представляю как можно изучить что-то полезное, потратив на книгу 25-30 минут. Иногда столько может уйти на одну страницу!

Отличная статья про парное программирование. Ссылки на исследования, паттерны, анти-паттерны. Рекомендую к прочтению всем интересующимся.

Документация - важная часть разработки. Но зачастую документацию плохая, устаревшая или вообще отсутствует. Так происходит потому что подходы к написанию документации безнадежно устарели. В разработке Continuous Integration, Continuous Test, Continuous Monitor и Continuous Deploy являются бест-практисами. Continuous Documentation - то, чего нам не хватает! Принципы Continuous Documentation: - Документация всегда актуальна - Документация пишется тогда, когда для этого лучший момент - Документация связана с кодом Идеи интересные, но в статье не описано, как это сделать в реальности

Текстовая расшифровка доклада про Observability в Netflix. Очень короткий tldr: - Observability состоит из логов, метрик и трейсинга - По метрикам можно понять "с высоты птичьего полета" что с сервисом что-то не то - По логам можно понять что конкретно идет не так - По трейсингу можно отследить путь запроса - В Netflix куча микросервисов и 1 запрос может пройти через сотню микросервисов – У каждого сервиса свои логи и свои метрики, но трейсинг должен быть единый - Написали свою систему для анализа трейсинга - Анализировали бизнес-эффект от всей текущей системы мониторинга Видео доклада тут, если не хочется читать текст https://www.infoq.com/presentations/netflix-edgar-observability/

Обзорный доклад от Витайлия Дмитриева про DevOps. Что такое DevOps, какие практики он в себе содержит и личный опыт внедрения практик в разные компании. Рекомендую.

У storybook появилась поддержка для Vite. В storybook 6.2 появилась поддержка альтернативных бандлеров. Vite - более быстрая альтернатива webpack, которая первая заехала на новое API.

Бест практисы для тестирования во фронтенде: - Следовать DRY и KISS - AAA паттерн - arrange, act, assrt - Правило трех (Что проверяем, в каких условиях и что ожидаем) - Изолированный стейт для каждого теста - Отдельные селекторы для тестирования (data-test-id) - Ожидать чего-то конкретного (например элемента), а не просто wait(500)

Большинство статей/видео показывают TDD на примерах, где каждому классу соответствует свой тестовый класс или тестовый сьют. Мапинг тестов к коду 1 к 1 делает тесты слишком связными с кодом. При рефакторинге кода в такой ситуации ращработчик вынужден править также и тесты. Это классическая ситуация с двумя стульями: либо разработчик рефакторит и делает код лучше, но идет еще и править тесты. Тогда тесты не выполняют своей роли - доказывать безопасность рефакторинга. Либо разработчик оставляет все как есть и система остается хуже, чем могла бы быть. Идея мапинга тестов к коду 1 к 1 может быть хороша вначале, но вредна если ей следовать на дистанции. Фокус в том, что тесты и код развиваются в разных направлениях. Тесты становятся все более и более специфичными, покрывая все более узкие сценарии. Код же становится все более и более абстрактным, чтобы быть гибким. TDD сам по себе не делает архитектуру хуже или лучше. TDD может сделать архитектуру лучше, если следовать бест практисам. А может сделать хуже, если не думать своей головой. TDD это дисциплина, которая позволяет иметь хорошее покрытие тестами и работать со специфичностью тестов и абстрактностью кода. Но эффект на архитектуру зависит только от разработчика, применяющего TDD

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

Новая статья от Димтрия Карловского и в этот раз почти без $mol. Статья про то, что HTML может быть и хорош, но то, как под него пытаются мимикрировать различные шаблонизаторы\фреймворки, выглядит как натягивание совы на глобу. Также в посте есть интересные комментарии

В статье описан интересный эксперимент над обезьянами. Есть клетка с обьезьянами и устройство с бананом, но достать его просто так нельзя. Сначала ученые обучили омега-обезьяну доставать банан. Но другие, более сильные, обезьяны отбирали у нее банан и сама омега-обезьяна оставалась голодной. Затем омега-обезьяну увели и научили доставать банан более сильную обезьяну. У нее отбирал бананы альфа-самец. Но после этого обезьяны, которые ниже статусом, научились доставать банан (повторили то что делала обученная обезьяна). Затем и этих обезьян увели. Научили доставать банан альфа-самца. Альфа достал банан для себя, затем этот опыт повторили среднестатусные обезьянны и низкостатусные. Исследование показывает, что обезьяны лучше учатся у более "авторитетных" соплеменников. Кажется примерно то же самое можно наблюдать и в человеческой среде. И в IT. Чтобы шарить бест-практисы и учить чему-нибудь, необходимо иметь авторитет в группе. И обратное тоже верно: если авторитета нет, то привнести бест-практис - очень тяжело.

Что должен делать менеджер, чтобы члены команды росли? Есть 2 необходимых вещи: 1. Нужно поощрать людей за то, что они берут сложные, непонятные, рисковые для них задачи. Это те задачи, которые несут новые челленджи и из-за которых происходит рост. 2. Предоставлять все, что нужно, чтобы задача была выполнена успешно. Инструменты, знания, поддержка, ментор.

Рассуждения agile коуча о современном не-аджайловом аджйле и о том что ситуацию можно улучшить с OKR. В статье есть неплохие мысли про OKR и то как его лучше применять. Также подсвечены неправильные методы использования OKR. Идея статьи одним предложением: "хорошим" командам OKR поможет улучшить их agile. От себя: тут есть противоречие. У "хороших" команд уже хороший agile и им не нужен OKR. А "плохие" команды применят OKR неправильно и сделают хуже

Статья от технического коуча (technical coach) про то как учить команды полезным практикам. Для примера взят TDD В статье есть свою нюансы из-за того что она написана коучем: - Очень много воды, нереально много. Целыми абзацами - Свои "уникальные" методы. Метода в статье названа "Samman" method. Хотя недалеко ушло от правильно проводимых уроков в школе. Короткая суть статьи: - Я технический коуч и мне нужно проводить много тренингов - Тренинги разбиваются на 2 части - Learning hour - Введение, рассказ про технику - Практика с преподготовленным примером. Тут идет работа группами или вообще все месте (30-45 минут) - Подведение итогов - Для закрепления навыков дальше следует делать Mob Programming (у которого в статье также придумано другое имя - работа в ансамбле). Во время Mob программирования коуч должен навигировать минимальное время. - Через несколько сессий практика расшарена! Не смотря на кучу воды и небольшой налет инфоциганчины, подход кажется рабочим

Небольшой пост от Raycast про их процесс без Code Review. Очень поверхностная статья. Основные поинты: - нужно двигаться быстро (мы ж стартап) - Code Review замедляет - PR - это про недоверие - Code Review не находит багов - Разработчики сами несут ответственность за свои фичи - Наши разработчики комитят сразу в мастер, в полночь мастер раскатывается на дев стенды - Если мы довольны тем что раскатилось, то изменения попадут в next public release (релизы раз в неделю) - Люди могут просить поревьюить их код. Даже после вливания в мастер. - Новых тиммейтов ревьюят пару недель, потом появляется доверие и надобность отпадает

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

В Typescript влили МР с реализацией уточнения типа переменной на основе ее использования в других переменных и алиасах. Т.е. теперь можно делать ``` const isString = typeof variable === 'string'; if (isString) { variable.length; } ``` Раньше TS, зная что isString === true, не мог уточнить тип переменной variable

ES2021 as approved by the Ecma General Assembly

Мысли разработчика о комментах к коду. В целом, ничего нового и кажется тема с комментариями к коду уже давно решена. Автор раньше считал что комментарии не нужны и нужно писать самодокументируемый код. Но в реальности самодокументируемый код хорошо описыват "what is it?" но плохо "why is it?". На второй вопрос легче ответить с помощью отдельного комментария к коду, который поможет разработчику понять почему сделано именно так, а не как-то иначе

Рассказ про разные варианты Peer Review, от Design Review до Code Review Очень хороший доклад про то, как люди могут эффективно проверять решения друг друга. Рассмотреные варианты ревью: - Код ревью - Дизайн ревью и практика описания тех дизайна - QA Ревью - Эксперт реввью - Парное программирование - Ревью по запросу - Чайка-ревью Много способов и нет универсального рецепта как их использовать и в каком количестве. В зависимости от команды подойдут разные практики. Но в идеале команда должна находить проблемы как можно раньше, неблокирующим способом и члены команды должны доверять друг другу

Убер опубликовал статьи про то, как они готовят API Gateway. тлдр: - API Gateway настраивается через админку - Состоит из 4х слоев. На основе конфига в админке может подключать мидлварки, заниматься сериализацией\десериализацией, подготовкой запроса на бек, мапинг ответа бека - Достаточно мощный и гибкий велосипед fun fact: походу весь гейтвей компилируется в 1 бинарник golang, потому что > The lack of generics resulted in a significant amount of generated code during build time to a point where we were hitting the limits of the Go linker

Интервью с авторами книги "Software Engineering at Google" Интересна часть интервью, связанная с Code Review. Основные поинты: - Code Review плохо ищет дефекты. - В гугле нужно 2 апрува: от любого инженера и от мейнтейнера. Часто это 1 человек. - Ревьюят как правило маленькие изменения. - Основная цель Code Review - обмен знаниями. Перформанс, например, тоже важен, но он достигается другими средствами

Автор описывает бест-практисы для написания компонентов исходя из своего опыта. Свой подход он назвал "Single Element Pattern" - singel Если совсем коротко, то здесь 5 правил: - Rule #1: Render only one element - Rule #2: Never break the app - Rule #3: Render all HTML attributes passed as props - Rule #4: Always merge the styles passed as props - Rule #5: Add all the event handlers passed as props В статье есть разумные мысли, но многие выводы слишком субьективны.

Статья про перевод JS движка на WASM. Зачем это нужно, какие проблемы существуют и какие решения применяэтся для решения этих проблем

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

Мартин Фаулер высказался на счет популярных в современное время отказов от классической пирамиды тестирования в сторону Триумфа Тестирования от Kent C. Dodds или в сторону Медовой Соты (ох эти попытки перевода английских терминов). В их основе лежит борьба с большим количеством юнит-тестов, которые не дают достаточного количества уверенности в работе кода. Но, сам термин unit очень размытый, даже по меркам IT. Мартин рассказывает про времена, когда термин только появился и что в него вкладывали разные люди. Кент Бек, например, вкладывал в unit - любые тесты, которые пишет разработчик. Также хорошая точка зрения что при разработке в Waterfall модели, все тесты написанные до интеграции - unit тесты. Вместо того, чтобы обсуждать пирамиду тестирования, разработчикам при общении следует сфокусироваться на том, что каждый из них вкладывает в слово unit. Добавлю от себя, что я бы предложил вообще не использовать это слово в обсуждениях.

Форматтер для JS и TS кода написанный на Rust. По бенчмаркам автора, быстрее чем prettier.

Доклад от Романа Ивлиева про рост проекта. Немного сумбурный, без презентации, но тем не менее достаточно интересный доклад про то, как меняется организация с ростом, какие проблемы появляются и почему всегда все плохо. Ниже официальный анонс доклада --- "Когда у вас что-то начинает расти — команда, количество задач, ответственность и пр, — всегда возникают вопросы: "на что я забыл посмотреть, подумал ли я о чем-то, что уже нацелилось прострелить мне руки и ноги?". С одной стороны, я не расскажу ничего нового. С другой, если бы всё это хотя бы иногда всплывало в головах, жизнь была бы прекрасна и удивительна. Мой рассказ будет про 13 направлений мысли и работы (на самом деле их 14, но для кликбейта нужны жертвы), любое из которых, будучи упущенным из виду, гарантированно создаст проблемы вашему растущему окружению. Даже если вы "не руководитель, пусть про это думают другие", всё равно будет полезно, т.к. у вас появится возможность помочь команде! Или вовремя соскочить ;)"

В больших компаниях есть 2 мира: в одном живут продуктовые команды, которым надо как можно быстрее выкатываться в прод, а в другом живут платформенные команды, которые делают "на века". Эти 2 мира могут друг друга не понимать по разным причинам, что приводит к конфликтам. В статье описано, почему так происходит и что делать. Почему так происходит: - Разный взгляд на вещи. Продуктовые команды считают важным продуктовый код. Платформенные команды не считают продуктовый код важным. - Разные стандарты качества. Платформенная команда делает решения на годы, поэтому делает медленно и очень качественно. Продуктовые команды должны делать быстро и часто удаляют или переписывают код. - Банальная "дистанция" между командами. В больших компаниях они могут быть так далеко друг от друга, что нет общих точек соприкосновения - команды воспринимают друг друга как "чужие" Я бы к этому еще добавил, что часто в платформенные команды нанимают самых сеньористых сеньоров, которые затем делают абстракции ради абстракций и получают синдром бога. Что автор предлагает делать: улучшить коммуникацию. Я не буду расписывать как это конкретно сделать т.к. там очень субьективные вещи. Например, использовать больше эмоджи 👍 💪