В новом эпизоде отрытого курса «Паттерны и практики написания кода» вместе с бэкенд-инженером Авито Юрой Афанасьевым продолжаем тему Структурных Паттернов. Разберём два новых подхода — Декоратор и Фасад, поговорим про UML-диаграммы паттернов и их реализацию в коде, а также рассмотрим основные преимущества подходов.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
🔥 Agile умирает - и его убийца уже здесь. Имя ему - искусственный интеллект! Заметили ли вы что многие Agile визионеры активно перетекают в сторону AI-консалтинга?
Agile обещал гибкость и гуманистический фокус. Однако новые роли, жесткий спуск сверху, трансформации и бесконечный встречи превратили его в бюрократию новой волны Теперь же “искусственный интеллект” врывается в менеджмент и ставит жирную точку: куда интереснее цифровые следы людей и возможности автоматизации и прогнозирования, а не работа в ценностной модели и адаптивности. Аджайл перестал справляться с изменениями и запросами на больший контроль поставляемого результата
У меня есть коллега, который активно включает LLM как в пайплайны разработки, так и в общие операционные процессы - и вот уже два месяца его студия живет без единого дейлика, встречи крайне редко, но повысилась асинхронная работа, коллаборация через код и документы, а также возможности глубокого погружения задачи без постоянного переключения контекста. Иногда ему кажется, что он здесь лишний
Может, Agile - это как Nokia в мире проектного менеджмента? Собственно у Nokia был замечательный Agile
Теперь думаю: это трагедия или естественный отбор? Agile ещё жив или уже пора хоронить?
Data-класс вашей ошибки: как относиться к ошибкам как программист
Ошибки можно рассматривать как задачи, которые возникли в ходе решения другой таски. Только, как правило, с экстремально короткими сроками выполнения и большим потоком информации. И входишь ты в этот поток не с самым высоким уровнем мотивации и возможным давлением.
Чтобы убрать эмоции из анализа ошибки и подойти к ней с «трезвой» головой, можно разложить ее как код. Вот, например, какой data-класс можно выделить у ошибки:
class Error {
// что нужно было сделать
var task
// что пошло не так
var errorDetails
//какие возможные последствия уже есть или последуют и кто может пострадать
var effect
//причины ошибки
var reasons
//плюшки от решения сложившейся ситуации
var benefits
//выводы
var experience
//список улучшений, которые можно сделать, чтобы минимизировать повторение ошибки
var actionItems
}
А теперь — реализация.
Пример: Вы неверно оценили сроки выполнения целого скоупа задач, входящих в MVP для приложения Сообщения — ошиблись на целых два релиза. Никто не пострадал, но ситуация по многим аспектам неприятная.
Как бы выглядела реализация интерфейса для данного случая:
class BadEstimationForMVPMessaging {
var task = эстимация MVP для приложения Сообщения. Необходимо оценить все задачи, распределить по спринтам и релизам, учесть загрузку команды и выдать предполагаемую дату релиза
var errorDetails = ошибка в эстимации на два релиза (два месяца разработки команды из трех человек)
var effects = listOf(
- релиз переносился два раза
- демотивация команды
- вопросы с продуктовой стороны
)
var reasons = listOf(
- часть задач были сильно недооценены
- не учтены зависимости, которые, конечно, вылезли только в конце
- не заложен запас по времени
)
var benefits = listOf(
- хороший пример, который можно разобрать
- прокачан навык работы с ожиданиями
- ощутили дух стартапа с командой, решая внезапные блокеры перед релизом, и радовались запуску приложения
)
var experience = listOf(
- детальнее искать зависимости на этапе подготовки к эстимации
- закладывать запас по времени в 2-3 релиза
- на задачи с неизвестными апишками и стеком увеличивать коэффициент Пи*
)
var actionItems = listOf(
- составить чек-лист для подготовки к запуску новых приложений, на который можно ориентироваться всем командам
- обсудить с командой процесс выявления зависимостей
)
}
Смотреть на ошибки так гораздо эффективнее. Вы выносите из них уроки, а не просто посыпаете голову пеплом. Попробуйте!
А больше лайфхаков по построению здоровой культуры ошибок в жизни и на работе читайте в подробной статье от Марии Киселевой, тимлида команды разработки мобильных приложений для KvadraOS в YADRO →
Задачи Структурных Паттернов: Адаптер и Компоновщик — в чём суть?
В пятой серии открытого курса «Паттерны и практики написания кода» мы начинаем новую объёмную тему — изучение Структурных Паттернов. Она состоит из семи подходов. В эпизоде вместе с бэкенд-инженером Юрой Афанасьевым погрузимся в особенности работы Адаптера и Компоновщика.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
Порождающие паттерны Prototype и Singleton: а минусы будут?
В новой серии открытого курса «Паттерны и практики написания кода» мы завершим изучение порождающих паттернов знакомством с двумя шаблонами — паттерном Прототип и паттерном Синглтон. Вместе с бэкенд-инженером Юрой Афанасьевым разберемся, почему паттерн Prototype — простой в реализации — используется редко, а паттерн Singleton — самый критикуемый.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
В новом выпуске подкаста «Свободный слот» обсуждаем сложные решения тимлида — те, что бьют не по метрикам, а по нервам. Чтобы разобрать эту непростую тему, ведущие Саша Прокшина и Паша Федотов встретились с Олегом Федоткиным, CTO в «Циан». Как принимать решения, когда нет правильного ответа? Уволить или дать шанс? Сохранить команду или пойти на реорганизацию? Согласиться на даунгрейд ради себя или тянуть дальше? Выделите свободный слот в своем расписании, чтобы вместе с ребятами найти ответы на все вопросы.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
Опять попробовали React Native и снова решили, что не хотим его внедрять у себя 🧐
Олег и Денис, наши фронтенд-разработчики, рассказали, почему отказались от этого фреймворка, несмотря на то что потратили на погружение в него немало времени. Это был хороший эксперимент, который дал нам много полезных инсайтов. ✍️
Перед нашей командой стояла задача: написать код один раз, собрать под три платформы и встроить в существующие нативные и веб-приложения. Решили поэкспериментировать с React Native: до этого мы «щупали» фреймворк в 2018-м, но делали новое приложение, опыта разработки SDK у нас не было. Отправились гуглить и узнавать, как это сделать. Начали с разработки под Android, потом подключили в веб, и уже финально — iOS, в котором практически всё заработало по дефолту.
В React Native просто начать делать компоненты, но, погрузившись в нативную часть, мы почувствовали себя джунами — запилить поле ввода с нативной валидацией было непросто.
Вот что мы поняли при разработке:
● Обязательно нужна единая дизайн-система под все три платформы под React Native и библиотека компонентов. А ещё — команда из фронтенд и мобильных разработчиков под iOS и Android: одни будут поддерживать часть React Native, которая относится к нативной платформе, другие — писать бизнес-логику и UI.
● React Native может подойти для проектов, которые начинаешь с нуля и нужно охватить мобильные платформы и веб сразу.
Результаты нашего эксперимента
Хоть и ушло на работу с React Native несколько кварталов, мы решили не внедрять его. Было ли нам обидно? Нет, потому что благодаря эксперименту мы:
✔ Закрепили опыт, что фронтенд-разработчики могут писать на React Native.
✔ Поняли, как всё работает изнутри, какие у фреймворка плюсы и минусы.
Будет ли применимо для нас в будущем — время покажет. Возможно, для новых продуктов это рабочая схема, сейчас — экономически неоправданно.
В малом и микро бизнесе встречаются два вида контроля. Они в каком-то смысле противоположны друг другу по цели и методам осуществления.
В первом случае предприниматель чувствует облегчение, что кто-то занимается отделом продаж и старается не вдаваться в подробности. Во втором контроль — это способ справиться с тревожностью. Спросил, и вроде отлегло.
Есть еще третий способ, когда предприниматель формализует и контролирует все, что хоть как-то похоже на процесс. Он верит, что бизнес должен быть оцифрован; что получаешь ровно то, что контролируешь; и прочие законы успешного бизнеса, с которыми трудно не согласиться.
Однако, нужно еще ответить на вопрос: каким должен быть следующий шаг. Контроль в общем смысле — это не только получение информации о деятельности подразделений, но и управленческое воздействие на основе этой информации.
Управленческое воздействие сильно зависит от того как интерпретировать данные. А те, в свою очередь, зависят от того куда мы смотрели.
Модерация объявлений, коммуникация внутри сервиса, меры безопасности — рассказываем о SafeCom в новом выпуске «AviTalk». На этот раз экспертизой делится Антон Тупиков, технический лидер дирекции SafeСom Авито. Вместе с ведущей Стасей Кошман говорим о найме в SafeCom, интересных кейсах из работы сервиса и способах стать детективом внутри Авито. Антон также поделится историей собственной карьеры: от первых проектов до перехода в Авито.
Чтобы ничего не пропустить, включайте видео и делитесь мнением в комментариях.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
В репозитории Tencent Cloud SDK for Go на GitHub содержится более 200 000 тегов Git. Это так много, что попытка взаимодействия с тегами в этом репозитории может фактически привести к сбоям в работе GitHub (504 Gateway Time-out. The server didn't respond in time).
BI-проекты: 5 причин, почему они выходят за рамки бюджета (и как этого избежать)
Если вы хоть раз участвовали во внедрении BI-системы — знаете, как легко проект может уйти не туда: – бюджет трещит по швам, – сроки съедены интеграцией и доработками, – пользователи по-прежнему делают аналитику в Excel.
Мы в GlowByte собрали в статье практический разбор типичных ошибок, которые чаще всего приводят к перерасходу бюджета и снижению отдачи от BI-проектов.
Плюс: даём самодиагностический чек-лист и PDF-гайд, где перечислены все организационные, финансовые и технические риски BI-проектов.
Открытый проект редактора Neovim имеет уже более 100 ИИ-плагинов сейчас. Их список привёл разработчик решение Colin Kennedy. Некоторые из плагинов в списке находятся в разработке или могут быть не полностью ориентированы на редактор Neovim.
В прошлом году усиленно начал пользоваться AI (LLM) тулами и словил жуткую волну грусти-печали после 5-6 месяцев использования. Для меня самым сложным стало не то, что код в целом может писать LLM, а осознание того, то в общем-то это и не так важно. Гораздо важнее появился абстрактный вопрос зачем его вообще писать если завтра всё может поменяться настолько быстро что глазом не моргнешь.
Погрустив и поболев буквально и походив по книжным магазинам наткнулся на интересную книгу - The Art of Excellent Products: Enchanting Customers with Premium Brand Experiences by Riccardo Illy. И эта книга попала настолько, что понял как разрешить (на текущий момент), моральную дилемму с AI кодом, когда ты сам не пишешь код, а его пишет AI - через этические принципы.
На мой взгляд этические принципы дают три возможности:
Ограничения или фокус - зафиксировав принципы, можно фокусироваться только на том, что действительно важно и отбрасывать / deprioritize то, что не согласуется с этими принципами.
Гибкость при принятии решений - зная ограничения и имея этический фокус, можно при необходимости быстрее принимать ответственные решения, но при этом не жертвовать тем, что этически важно для компании / продукта.
Доверие - имея ограничения в виде выбранных этических принципов, ценности продукта / компании могут стать более устойчивыми к кризисам - что в итоге может дать больше доверия продукту для конечного пользователя. В теории:)
Поэтому с начала года я начал думать над принципами / ценностями / values и пытаться понять, какие подходят - и почему.
вышел из digital чтобы написать ручками в блокнотике:)
Для себя выделил три группы (пока что): - Приложения, игры и персональные принципы.
Например для приложений пока пришел к такому списку:
Удобство
Простота
Безопасность
Долговечность
Полезность
Для игр (так как это хобби, немного другие принципы):
Полезность
Творчество
Развлечение
Вызов
На текущий момент (май), 5 месяц тестирования - и могу честно сказать что стало гораздо проще фокусироваться на проблеме и решении чем раньше. Уверен что с развитием AI многое ещё изменится - но как будто это может стать мостиком для работы с ним с морально - этической стороны (особенно когда нужно торговаться / выбирать между быстрее - качественнее).
Ещё завел телеграм канал - https://t.me/devethics, в который стал собирать ценности / принципы которые внезапно стал открывать у других людей и компаний (продуктовых, электронных) и т.д.. Пока назвал этика разработчика:)
Надеюсь что пост чем нибудь вдохновит и окажется полезным :-)
Пожалуйста делитесь своими мыслями в комментариях:-) это поможет сделать эту статью видимой для других и будет здоровской поддержкой и мотивацией:-)
Объявлено решении включить в состав выпуска GNOME 49 видеопроигрыватель Showtime, который станет поставляться под именем GNOME Video Player и будет задействован по умолчанию вместо видеопроигрывателя Totem (GNOME Videos).
Для желающих протестировать Showtime не дожидаясь осеннего релиза GNOME 49 подготовлен пакет в формате flatpak. Программа отличается минималистичным интерфейсом, отображаемым поверх содержимого и скрываемым во время просмотра. Поддерживаются типовые элементы управления, полноэкранный режим, изменение скорости воспроизведения, показ субтитров и создание скриншотов.
ГОСТ Р 56939-2024 – Разработка безопасного программного обеспечения (РБПО)
20 декабря 2024 года введён ГОСТ Р 56939-2024 взамен ГОСТ Р 56939—2016. Хотя уже прошло около полугода, не все про это знают, осознают это или как-то подстраиваются под произошедшие изменения :) А изменения есть, так как новый ГОСТ ориентирован на построение и контроль процессов, обеспечивающих цикл безопасной разработки в компании.
Update 2026. Публикации в канале, вебинары и другие ресурсы легли в основу создания информационной подборки о разработке безопасного программного обеспечения по ГОСТ Р 56939‑2024 – ГОСТ56939.РФ
Несколько информационных моментов.
1. Цикл публикаций в моём канале "Бестиарий программирования" на тему РБПО
Я начинаю большой цикл публикаций в Telegram, посвящённый РБПО и ГОСТ Р 56939-2024. Приглашаю подписываться всех, кто хочет постепенно знакомиться с этой темой и разбираться в ней.
2. Вебинары РБПО-направленности
Мы уже провели совместно с другими компаниями два вебинара, связанных с ГОСТ Р 56939-2024:
Приглашаем и другие компании к технологическому и/или информационному сотрудничеству. Напишите нам в поддержку или моему ассистенту.
3. Сертификация ФСТЭК
В последнее время нас спрашивают, подходит ли PVS-Studio для сертификации, и есть ли у нас сертификат ФСТЭК?
Для PVS-Studio нет сертификата ФСТЭК, так как он не нужен (для статических анализаторов процедура сертификации является добровольной).
PVS-Studio может использоваться как инструментальное средство статического анализа кода при построении процессов РБПО по ГОСТ Р 56939-2024.
PVS-Studio успешно применяется испытательными лабораториями, аккредитованными в системах сертификации средств защиты информации ФСТЭК России в рамках работ по сертификационным испытаниям программных продуктов, так как соответствует необходимым критериям (для заказчиков и сертификационных лабораторий мы подготовили информационное письмо):
PVS-Studio включён в Реестр российского ПО (запись № 9837 от 18.03.2021);
PVS-Studio удовлетворяет функциональным требованиям к инструментам статического анализа кода, описанным в Методическом документе "Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении" (издание второе, доработанное, утверждён ФСТЭК России 25 декабря 2020 г.);
продукт разрабатывается с учётом требований, предъявляемых к статическим анализаторам в ГОСТ Р 71207–2024.
Подробнее: Сертификация ФСТЭК. Если у вас есть вопросы, напишите нам в поддержку или позвоните по телефону +7(903)844-02-22.
Работа каждого руководителя начинается с PDCA (Plan–Do–Check–Act)
Работала в одном из моих самых первых стартапов командиром админов девочка-админ из Питера. Говорят, в Питере даже у хулиганов два высших образования — вот и она была чёткая, как питерский пацан и резкая, как клинок в питерской подворотне! Её отец (тоже питерский админ) учил так, — пока чёткий план не составишь, руки на клавиатуру не кладёшь!
Хорошее правило, да и вообще стандартный управленческий цикл состоит из 4х элементов: планирование, работа, контроль и развитие. Никакую компоненту выкинуть не получится. Если оставить только планирование и развитие без контроля за результатом, — получается ерунда. Именно так всё тогда и случилось.
В целом по способности выстроить всю цепочку от планирования до развития можно оценить любого руководителя. Каждый этап имеет свой вес в зависимости от специфики работы. Руководитель, исходя из своих личных особенностей и контекста бизнеса, может активнее участвовать в одних звеньях цепочки и делегировать другие. Полностью вложиться конечно можно, но гораздо спокойнее, если часть элементов делегировать, оставив себе наиболее критичные.
Беда была в том, что планировать она умела, а вот выполнять получалось не очень. Точнее как... Так получилось, что исполнителем был как раз её отец, но он не исполнял. А она не могла его проконтролировать должным образом. В результате из всего управленческого цикла было только планирование.
Зато бабло на развитие команда админов просила регулярно, — чтобы влить, например, в оборудование. Я однажды отказал в финансировании на обновление серверов — решение оказалось ошибочным: сервис перешёл в режим ReadOnly на несколько суток, пока срочно не докупили новых серверов. Без прозрачности и системного контроля принятие каких бы то ни было решений превращается в рулетку (русскую) — и почти всегда стреляют в бизнес. Этот случай я до сих пор использую как пример рисков при отсутствии контроля в управленческом цикле.
Руководителю лучше заранее решить, за что браться самому, а что делегировать для обеспечения полноты управленческой цепочки. Ну или надеется на "авось", а потом расхлебывать. В нашем случае девочка планировала, её отец брался за работу и развитие. Но цепочка была неполной как раз из-за отсутствия контроля — никто по-настоящему не отвечал за результат. Вот и получили то, что получили.
Какой вывод можно сделать? Любая перекошенная конфигурация PDCA почти всегда чинится — главное, вовремя откалибровать баланс между вовлечённостью руководителя и делегированием. А вот если без балансировки просто потерять какой-то элемент из цепочки, то последствия неизбежны.
Есть 1000 и 1 способ организовать продуктовую команду, и каждый со своими преимуществами и недостатками. Как тут выбрать и не ошибиться? (*ﾉωﾉ)
Наш CPO Саша Бондаренко собрал и описал более 12 моделей команд. У каждой указал, какому типу компаний она подойдет, а также дал инструкцию по подбору «той самой». Получился большой материал, который мы разбили на несколько частей.
Спрос на IT-специалистов в 2025 году близок историческому минимуму и продолжает падать — по многим направлениям количество IT‑вакансий стало меньше, чем в самые тяжёлые времена ковида.
С конца 2022 года многие IT-компании во всём миру уволили примерно 635 тысяч сотрудников.
Эксперты винят в этой ситуации спад выручки, закрытие проектов, а также автоматизацию и внедрение нейросетей, которые снимают ощутимую часть работы. Специалисты говорят, что такие события будут прогрессировать по мере совершенствования ИИ. Под угрозой оказались даже сеньоры с 15-летним опытом и специалисты Microsoft, Google, Tesla, eBay и PayPal.
Что такое чистая архитектура: основные особенности
Чистая архитектура — это подход к проектированию систем, который предполагает независимость от фреймворка и вообще от внешних компонентов. Выделяем слой use-кейсов, слой сущностей, UI и презентер — и теперь эти слои и есть наши фреймворки. Поэтому реальный фреймворк в чистой архитектуре можно использовать как инструмент, а не перестраивать весь проект под его ограничения.
Как, по сути, работает чистая архитектура
Какие еще свойства чистой архитектуры важны:
Тестируемость. Это значит, что бизнес-правила могут быть протестированы без UI, без баз данных, без веб-сервера и без любого другого внешнего компонента. Например, у нас может быть фронтенд на React и мобилка на Flutter — и мы при этом всё равно можем менять контракты, не меняя бизнес-правила.
Чистая архитектура независима от информационных хранилищ. Можно поменять PostgreSQL на MongoDB или на любую другую СУБД. При этом работа бизнес-правил не изменится.
Чистая архитектура — это независимость от внешнего сервиса. По факту слой use-кейсов изолирован от внешнего мира, ничего о нем не знает. А знает только о том, как работать в рамках бизнес-системы.
Большой материал о том, на каком проекте была внедрен этот подход и почему выбрали именно его, читайте в блоге.
❓Разработчик и стартап: работать | основать | избегать?
В новом выпуске Sravni Tech Podcast обсуждаем, куда податься разработчику: пойти работать в стартап, рискнуть и запустить свой или держаться подальше от “стартапной суеты”? Наш гость — Илья Хрусталёв, основатель Foodfox (тот самый, что стал «Яндекс.Едой»).
В выпуске: 📌Работа в ИТ-стартапе: ожидание vs реальность 📌Жизненный цикл стартапа (и когда это уже не стартап?) 📌Запускаем свой бизнес в ИТ. Что важно учесть? 📌Различия стартапов в России и США. Где проще получить инвестиции?
