This media is not supported in your browser
VIEW IN TELEGRAM
😍7👍1
ITKatya: культурные паттерны в IT
Video message
Уже поступили вопросики про следующую встречу!
Следующая встреча будет в начале июля!
Если вам интересен мастер-майнд приходите в этот пост в комментарии 😍
Следующая встреча будет в начале июля!
Если вам интересен мастер-майнд приходите в этот пост в комментарии 😍
😍5
📚 Книги - путь в светлое будущее! 📚
Я даже не знала, что существует такая серия книг! Сегодня, открылся занимательный 🧐 мир серии «Педагогика и психология». Если честно, не знаю, воспринимать это, как мем или как историческое свидетельство!
Говорят, что есть в электронке на просторах интернета (пока не искала).
Но давайте считать этот пост-постом в котором делюсь мемасиком ☺️
PS Экватор недельки полной совещаний на большее не сподвигает!
Я даже не знала, что существует такая серия книг! Сегодня, открылся занимательный 🧐 мир серии «Педагогика и психология». Если честно, не знаю, воспринимать это, как мем или как историческое свидетельство!
Говорят, что есть в электронке на просторах интернета (пока не искала).
Но давайте считать этот пост-постом в котором делюсь мемасиком ☺️
PS Экватор недельки полной совещаний на большее не сподвигает!
🔥6😁4
🌐 Документация к API: Искусство ясности и точности 🌐
Продолжим разговор про API (1ая часть тут). Часто API страдает от недостаточной ясности, даже при хорошем проектировании из-за отсутвия качественной документации. Сегодня хочу поделиться с вами составляющими документации к API, которые я вывела для себя.
🤝 Контракт: Это основа любого протокола. Этот документ разъясняет, кто участники взаимодействия, на основании чего строится это взаимодействие. Здесь очерчиваются зоны ответственности сторон. Особенно важно это, если у вас несколько потребителей, и они не все одноранговые. В контракте также описываются регламенты обновлений, правила совместного тестирования, порядок проведения технических работ.
🔖 Словарь: Вводите чёткое определение терминов, таких как "Merchant" или "Client", чтобы избежать недопонимания. Это упростит интеграцию новых пользователей и поможет избежать многих ошибок.
📈 Бизнес-описание методов: Просто перечисления параметров и примеров недостаточно. Необходимо описать, как именно вы спроектировали протокол, что делает каждый метод, какое поведение системы ожидается, что делать в случае успеха, и какие рекомендации при ошибках. Если есть рекомендованный Customer Journey Map (CJM), его тоже стоит приложить.
🚫 Описание ошибок и рекомендации по их обработке: Предоставляйте не только коды ошибок, но и чёткие инструкции о том, как их обрабатывать. Вы не можете диктовать какие интерфейсы будут у конечного пользователя, но вы можете выдать рекомендации и рекомендуемые тексты к ошибкам. Это особенно актуально, если по части ошибок, сопровождает клиента не потребитель, а ваша компания (частый кейс для платежных систем).
🥸 Справочники: Содержат всю необходимую справочную информацию, включая алгоритмы проверки данных. Именно тут должен быть описан алгоритм проверки валидности ИНН или перевод кодов сторонней системы (например МПС) в ваши коды ошибок. Тут же могут быть отражены, рекомендуемые тексты для писем/PUSH/sms конечным пользователям, если их отправляет потребитель.
🧑💻 Сценарии тестирования: Предоставьте полный набор тестов, который позволит потребителю убедиться в корректности интеграции с вашим API.
📑Лист изменений: Документируйте все изменения в API, указывая версию, список изменений, статус внедрения и планируемые даты релизов.
🛠 Технический лист: Описывает процедуры получения токенов, их отзыва и требования к безопасности и хранению данных.
⁉️FAQ: Ответы на частые вопросы и описание типичных ошибок, с которыми уже сталкивались пользователи, а также контактная информация для обратной связи.
Продуманная документация — ключ к эффективному и приятному взаимодействию с вашим API! А из чего состоит ваша документация к протоколам? Знаю, что есть практика включения sequence diagram — мне пригодились, как часть документации к API, лишь 2ды в жизни.
#architecture
Продолжим разговор про API (1ая часть тут). Часто API страдает от недостаточной ясности, даже при хорошем проектировании из-за отсутвия качественной документации. Сегодня хочу поделиться с вами составляющими документации к API, которые я вывела для себя.
📑Лист изменений: Документируйте все изменения в API, указывая версию, список изменений, статус внедрения и планируемые даты релизов.
⁉️FAQ: Ответы на частые вопросы и описание типичных ошибок, с которыми уже сталкивались пользователи, а также контактная информация для обратной связи.
Продуманная документация — ключ к эффективному и приятному взаимодействию с вашим API! А из чего состоит ваша документация к протоколам? Знаю, что есть практика включения sequence diagram — мне пригодились, как часть документации к API, лишь 2ды в жизни.
#architecture
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
ITKatya: культурные паттерны в IT
🚀 10 Капитанских правил для REST-API в Финтехе 🚀
Привет всем!
На протяжении многих лет работы в IT я сталкиваюсь с "детскими болезнями" API. Не смотря на то, что написана масса статей, сделано множество докладов, и даже изданы книги, но проблема качества…
Привет всем!
На протяжении многих лет работы в IT я сталкиваюсь с "детскими болезнями" API. Не смотря на то, что написана масса статей, сделано множество докладов, и даже изданы книги, но проблема качества…
🔥5👍2
Последние несколько постов мы обсуждали API (пост 1) и документацию (пост 2), а теперь пора ответить на вопрос: где это всё размещать и как с этим работать? Ответ прост и лежит на поверхности — создание портала разработчика.
Думаю, что коллегам из финтеха хорошо знаком пример такого портала — PayPal Developer. Шикарно оформленный и информационно-наполненный ресурс, на который стоит ровняться!
Портал разработчика — это централизованный ресурс, предназначенный для взаимодействия с вашими протоколами. Он может быть как внешним, так и внутренним, часто организованным на уровне поддоменов. Внутренний портал предназначен для ваших команд и аутсорсинговых партнёров, а внешний — для ваших клиентов и мерчантов.
На портале разработчика обычно размещаются:
1️⃣ Протоколы API и их документация
2️⃣ Интерактивная "песочница" для тестирования
3️⃣ Справочные материалы, форумы и сообщества поддержки
4️⃣ Описание end-to-end тестов, включая тестовые наборы данных
5️⃣ SDK, демо-версии сайтов, no-code решения, тестовые админки
6️⃣ Пользовательские инструкции, договоры оферт
Основная цель портала — обеспечить единую точку доступа ко всей необходимой информации для внутреннего и внешнего использования вашей системы. Это особенно важно для компаний, предоставляющих решения на условиях white label. Портал упрощает интеграцию с вашими продуктами и способствует развитию партнёрских отношений.
📌Централизация информации — все данные о продукте собраны в одном месте.
🛠 Упрощение интеграции — сторонним разработчикам легче работать с вашим API благодаря хорошо структурированной документации и инструментам.
🤝 Снижение нагрузки на поддержку — хорошо документированная информация уменьшает количество запросов в службу поддержки.
👋Привлечение новых клиентов — доступный и понятный портал привлекает разработчиков, что способствует росту использования ваших продуктов.
💬 Обратная связь и развитие — портал позволяет собирать обратную связь и улучшать продукты в соответствии с потребностями пользователей.
Вывод прост: если ваш продукт уже не новичок на рынке и имеет обширную историю, наличие портала разработчика — это не роскошь, а средство для обеспечения удобства работы с вашим API и укрепления вашего бренда среди разработчиков. Если ваш продукт представляет собой "коробку" или предлагается на условиях white label, то наличие такого портала не просто желательно, а почти обязательно.
#project_management #architecture
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5💯3❤1
Всем привет!
На этой недееле 6го и 7го июня, приглашаю пообщаться на тему проектирования в контексте DevOps.
DevOpsConf устраивает разговор по теме доклада. Если хотите что-то спросить/обсудить/накинуть - welcome в канал конференции в комментарии к посту!
Там же ссылка на видео и слайды презентации!
На этой недееле 6го и 7го июня, приглашаю пообщаться на тему проектирования в контексте DevOps.
DevOpsConf устраивает разговор по теме доклада. Если хотите что-то спросить/обсудить/накинуть - welcome в канал конференции в комментарии к посту!
Там же ссылка на видео и слайды презентации!
Forwarded from DevOpsConf Channel
Запись доклада «Неизбежность, или Как приучить Devops-инженеров к проектированию» Екатерины Лысенко с DevOpsConf 2024
Доклад про взгляд на DevOps и эксплуатацию с точки зрения архитектуры. Рекомендуем для всех, кто по работе, помимо технологий, занимается построением процессов работы и управлением бэклогом команды.
https://youtu.be/BTdfWGL33sw
Скачать презентацию доклада можно здесь: https://disk.yandex.ru/i/wzBAj7vtAUJdPQ
После просмотра пишите вопросы с тегом #ВопросCпикеру в комментарии к этому посту и в четверг-пятницу (6-7 июня) Екатерина лично на все ответит.
Доклад про взгляд на DevOps и эксплуатацию с точки зрения архитектуры. Рекомендуем для всех, кто по работе, помимо технологий, занимается построением процессов работы и управлением бэклогом команды.
https://youtu.be/BTdfWGL33sw
Скачать презентацию доклада можно здесь: https://disk.yandex.ru/i/wzBAj7vtAUJdPQ
После просмотра пишите вопросы с тегом #ВопросCпикеру в комментарии к этому посту и в четверг-пятницу (6-7 июня) Екатерина лично на все ответит.
❤5
🔧 Управление техническим долгом! 🎨
Привет, сегодня поговорим о техническом долге. Техдолг — совокупность компромиссов в проекте, которые были сделаны для ускорения разработки, но которые в долгосрочной перспективе увеличивают стоимость поддержки и развития продукта.
Работы по снижению технического долга:
1️⃣Рефакторинг и реинжениринг на уровне кода и архитектуры: это пересмотр существующего кода и архитектуры с целью улучшения и оптимизации без изменения внешнего поведения системы (рефакторинг) и с изменением — реинжениринг.
2️⃣Рефакторинг технической документации: обновление документации для соответствия текущему состоянию системы. Например, после изменения API необходимо обновить и документацию к нему.
3️⃣Рефакторинг и реинжениринг тестов: пересмотр и оптимизация тестовых сценариев и сред, например, переход на новые версии тестовых фреймворков или интеграция с CI/CD.
4️⃣Переход на новые технологии: внедрение новых технологических решений, таких как обновление версий языков программирования или переход на микросервисную архитектуру.
5️⃣Внедрение и реинжениринг процессов и инженерных практик: например, внедрение DevOps практик или пересмотр релизного процесса.
Правила проведения работ с техническим долгом:
👶 Маленькими шагами: Рефакторинг проводи в рамках текущих фич, оставляя комментарии в задачах и коде. НО ⚠️ задача = 1 сервис, 1 процесс, 1 бизнес-домен, 1 контекст!
🤝Отдельные задачи на реинжениринг: Для серьёзных изменений стоит заводить отдельную задачу или эпик.
📖Синхронизация с документацией: Всегда обновляйте техническую документацию в соответствии с изменениями.
📈Мониторинг изменений: Если изменения затрагивают бизнес-логику, проверьте соответствующие метрики, расширьте борды, проверьте вывод новых ошибок.
🕵Учёт изменений в админке: Убедитесь, что все необходимые изменения в админке также выполнены (не стоит проводить расширения конфигураций без возможности их управления).
📚Обновление пользовательской документации: Если изменения затрагивают пользовательские интерфейсы, обновите соответствующие руководства.
Дополнительные "капитанские" правила:
🔍Тестирование перед деплоем: Всегда проводите тщательное тестирование изменений перед их внедрением в продакшн. Даже если вы не трогали функционал. Все самые "дурацкие" инциденты порождаются именно тем, что "ничего не делали".
💬Обратная связь от пользователей: Не забывайте заглядывать в обратную связь от конечных пользователей, она поможет вам выявить и технический беклог (например: снижение производительности, неочевидность ошибок).
💻Регулярные ревью: Регулярные код-ревью снизят накопление технического долга. Если можно исправить сейчас - исправь, не копи!
🗓Планирование: Включайте управление техническим долгом в план разработки, чтобы систематически улучшать проект.
Управление техдолгом — неотъемлемая часть разработки, но основной проблемой работы с ним является частая сложность его внедрения, как регулярного стрима в планы команд, если изначально практики рефакторинга и реинжениринга не были базовами для разработки. Ошибаться — нормально, развиваться и узнаваться, как сделать лучше — нормально, внедрять новое и улучшать — нормально, НЕ НОРМАЛЬНО стагнировать и бетонировать устаревающий код!
#project_management
Привет, сегодня поговорим о техническом долге. Техдолг — совокупность компромиссов в проекте, которые были сделаны для ускорения разработки, но которые в долгосрочной перспективе увеличивают стоимость поддержки и развития продукта.
Работы по снижению технического долга:
1️⃣Рефакторинг и реинжениринг на уровне кода и архитектуры: это пересмотр существующего кода и архитектуры с целью улучшения и оптимизации без изменения внешнего поведения системы (рефакторинг) и с изменением — реинжениринг.
2️⃣Рефакторинг технической документации: обновление документации для соответствия текущему состоянию системы. Например, после изменения API необходимо обновить и документацию к нему.
3️⃣Рефакторинг и реинжениринг тестов: пересмотр и оптимизация тестовых сценариев и сред, например, переход на новые версии тестовых фреймворков или интеграция с CI/CD.
4️⃣Переход на новые технологии: внедрение новых технологических решений, таких как обновление версий языков программирования или переход на микросервисную архитектуру.
5️⃣Внедрение и реинжениринг процессов и инженерных практик: например, внедрение DevOps практик или пересмотр релизного процесса.
Правила проведения работ с техническим долгом:
🤝Отдельные задачи на реинжениринг: Для серьёзных изменений стоит заводить отдельную задачу или эпик.
📖Синхронизация с документацией: Всегда обновляйте техническую документацию в соответствии с изменениями.
📈Мониторинг изменений: Если изменения затрагивают бизнес-логику, проверьте соответствующие метрики, расширьте борды, проверьте вывод новых ошибок.
🕵Учёт изменений в админке: Убедитесь, что все необходимые изменения в админке также выполнены (не стоит проводить расширения конфигураций без возможности их управления).
📚Обновление пользовательской документации: Если изменения затрагивают пользовательские интерфейсы, обновите соответствующие руководства.
Дополнительные "капитанские" правила:
🔍Тестирование перед деплоем: Всегда проводите тщательное тестирование изменений перед их внедрением в продакшн. Даже если вы не трогали функционал. Все самые "дурацкие" инциденты порождаются именно тем, что "ничего не делали".
💬Обратная связь от пользователей: Не забывайте заглядывать в обратную связь от конечных пользователей, она поможет вам выявить и технический беклог (например: снижение производительности, неочевидность ошибок).
💻Регулярные ревью: Регулярные код-ревью снизят накопление технического долга. Если можно исправить сейчас - исправь, не копи!
🗓Планирование: Включайте управление техническим долгом в план разработки, чтобы систематически улучшать проект.
Управление техдолгом — неотъемлемая часть разработки, но основной проблемой работы с ним является частая сложность его внедрения, как регулярного стрима в планы команд, если изначально практики рефакторинга и реинжениринга не были базовами для разработки. Ошибаться — нормально, развиваться и узнаваться, как сделать лучше — нормально, внедрять новое и улучшать — нормально, НЕ НОРМАЛЬНО стагнировать и бетонировать устаревающий код!
#project_management
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8❤2👍1
☠️ Смерть, финтех и IT! 💀
Признаюсь в своем guilty pleasure -фентези и лучше с юмором ! Обожаю отвлечься вечером о фантастический мир! И сегодняшний пост навеян двумя книгами. Первая: "Смерть, отбор и котики" - помогла с названием.
А вторая сформировала повестку поста, который не только про пятничное настроение, но и с дозой психологии и юмора в контексте IT и финтеха. Это книга 1969г. "О смерти и умирании" психолога Элизабет Кюблер-Росс, в которой она ввела в обиход модель (принятия смерти) DABDA (Denial, Anger, Bargaining, Depression, Acceptance), которая трансформировалась с годами в стадии принятия неизбежного.
И хотя первоначально модель была применена к восприятию смерти, не удивительно, что ее принципы актуальны и для процесса осознания и принятия технического незнания в IT.
👩💻 Как проходит процесс борьбы с неизбежным в IT, особенно в финтехе?
🙅♂️Отрицание: Сначала мы не можем поверить, что столкнулись с проблемой. "Это не может быть настолько сложным!"
😈Гнев: Когда осознание приходит, мы начинаем раздражаться. Виноваты все - архитектура, техдолг, "некомпетентность" коллег, а иногда даже весь регуляторный орган.
🤑Торг: После эмоционального всплеска мы переходим к стадии торга: "А может, можно обойтись без полного пересмотра кодовой базы?". Подсознательно мы надеемся, что небольшой "костыль" все исправит и не придется впадать в реижениринг.
😓Депрессия: Когда становится ясно, что простых путей нет, охватывает уныние. "Как мы могли не предвидеть это раньше?"
👍Принятие: В конце концов, мы смиряемся и готовы к действиям. "Да, нам предстоит серьезно пересмотреть архитектуру и решить скопившиеся проблемы." Вся команда готова начать "жить дальше", разрабатывая новые схемы и закладывая изменения в процессы, чтобы обойти текущие ограничения.
🌟 Незнание — это неизбежная часть нашей работы, и каждый проход через эти стадии делает нас сильнее. Принимая незнание и двигаясь к знаниям, мы создаем гибкую и устойчивую архитектуру.
🤔 А вы находите отражение модели Кюблер-Росс в вашей работе?
#fintech #books #mylife
Признаюсь в своем guilty pleasure -
А вторая сформировала повестку поста, который не только про пятничное настроение, но и с дозой психологии и юмора в контексте IT и финтеха. Это книга 1969г. "О смерти и умирании" психолога Элизабет Кюблер-Росс, в которой она ввела в обиход модель (принятия смерти) DABDA (Denial, Anger, Bargaining, Depression, Acceptance), которая трансформировалась с годами в стадии принятия неизбежного.
И хотя первоначально модель была применена к восприятию смерти, не удивительно, что ее принципы актуальны и для процесса осознания и принятия технического незнания в IT.
👩💻 Как проходит процесс борьбы с неизбежным в IT, особенно в финтехе?
🙅♂️Отрицание: Сначала мы не можем поверить, что столкнулись с проблемой. "Это не может быть настолько сложным!"
😈Гнев: Когда осознание приходит, мы начинаем раздражаться. Виноваты все - архитектура, техдолг, "некомпетентность" коллег, а иногда даже весь регуляторный орган.
🤑Торг: После эмоционального всплеска мы переходим к стадии торга: "А может, можно обойтись без полного пересмотра кодовой базы?". Подсознательно мы надеемся, что небольшой "костыль" все исправит и не придется впадать в реижениринг.
😓Депрессия: Когда становится ясно, что простых путей нет, охватывает уныние. "Как мы могли не предвидеть это раньше?"
👍Принятие: В конце концов, мы смиряемся и готовы к действиям. "Да, нам предстоит серьезно пересмотреть архитектуру и решить скопившиеся проблемы." Вся команда готова начать "жить дальше", разрабатывая новые схемы и закладывая изменения в процессы, чтобы обойти текущие ограничения.
🌟 Незнание — это неизбежная часть нашей работы, и каждый проход через эти стадии делает нас сильнее. Принимая незнание и двигаясь к знаниям, мы создаем гибкую и устойчивую архитектуру.
🤔 А вы находите отражение модели Кюблер-Росс в вашей работе?
#fintech #books #mylife
🔥11❤2
🌟 Просьба! 🌟
Я сейчас в поисках подходящего канала (индексируемого) для публикации статей и лонгридов. Хотелось бы узнать, какие информационные источники, где публикуется контент на русском языке по теме IT и около неё, вы читаете?🙏 СПАСИБО!🥰
Я сейчас в поисках подходящего канала (индексируемого) для публикации статей и лонгридов. Хотелось бы узнать, какие информационные источники, где публикуется контент на русском языке по теме IT и около неё, вы читаете?🙏 СПАСИБО!
Anonymous Poll
34%
67%
habr
2%
vk
29%
linkedIn
5%
Дзен
6%
Tproger
10%
Другое (укажу в комментах)
😘СПАСИБО огромное!😘
Невероятный отклик на опрос! Вы - классные и очень помогательные!
СПАСИБО!!
PS: если еще не ответили, но хотите - буду признательна! Опрос - в после выше!
NB! Сегодня полезного контента не будет, но, если у вас работает Instagram - ловите шикарную новую шутку от ребят из ППШ!
Невероятный отклик на опрос! Вы - классные и очень помогательные!
СПАСИБО!!
PS: если еще не ответили, но хотите - буду признательна! Опрос - в после выше!
NB! Сегодня полезного контента не будет, но, если у вас работает Instagram - ловите шикарную новую шутку от ребят из ППШ!
❤4
🌟 ADL и ADR 🌟
Привет! Сегодня хочу поговорить о том, как управлять архитектурной документацией в динамичной IT-среде, особенно учитывая множество решений, которые нам приходится принимать и документировать.
Этот пост будет особенно полезен тем, кто работает в области IT-архитектуры, разработки программного обеспечения и проектного управления в технологических и финтех-компаниях. Если вы архитектор, разработчик, технический руководитель или менеджер проекта, вы найдете ценные советы о том, как эффективно управлять архитектурными решениями и поддерживать документацию в актуальном состоянии.
📘 Что такое ADL и ADR?
ADL (Architecture Decision Log) — это библиотека архитектурных решений, где каждое решение, или ADR (Architecture Decision Record), детально описывает причины выбора тех или иных технологий или подходов.
При организации процесса по работе и созданию ADR и ведению ADL важно понимать, кто будет использовать эту документацию, кто напишет архитектурные решения, как они будут рассматриваться и приниматься.
🔍 Как я организую ADL:
1️⃣ Уровень продуктового стрима или технологического кластера: Например, 'Клиентский опыт' или 'Платежи', в рамках которых формируются разные команды и подразделения.
2️⃣ Уровень продукта или домена: Здесь уже речь идет о конкретных продуктах, таких как 'банковские карты' или 'автокредит'.
3️⃣ Уровень команд или мини-продуктов: На этом уровне мы спускаемся к таким элементам, как 'дебетовые карты' или 'сквозной платеж'.
📚 Подходы к ведению ADL:
ADL – это, скорее, картотека ADR. Вы сами решаете, какие "тома" будут занимать место на полках. Не все документы стоит превращать в ADR: есть множество других видов артефактов.
1️⃣ Не создавать ADR на каждый мелкий "чих": Не создаем ADR для абсолютно нового продукта или проекта! Во время работы над крупным и новым проектом для компании обычно создается так много документации, что она не поместится в один ADL. Такую документацию лучше вести отдельно внутри команды, отвечающей за проект или продукт.
2️⃣ Разделение ADR и аналитических справок: Исследования новых инструментов или методик не всегда требуют создания ADR, пока не станет ясно, что они влияют на архитектуру.
3️⃣ Сохранение "археологических заметок": Иногда нам всем приходится заниматься "археологией" – исследованиями "о прошлом" на уровне кода или бизнеса. Результаты таких исследований – заметки и выводы, которые не всегда становятся задачами в бэклоге технического долга, но это не делает их менее ценными. Но даже если вы хотите обсудить результаты таких "раскопок" на архитектурном совещании и предложить что-то новое, можно начать с обсуждения заметок, и, если станет очевидно, что они должны быть преобразованы в решение, можно оформить ADR.
📌 Ответственность за управление ADR и ADL:
1️⃣ ADR и ADL должны регулярно пересматриваться, чтобы оставаться актуальными и отражать изменения в проектах.
2️⃣ Ответственные лица должны контролировать качество и актуальность ADR. Обычно это технические писатели за форму и архитекторы за содержание.
3️⃣ Автоматизация контроля и мониторинга ADR через платформы вроде Confluence для обеспечения постоянного обновления и обратной связи.
💡 Эффективное управление ADR и ADL не только помогает сохранять архитектурную целостность проектов, но и облегчает интеграцию новых членов команды и адаптацию к изменяющимся бизнес-требованиям.
Давайте обсудим, какие у вас есть методы и практики в этой области!
#architecture
Привет! Сегодня хочу поговорить о том, как управлять архитектурной документацией в динамичной IT-среде, особенно учитывая множество решений, которые нам приходится принимать и документировать.
Этот пост будет особенно полезен тем, кто работает в области IT-архитектуры, разработки программного обеспечения и проектного управления в технологических и финтех-компаниях. Если вы архитектор, разработчик, технический руководитель или менеджер проекта, вы найдете ценные советы о том, как эффективно управлять архитектурными решениями и поддерживать документацию в актуальном состоянии.
📘 Что такое ADL и ADR?
ADL (Architecture Decision Log) — это библиотека архитектурных решений, где каждое решение, или ADR (Architecture Decision Record), детально описывает причины выбора тех или иных технологий или подходов.
При организации процесса по работе и созданию ADR и ведению ADL важно понимать, кто будет использовать эту документацию, кто напишет архитектурные решения, как они будут рассматриваться и приниматься.
🔍 Как я организую ADL:
1️⃣ Уровень продуктового стрима или технологического кластера: Например, 'Клиентский опыт' или 'Платежи', в рамках которых формируются разные команды и подразделения.
2️⃣ Уровень продукта или домена: Здесь уже речь идет о конкретных продуктах, таких как 'банковские карты' или 'автокредит'.
3️⃣ Уровень команд или мини-продуктов: На этом уровне мы спускаемся к таким элементам, как 'дебетовые карты' или 'сквозной платеж'.
📚 Подходы к ведению ADL:
ADL – это, скорее, картотека ADR. Вы сами решаете, какие "тома" будут занимать место на полках. Не все документы стоит превращать в ADR: есть множество других видов артефактов.
1️⃣ Не создавать ADR на каждый мелкий "чих": Не создаем ADR для абсолютно нового продукта или проекта! Во время работы над крупным и новым проектом для компании обычно создается так много документации, что она не поместится в один ADL. Такую документацию лучше вести отдельно внутри команды, отвечающей за проект или продукт.
2️⃣ Разделение ADR и аналитических справок: Исследования новых инструментов или методик не всегда требуют создания ADR, пока не станет ясно, что они влияют на архитектуру.
3️⃣ Сохранение "археологических заметок": Иногда нам всем приходится заниматься "археологией" – исследованиями "о прошлом" на уровне кода или бизнеса. Результаты таких исследований – заметки и выводы, которые не всегда становятся задачами в бэклоге технического долга, но это не делает их менее ценными. Но даже если вы хотите обсудить результаты таких "раскопок" на архитектурном совещании и предложить что-то новое, можно начать с обсуждения заметок, и, если станет очевидно, что они должны быть преобразованы в решение, можно оформить ADR.
📌 Ответственность за управление ADR и ADL:
1️⃣ ADR и ADL должны регулярно пересматриваться, чтобы оставаться актуальными и отражать изменения в проектах.
2️⃣ Ответственные лица должны контролировать качество и актуальность ADR. Обычно это технические писатели за форму и архитекторы за содержание.
3️⃣ Автоматизация контроля и мониторинга ADR через платформы вроде Confluence для обеспечения постоянного обновления и обратной связи.
💡 Эффективное управление ADR и ADL не только помогает сохранять архитектурную целостность проектов, но и облегчает интеграцию новых членов команды и адаптацию к изменяющимся бизнес-требованиям.
Давайте обсудим, какие у вас есть методы и практики в этой области!
#architecture
🔥9❤7👍4
🌟 DevOps-проектировщик🌟
Сегодня будет пост с легкими нотами философии. Хочу поделиться с вами моими размышлениями на тему, которую обсудили после моего доклада на DevOpsConf'24 под названием "Неизбежность, или Как приучить Devops-инженеров к проектированию". Если вы пропустили, вот ссылка на видео доклада, где я разбирала взаимодействие архитекторов и DevOps-специалистов в процессе проектирования.
Мы привыкли видеть DevOps как практику, направленную на улучшение сотрудничества между разработчиками и операционными отделами, чтобы ускорить и оптимизировать процессы разработки, тестирования и внедрения программного обеспечения. Но DevOps также имеет и более широкое значение. Это не просто интеграция разработки и операций — это философия, которая в корне меняет подход к созданию и поддержке программного обеспечения, подчеркивая необходимость непрерывного сотрудничества всех участников проекта.
Вопросы, которые возникли в дискуссии: Может ли архитектор в одиночку принимать решения по дизайну системы? Должен ли он привлекать к этому процессу DevOps-инженеров, разработчиков, а также специалистов по базам данных?
💬 На мой взгляд, DevOps-специалисты — это не просто технические исполнители, они — активные участники процесса проектирования. Они помогают архитекторам видеть большую картину, учитывать возможные операционные проблемы и оптимизировать продукт для удовлетворения потребностей пользователя.
🏝Пример из жизни: Всё как на Кипре, где я живу. Здесь важно не просто знать соседей, но и участвовать в жизни друг друга. Проходя мимо, вы не просто машете рукой, но и обсуждаете новости, погоду или семейные события. В DevOps та же идея — быть частью "семьи", активно участвовать в жизни проекта.
Что это значит для DevOps-специалистов? Они не только помогают автоматизировать процессы, но и активно участвуют в создании архитектуры, помогая разработчикам и архитекторам видеть риски и возможности на ранних этапах проектов.
Итак, DevOps-инженеры — это не просто роль, это философия сотрудничества и инноваций. Возможно, этот путь выглядит "утопичным" для некоторых компаний. Знаю, что, несмотря на возраст, во мне еще много юношеского максимализма и веры в светлое, доброе, вечное. Но мне хочется и интересно строить именно такие подходы, именно такую архитектуру, которую понимают и бизнес, и разработка; в проектирование которой не нужно отдельно приглашать DevOps-специалистов, так как они уже внутри процесса, они — "клей" и связь между всеми, они могут обогатить меня, коллег и, главное, решение, знаниями, которых у меня нет.
DevOps-специалисты помогают всем членам команды работать эффективно, предотвращая ошибки и оптимизируя процессы. В конечном счете, это не только ускоряет процессы разработки и внедрения, но и создает продукты высшего качества, которые лучше отвечают потребностям пользователей.
Я уверена, что проектированием должна заниматься КОМПАНИЯ, а не один конкретный человек, например, архитектор. Уверена, что глагол "проектировать" сродни глаголу "думать". Самые страшные решения принимаются, когда мы себе разрешаем "махнуть рукой" или "забить". Уверена, что доклад и мысли в нем применимы не только к DevOps-инженерам, но и к разработчикам, лидам, менеджерам, аналитикам, продактам - всем, кто хочет, кто готов, кто может. При отсутствии желания, думать не заставить...
Ваши мысли? Считаете ли вы, что интеграция DevOps в процесс проектирования архитектуры необходима для современных IT-проектов?
#architecture
Сегодня будет пост с легкими нотами философии. Хочу поделиться с вами моими размышлениями на тему, которую обсудили после моего доклада на DevOpsConf'24 под названием "Неизбежность, или Как приучить Devops-инженеров к проектированию". Если вы пропустили, вот ссылка на видео доклада, где я разбирала взаимодействие архитекторов и DevOps-специалистов в процессе проектирования.
Мы привыкли видеть DevOps как практику, направленную на улучшение сотрудничества между разработчиками и операционными отделами, чтобы ускорить и оптимизировать процессы разработки, тестирования и внедрения программного обеспечения. Но DevOps также имеет и более широкое значение. Это не просто интеграция разработки и операций — это философия, которая в корне меняет подход к созданию и поддержке программного обеспечения, подчеркивая необходимость непрерывного сотрудничества всех участников проекта.
Вопросы, которые возникли в дискуссии: Может ли архитектор в одиночку принимать решения по дизайну системы? Должен ли он привлекать к этому процессу DevOps-инженеров, разработчиков, а также специалистов по базам данных?
💬 На мой взгляд, DevOps-специалисты — это не просто технические исполнители, они — активные участники процесса проектирования. Они помогают архитекторам видеть большую картину, учитывать возможные операционные проблемы и оптимизировать продукт для удовлетворения потребностей пользователя.
🏝Пример из жизни: Всё как на Кипре, где я живу. Здесь важно не просто знать соседей, но и участвовать в жизни друг друга. Проходя мимо, вы не просто машете рукой, но и обсуждаете новости, погоду или семейные события. В DevOps та же идея — быть частью "семьи", активно участвовать в жизни проекта.
Что это значит для DevOps-специалистов? Они не только помогают автоматизировать процессы, но и активно участвуют в создании архитектуры, помогая разработчикам и архитекторам видеть риски и возможности на ранних этапах проектов.
Итак, DevOps-инженеры — это не просто роль, это философия сотрудничества и инноваций. Возможно, этот путь выглядит "утопичным" для некоторых компаний. Знаю, что, несмотря на возраст, во мне еще много юношеского максимализма и веры в светлое, доброе, вечное. Но мне хочется и интересно строить именно такие подходы, именно такую архитектуру, которую понимают и бизнес, и разработка; в проектирование которой не нужно отдельно приглашать DevOps-специалистов, так как они уже внутри процесса, они — "клей" и связь между всеми, они могут обогатить меня, коллег и, главное, решение, знаниями, которых у меня нет.
DevOps-специалисты помогают всем членам команды работать эффективно, предотвращая ошибки и оптимизируя процессы. В конечном счете, это не только ускоряет процессы разработки и внедрения, но и создает продукты высшего качества, которые лучше отвечают потребностям пользователей.
Я уверена, что проектированием должна заниматься КОМПАНИЯ, а не один конкретный человек, например, архитектор. Уверена, что глагол "проектировать" сродни глаголу "думать". Самые страшные решения принимаются, когда мы себе разрешаем "махнуть рукой" или "забить". Уверена, что доклад и мысли в нем применимы не только к DevOps-инженерам, но и к разработчикам, лидам, менеджерам, аналитикам, продактам - всем, кто хочет, кто готов, кто может. При отсутствии желания, думать не заставить...
Ваши мысли? Считаете ли вы, что интеграция DevOps в процесс проектирования архитектуры необходима для современных IT-проектов?
#architecture
YouTube
Неизбежность, или Как приучить Devops-инженеров к проектированию / Екатерина Лысенко (RoboGate)
Конференция для инженеров и всех, кто должен понимать инженеров DevOpsConf 2024
Презентация и тезисы:
https://devopsconf.io/moscow/2024/abstracts/11557
DevOps-инженеры легко становятся заложниками одной из двух моделей восприятия:
1) Задача DevOps — …
Презентация и тезисы:
https://devopsconf.io/moscow/2024/abstracts/11557
DevOps-инженеры легко становятся заложниками одной из двух моделей восприятия:
1) Задача DevOps — …
👍4
Сегодня хочу поговорить об использовании ИИ, но, внезапно, не в основной работе, а в сопутствующей деятельности по освещению экспертизы и собственного бренда. И тут ИИ для меня, как для технаря, а не маркетолога или филолога, стал настоящим подспорьем!
🔍 Сети, которые использую:
1. ChatGPT- платный. Стоимость: $20 в месяц.
1️⃣ Проверка ошибок: Нет больше страха перед опечатками и грамматическими ошибками.
2️⃣ Оформление постов: AI помогает мне подобрать эмоджи 😶 и отформатировать текст.
3️⃣ Генерация картинок: Идеи для визуального контента и промты для MidJorney (часто быстро пробую в ChatGPT, потом в нем же пишу promt и уже «докручиваю» изображение в MidJorney).
4️⃣ Придумывание шуток: Когда понимаешь, что в докладе «перегундел», а шутка никак не рождается!
5️⃣ Поиск статей на английском: Легко нахожу примеры с подтверждением из официальных источников для статей и докладов.
Признаюсь, писать посты иногда сложно, так как тексты получаются либо очень большими, либо слишком краткими. ChatGPT помогает мне найти баланс!
2. MidJourney - платный. Стоимость: от $10 до $60 в месяц, в зависимости от тарифа.
1️⃣ Создание картинок для докладов: Относительно быстро и без нарушения авторских прав (для меня это важно!) создаю визуальные материалы, которые делают мои доклады яркими и запоминающимися.
2️⃣ Генерация стикер-паков в одном стиле: Мое открытие года! Позволяет снизить и временные, и финансовые затраты при работе с дизайнерами при подготовке материалов к конференции. Создаешь картинку, а на ее основе стикер-пак с иконками заданной тематики!
3. Perplexity.ai - бесплатный
1️⃣ Поиск статей и подходящих материалов: Легко нахожу нужные источники для исследований и подготовки контента. ИМХО, это основное преднозначение этой ИИ!
2️⃣ Упоминания и проверка гипотез об статьи других авторов: Получаю актуальную информацию и подтверждение своих идей.
3️⃣ Работа с русскоязычными источниками: В то время как ChatGPT отлично справляется с англоязычным контентом, Perplexity.ai становится незаменимым помощником для работы в русскоязычном поле.
Эти AI значительно экономят мои время и силы. Я могу сосредоточиться на главном, не тратя много времени на рутинные задачи! Да, можно использовать ИИ "в лоб" и делегировать им написание всех текстов, но это личный выбор каждого и "контракт с совестью"!
P.S. Если у вас есть вопросы по использованию AI, пишите в комментариях, буду рада помочь!
#toolkit
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥12❤6👍2💯2