DevFM

Недавно делился ощущениями от конференции ArchDays.

Хочу рассказать ещё об одном замечательном докладе "Как мы в Tinkoff принимаем архитектурные решения" от Александра Поломодова.

Особенно мне откликнулись следующие темы:

Какие архитектуры и архитекторы бывают – Enterprice, Solution, Software. По каждому типу даются ответы на вопросы: кто это делает, на каком уровне абстракции, для чего, какие инструменты используются, в какой нотации.

Более детально рассматривается Software Architecture, в том числе о внедрении работы над архитектурой внутрь команд.

Как принимаются архитектурные решения
– RFC (Request for Comments) – документ с описанием проблемы, предложением и обоснованием. Он публично обсуждается, после чего фиксируется решение.
– ADR (Architectural Decision Records) – все решения документируются, включая компромиссы и условия, при которых решение может быть пересмотрено.
– Рабочие группы – временные группы из активных участников разрабатывают предложения и координируют обсуждения.

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

#systemdesign

Как я использую папки в Телеграм для удобства

Меня несколько раз спрашивали, как я живу с сотней активных чатов и десятком групповых. Сегодня необычное — о нашем опыте применения папок в ТГ для асинхронной коммуникации по работе. Как работать с огромным количеством чатов с длительным сроком жизни? Как удобно организовать чтение каналов, если у вас сотня каналов к прочтению?

#devfm #edu #tools

Друзья, сегодня стартует конференция Highload++. Всем, кто присутствует — хорошо провести время.

А для всех желающих из главного зала будет онлайн трансляция. В 11:10 будет, кажется, интересный доклад: «Можем ли мы с базой, но без кэш-слоя в 2024 году?»

Воскресное развлекательное

Что-то меня немного порвало😁

Закон Конвея

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

На волне этого вспомнил статью от Фаулера, в которой он рассказывает о важности закона Конвея в разработке. Согласно этому закону, что любая разрабатываемая система будет отражать организационные связи между командами, которые создают эту систему.

Фаулер предлагает три подхода к учёту закона Конвея:
🔹 Игнорирование — не учитывать закон, что обычно приводит к проблемам в архитектуре.
🔹 Принятие — проектировать систему так, чтобы архитектура соответствовала структуре взаимодействия команд.
🔹 Инверсный манёвр Конвея — перестроить организацию команды для достижения желаемой архитектуры (часто применяется в микросервисах).

В заключении подчеркивается, что важно учитывать закон Конвея не только при создании архитектуры, но и на протяжении всего жизненного цикла проекта, организуя эволюцию архитектуры и организационных структур вместе.
#edu #systemdesign

Автоматизируй автоматизируемое

Это пост для исключительно для маководов.

Уже очень давно пользуюсь такой замечательной программой — Raycast. Это супер-разухабистая штука, которая может упростить повседневную рабочую рутину, да и не только рабочую.

Начну с банального: слёзы текут, когда вижу как кто-то неуклюже ищет нужное ему окно. Ой, это браузер, ой, это почта, блин, это IDE, фух, вот же он — телеграмчик!

Первое, что у меня настроено в Raycast — это хоткеи абсолютно на все программы, которыми я постоянно пользуюсь: Option + M — почта, Option + T — телеграм, option + B — браузер, и т.д.

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

Также стоит обратить внимание на плагины для Raycast — они предоставляют какое-то нереальное количество возможностей. Переводчик, управление зумом, очистка текста в clipboard от спец символов, конвертер времени из юникс формата — всё через плагины.
#devfm #tools

Стрим: разбираем Fastapi + Docker

Сняли почти часовое видео для начинающих, смотрите где удобно youtube / rutube / dzen / VK.

В нём собираем приложение по доке FastAPI (кстати, документацию читать полезно, а их дока крутая). В видео фокусируемся на обвязке — код на гитлабе, проект в докере, в процессе используем Postman и смотрим web console браузера.

Предыдущий стрим про разработку небольшого проекта python-students.

#devfm #youtube #python
#СоерКлуб

Некоторое время назад прочитал у Николая Хитрова пост о том, как он затащил к себе на проект gitlint — инструмент для валидации commit messages.

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

Ребята внедрили себе gitlint и уже несколько месяцев полноценно им пользуются. По отзывам разработчиков: кому-то понравилось, что теперь коммиты нужно писать более дисциплинированно, кто-то и так их качественно писал, поэтому и не заметил разницы. Кто-то, конечно, воняет до сих пор, но на них не отвлекаемся :)

Мне же приятно, что ченджлог и история коммитов теперь выглядит стройненько и единообразно.

За вдохновением по правилам написания коммитов загляните сюда.

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

Вдогонку посмотрите еще на comimitizen.

Не на каждом проекте нужны такие штуки, но может именно на вашем пригодится.
#devfm #tools

Бекап постов за последнее время

Собрали посты, которые получили больше всего лайков, репостов и те, что понравились нам самим.

Материалы, подготовленные нами:
▫️Багскрам – что это и для чего нужен
▫️Как мы начали улучшать процесс в команде после анализа багов
▫️Опыт ведения дел
▫️Фиксация зон ответственности разработки – как и зачем
▫️Для чего нужны архитектурные схемы
▫️И снова о необходимости архитектурных схем
▫️Наш небольшой подкаст на тему: Кто такой тимлид тимлидов
▫️Шуточный пост на тему оценки задач

Обзоры статей:
▪️Отличный гайд от гугла по API
▪️Боль от распухающей базы данных
▪️Всё ли так просто с ретраями?
▪️Оптимизация Postgres за счёт порядка колонок в таблице
▪️Как в гугл пишут дизайн доки
▪️The ultimate docker compose cheat sheet
▪️RESTful web API design

Так же мы советовали несколько отличных книг:
🔹Книга "Думай медленно... Решай быстро" от лауреата Нобелевской премии по экономике – Даниэля Канемана
🔹Книга "Релевантный поиск"
🔹Книга "Getting Real"

#backup

Пятничное развлекательное

Проблема вагонетки – это известная этическая задача, иллюстрирующая сложность морального выбора. Задача звучит так: представьте, что вы управляете рычагом, который может изменить путь вагонетки/трамвая. По текущему пути вагонетка мчится на пятерых людей, и, если ничего не сделать, она их собьёт.

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

Наткнулся недавно на замечательный ресурс – Absurd Trolley Problems, моделирующий проблему вагонетки.
Действительно любопытно потыкать, а также посмотреть, как отвечают на эти непростые вопросы другие люди.

#fun #edu

When to write strategy, and how much?

Отличная статья Will Larson. Она посвящена созданию стратегии в инженерной команде с акцентом на выборе подходящего момента для её написания, определении оптимального объёма и способе внедрения.

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

Следующим рассматривается вопрос оптимального количества стратегий. Автор рекомендует ограничивать количество одновременно разрабатываемых стратегий одной или двумя, чтобы обеспечить их успешное внедрение и избежать перегрузки организации. При этом подчеркивается важность постепенного роста стратегий и гибкого видения конечного результата, которое поддерживает принятие мелких шагов. На примере Uber: в какой-то момент возникла проблема надёжности сервисов и скорости их разработки. Для её решения была создана стратегия, направленная на обеспечение безболезненного деплоя и функционирования сервисов. Реализация этой стратегии постепенно привела к решению более глобальной исходной проблемы.

Далее самое интересное. Для внедрения стратегии нужно учитывать масштаб внедрения (команда или вся организация) и стиль изложения стратерии: запретительный (proscriptive, пример: "блокировать MR, если код не прошёл линтеры") или разрешительный (permissive, пример: "давайте использовать линтеры, вот основные правила, в каждой команде можно кастомизировать под себя"). Чем больше масштаб внедрения, например, на уровне всей компании, тем больше разрешительных пунктов должно быть. Иначе вряд ли стратегию получится внедрить.

Немаловажный момент, на который обращает внимание автор – оценка эффективности стратегии, а также её влияние на принятие различных решений.

Статья любопытная, как и многие другие от этого автора :)

#edu #systemdesign

Вдохновившись выступлениями прошлых лет, побывал тут на ArchDays 2024.

Были доклады поверхностные – за всё хорошее, против всего плохого, были доклады, где люди просто плохо готовились к выступлению или рассказывали сырой материал.

Однако удалось послушать и два хороших выступления:

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

▫️И очень практический доклад Виталия Минко на тему архитектурных принципов. Как только доклад появится на ютубе, обязательно сделаю пост о нём. А пока от него же доклад с одной из прошлых конференций на тему Технического радара. В нём затрагиваются темы: что такое Технический радар, для чего он нужен, когда и как его внедрять в своей компании.

#systemdesign

Багскрам

Недавно поднимали вопрос классификации багов и во что это может вылиться.

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

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

Багскрам – это встреча, цель которой однозначно определить суть бага, актуальность, его приоритет, назначить исполнителя и сроки исправления. На ней же можно классифицировать баги по причине возникновения.

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

Проводить багскрам следует по следующему сценарию:

Подготовка
Заранее выбрать скоуп багов, которые хотите разобрать.

Встреча
1. Тот кто проводит встречу, планомерно открывает каждый из багов.
2. Тестировщик, который завёл баг, тезисно описывает проблему.
3. Команда обсуждает баг, появляется и фиксируется какая-то дополнительная информация. Далее определяется приоритет бага, назначается ответственный. Очень важно, чтобы во время обсуждения руководитель проекта или любой другой фасилитатор следил за тем, чтобы встреча не уходила не в то русло и шла чётко по плану.
4. По результату обработки бага оставляется комментарий о том, что баг рассмотрен на багскраме. Это нужно, чтобы по нескольку раз не смотреть одно и тоже. Если на следующем багскраме окажется снова этот баг, то возникнут закономерные вопросики.

Периодический багскрам в целом не даёт багам накапливаться и превращаться в неуправляемую массу.

А на тех проектах, где такое мероприятие у нас проводится, конечно, зафиксирован процесс: участники, периодичность, правила, примеры фильтрации багов в системе контроля задач. Чтобы любой человек мог ознакомиться с процессом.
#devfm #teamwork

Есть такой замечательный ресурс от гугла – API Improvement Proposals. Ребята активно поддерживают ресурс, где делятся своими практиками по разработке API.

AIP содержит:

▪️ Рекомендации по проектированию API: AIPs охватывают все основные аспекты создания API, от именования ресурсов до управления версиями и методов работы с HTTP-запросами. Это включает в себя рекомендации по структуре URL, стандартам наименования полей и параметров, а также подходы к работе с HTTP-методами (GET, POST, PUT, DELETE).

▪️Шаблоны и примеры: для многих сценариев предлагаются конкретные примеры и шаблоны реализации, которые помогают разработчикам лучше понимать, как применять правила на практике. Например, можно найти примеры по созданию структурированных ответов, оформлению ошибок и управлению версиями API.

▪️ Конкретные правила и стандарты: AIPs охватывают такие темы, как использование протокола gRPC, RESTful API, стандарты кодирования, а также рекомендации по работе с HTTP-заголовками, кодами ошибок, аутентификацией и авторизацией.

▪️Методология и философия проектирования: помимо технических аспектов, AIPs содержат информацию о том, как Google подходит к проектированию API на концептуальном уровне. Это позволяет понять, почему определённые решения предпочтительны с точки зрения пользовательского опыта и долгосрочной поддержки API.

#skills

Анализ источника багов как начало улучшения процессов работы в команде

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

Всё шло как обычно, тестировщики тестировали, баги заводились, баги фиксились.

Но тут мы решили посмотреть на природу багов. Из-за чего они возникают? Где что-то ломается?

В результате этого процесса получилось классифицировать баги:
– кейс не проработан бизнес-анализом
– кейс не проработан системным анализом
– в требованиях нечёткие формулировки: аналитик написал как-то расплывчато, разработчик не пошёл уточнять
– ошибка разработчика
– ёпрст, никто об этом не думал, бизнес сам не представлял, что такое бывает

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

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

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

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

Вот такие жирные проблемы удалось выявить в результате анализа природы багов и решения, к которым удалось прийти.
#devfm #systemdesign

Когда всё горит

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

На тему преодоления кризисных ситуаций с точки зрения руководителя принёс вот такую статью.

Автор предлагает сосредоточиться на следующих аспектах.

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

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

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

И ещё немаловажное замечание. Не забывайте о своем здоровье: вы не сможете помочь другим, если сами выгорите. Заботьтесь о себе, находите время на отдых и восстановление. В конце концов, не корову проигрываете.
#edu #teamwork

Пятничное развлекательное

Если вы не любите настолки, то пропустите этот пост. Но я совершу преступление по отношению к любителям настолок, если я не напишу об этом.

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

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

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

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

Всей крутоты в посте не описать, посмотрите обзоры на ютубе.

Пишу об этой игре, потому что совсем недавно Шёпот появился в магазине издателя, но, подозреваю, вскоре будет раскуплен.
#fun

Ведение дел – мой опыт

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

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

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

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

Полезно всем, у кого есть запрос на понятное и упорядоченное ведение своих дел.

Лайки, конечно же, приветствуются.
#devfm #edu #tools