Бережливая_архитектура_Лысенко_Podlodka.pdf
12.6 MB
🌊 Привет, морские волки! 🌊
После недели, проведенной в недрах подготовки, я, словно субмарина, всплыла на поверхность, чтобы поделиться с вами своим докладом на конференции Podlodka Techlead Crew!
🎥 Свежее видео моего доклада уже доступно, а слайды готовы разжечь огонь дискуссий. 📑
🔥 Ожидаю бурю мнений в комментариях! Давайте вместе разберемся в каждой детали и поспорим на здоровье. 💬
PS: Не забыла про обещанный пост о насмотренности — он уже на подходе! Ожидайте свежие мысли в ближайшие дни. 🎞️📖
#architecture
После недели, проведенной в недрах подготовки, я, словно субмарина, всплыла на поверхность, чтобы поделиться с вами своим докладом на конференции Podlodka Techlead Crew!
🎥 Свежее видео моего доклада уже доступно, а слайды готовы разжечь огонь дискуссий. 📑
🔥 Ожидаю бурю мнений в комментариях! Давайте вместе разберемся в каждой детали и поспорим на здоровье. 💬
PS: Не забыла про обещанный пост о насмотренности — он уже на подходе! Ожидайте свежие мысли в ближайшие дни. 🎞️📖
#architecture
🔥12👍1
🌟 Развиваем насмотренность! 🌟
Привет! Наконец-то давно обещанный пост о "насмотренности" — умении видеть глубже очевидного. Это та самая способность, которая помогает нам не просто смотреть, но видеть и анализировать, связывая казалось бы несвязанное!
🚀 Вдохновение из всех источников
Развитие насмотренности особенно важно в профессиональной деятельности, например, при проектировании архитектуры в IT. Умение видеть скрытые связи между элементами помогает находить инновационные решения и улучшать продукт.
✍️ Советы для повседневной практики:
👁🗨Расширяйте кругозор: Чем больше вы знакомитесь с разными жанрами искусства, культуры или пробуете что-то новое, тем больше нейронных связей устанавливает ваш мозг. Изучайте, как сделано у других, исследуйте открытые источники, интересуйтесь новыми технологиями и методологиями — это поможет вам находить неочевидные решения для сложных технических задач.
Пример: вам необходимо сделать гибкую систему комиссий за проведение платежа. Можно пойти по пути типизации платежей, а можно, по аналогии с системой MCC-кодов, вынести основное назначение платежей на уровень мерчантов и, в зависимости от мерчанта и вида его деятельности, настроить динамический % за услуги.
⚖️Анализ и рефлексия: После просмотра фильма, прочтения книги или посещения выставки попробуйте задуматься, какие идеи или темы вы могли бы адаптировать в своей работе. После каждого проекта проводите ретроспективу, анализируйте, какие подходы были эффективны, и какие уроки можно извлечь. Комбинируйте "культурный" опыт с опытом, получаемым на работе.
Пример: Однажды, размышления о Листе и Рахманинове помогли мне придумать способ разделения пользователей, а именно упростить выдачу продуктовых ролей и при достижении пользователем определенных условий, так как роли перестали быть набором "галочек", а стали разрешением к действиям, как когда-то Рахманинов "разрешил" себе быть и гениальным пианистом и гениальным композитором.
💬Обсуждение: Обсуждение помогает углубить понимание и может привести к новым идеям. Делитесь своими находками с коллегами. Обсуждение углубляет понимание и способствует генерации новых идей.
🪄Креативное мышление: Например, попробуйте использовать методы из геймдизайна для оптимизации пользовательского интерфейса в вашем программном продукте. Как - легко, даже для админки интегрированных продуктов.
Пример: Вспомните работу с "сундуком" и "вещами", возможно, это то, что нужно вам при настройке сложных фильтров для громоздких таблиц с платежами!
🛠Интеграция и применение: Когда встречаете интересную идею или концепцию, подумайте, как ее можно адаптировать и применить в вашей сфере. Не бойтесь экспериментировать с новыми подходами.
Пример: Если бы люди все делали только по инструкции, мир IT никогда бы не получил прекрасный LEAN-Design, так как бережливое производство ТОЛЬКО ДЛЯ АВТОПРОМА!
📚Создайте свою "библиотеку идей": Идея может быть классной, но не ко времени. Заведите заметку/борду, куда будете выписывать "озарения", и иногда проводите ревизию.
И знаете что? Насмотренность - навык, который можно развивать не только у себя, но и у младших членов вашей семьи, превращая обучение в увлекательную игру. И вместе с детьми прокачивать себя! Если хотите расскажу как-ниб про игры, которые прокачают вас и "займут" ребенка?
А как вы тренируете "насмотренность" и помогает ли она вам в работе?
#product_management
Привет! Наконец-то давно обещанный пост о "насмотренности" — умении видеть глубже очевидного. Это та самая способность, которая помогает нам не просто смотреть, но видеть и анализировать, связывая казалось бы несвязанное!
🚀 Вдохновение из всех источников
Развитие насмотренности особенно важно в профессиональной деятельности, например, при проектировании архитектуры в IT. Умение видеть скрытые связи между элементами помогает находить инновационные решения и улучшать продукт.
✍️ Советы для повседневной практики:
👁🗨Расширяйте кругозор: Чем больше вы знакомитесь с разными жанрами искусства, культуры или пробуете что-то новое, тем больше нейронных связей устанавливает ваш мозг. Изучайте, как сделано у других, исследуйте открытые источники, интересуйтесь новыми технологиями и методологиями — это поможет вам находить неочевидные решения для сложных технических задач.
Пример: вам необходимо сделать гибкую систему комиссий за проведение платежа. Можно пойти по пути типизации платежей, а можно, по аналогии с системой MCC-кодов, вынести основное назначение платежей на уровень мерчантов и, в зависимости от мерчанта и вида его деятельности, настроить динамический % за услуги.
⚖️Анализ и рефлексия: После просмотра фильма, прочтения книги или посещения выставки попробуйте задуматься, какие идеи или темы вы могли бы адаптировать в своей работе. После каждого проекта проводите ретроспективу, анализируйте, какие подходы были эффективны, и какие уроки можно извлечь. Комбинируйте "культурный" опыт с опытом, получаемым на работе.
Пример: Однажды, размышления о Листе и Рахманинове помогли мне придумать способ разделения пользователей, а именно упростить выдачу продуктовых ролей и при достижении пользователем определенных условий, так как роли перестали быть набором "галочек", а стали разрешением к действиям, как когда-то Рахманинов "разрешил" себе быть и гениальным пианистом и гениальным композитором.
💬Обсуждение: Обсуждение помогает углубить понимание и может привести к новым идеям. Делитесь своими находками с коллегами. Обсуждение углубляет понимание и способствует генерации новых идей.
🪄Креативное мышление: Например, попробуйте использовать методы из геймдизайна для оптимизации пользовательского интерфейса в вашем программном продукте. Как - легко, даже для админки интегрированных продуктов.
Пример: Вспомните работу с "сундуком" и "вещами", возможно, это то, что нужно вам при настройке сложных фильтров для громоздких таблиц с платежами!
🛠Интеграция и применение: Когда встречаете интересную идею или концепцию, подумайте, как ее можно адаптировать и применить в вашей сфере. Не бойтесь экспериментировать с новыми подходами.
Пример: Если бы люди все делали только по инструкции, мир IT никогда бы не получил прекрасный LEAN-Design, так как бережливое производство ТОЛЬКО ДЛЯ АВТОПРОМА!
📚Создайте свою "библиотеку идей": Идея может быть классной, но не ко времени. Заведите заметку/борду, куда будете выписывать "озарения", и иногда проводите ревизию.
И знаете что? Насмотренность - навык, который можно развивать не только у себя, но и у младших членов вашей семьи, превращая обучение в увлекательную игру. И вместе с детьми прокачивать себя! Если хотите расскажу как-ниб про игры, которые прокачают вас и "займут" ребенка?
А как вы тренируете "насмотренность" и помогает ли она вам в работе?
#product_management
❤6👍4
🚀 10 Капитанских правил для REST-API в Финтехе 🚀
Привет всем!
На протяжении многих лет работы в IT я сталкиваюсь с "детскими болезнями" API. Не смотря на то, что написана масса статей, сделано множество докладов, и даже изданы книги, но проблема качества API возвращается как бумеранг. API — это лицо компании. И к сожалению, очень часто, вместо того чтобы сделать его прекрасным, мы делаем его "помятым". Вот мои 10 капитанских правил, как сделать API лучше:
1️⃣ Понятность названий параметров: Каждый параметр должен однозначно объяснять своё предназначение и формат. Пример: параметр "visibility_flag", кажется должен быть булевым (true/false). Однако часто такие параметры могут быть представлены как int со значениями 0, 1, 2, 3... Это создаёт путаницу и уменьшает читаемость API.
2️⃣ Использование префикса для булевых переменных: Для булевых переменных используйте префикс 'is', например, 'is_visible'. Это сразу делает понятным, что переменная имеет два состояния: истина (и true = видимо) или ложь, и упрощает работу с кодом.
3️⃣ Ясное описание происходящего: Если можно объяснить ситуацию словами — делайте это. Вместо того чтобы заставлять пользователя дешифровать числовые значения в 'invisibility_reason', лучше сразу указывать причину: 'blocked', 'fraud', 'no money'. Это делает API более дружелюбным и понятным.
4️⃣ Прозрачность ошибок: Не заставляйте пользователей разбираться в сложных таблицах для понимания ошибок. Ошибки должны быть понятны и просты для интерпретации, чтобы пользователи могли быстро находить и исправлять проблемы. Самый странный протокол в моей жизни содержал 57 печатных страниц с расшифровкой кодов ошибок.
5️⃣ Полная информация об ошибках: Если в процессе выполнения запроса обнаружено несколько ошибок, сообщайте о всех одновременно. Это позволяет пользователям быстрее и эффективнее устранять проблемы. Пример: отправлены данные пользователя. Но одно из обязательных полей пропущено, а в паспорте нехватает цифры. Если обе проверки выполняются на API (а скорее всего - да, так как это валидация данных) - отдайте сразу обе ошибки и о нехватке данных, и об ошибке в номере паспорта.
6️⃣ Отсутствие дублирующих параметров: Избегайте создания параметров с похожими названиями и разной логикой. Пример: 'is_visible' и 'visible_flag'. Если хотите в поле 'visible_flag' поместить причину - назовите 'visibility_reason', если "буль" передающий информацию о ручной установки видимости из админки 'is_visible_manual'.
7️⃣ Один метод — одна функция: Избегайте создания универсальных методов, которые меняют своё поведение в зависимости от передаваемых параметров. Это усложняет поддержку и отладку. Иногда встречается попытка создать единый метод для старта однофазного и двухфазного платежа, внутри которого флагом отмечается какой это платеж. Вместо того чтобы явно прописать, что за метод вызывает. К сожалению, это путь к проблемному дебагу и сложному мониторингу.
8️⃣ Продуманность структуры данных: Лучше заранее подумать о данных, которые могут понадобиться в будущем (в части сущностей, где вы не main система), чем впоследствии их добавлять. Например, клиент-создается на стороне Мерчанта, вы только обогащаете его параметрами. Но клиент может иметь «галочку», которая вам если и понадобится, то не раньше чем через год. При большой пользовательской базе и части процессов идущих напрямую через вас, добавление параметра через год, может стоить дорого.
9️⃣ Изолированность данных в методах: Убедитесь, что каждый метод работает с данными только одной сущности. Это облегчает понимание и поддержку API. Не стоит в клиентские методы прокидывать параметры счета и наоборот. Если признак тестовости у клиента, а счет не имеет признака тестовости, то методы аккаунтов не должны содержаить параметь 'is_test'.
🔟 Подробные описания кодов: Если ваш API использует специфичные числовые коды, обязательно предоставьте рядом текстовое описание. Это поможет другим разработчикам и поддержке быстрее разобраться в работе системы.
Надеюсь, эти правила помогут сделать наш API не просто функциональным, но и удобным в использовании!
#architecture
Привет всем!
На протяжении многих лет работы в IT я сталкиваюсь с "детскими болезнями" API. Не смотря на то, что написана масса статей, сделано множество докладов, и даже изданы книги, но проблема качества API возвращается как бумеранг. API — это лицо компании. И к сожалению, очень часто, вместо того чтобы сделать его прекрасным, мы делаем его "помятым". Вот мои 10 капитанских правил, как сделать API лучше:
1️⃣ Понятность названий параметров: Каждый параметр должен однозначно объяснять своё предназначение и формат. Пример: параметр "visibility_flag", кажется должен быть булевым (true/false). Однако часто такие параметры могут быть представлены как int со значениями 0, 1, 2, 3... Это создаёт путаницу и уменьшает читаемость API.
2️⃣ Использование префикса для булевых переменных: Для булевых переменных используйте префикс 'is', например, 'is_visible'. Это сразу делает понятным, что переменная имеет два состояния: истина (и true = видимо) или ложь, и упрощает работу с кодом.
3️⃣ Ясное описание происходящего: Если можно объяснить ситуацию словами — делайте это. Вместо того чтобы заставлять пользователя дешифровать числовые значения в 'invisibility_reason', лучше сразу указывать причину: 'blocked', 'fraud', 'no money'. Это делает API более дружелюбным и понятным.
4️⃣ Прозрачность ошибок: Не заставляйте пользователей разбираться в сложных таблицах для понимания ошибок. Ошибки должны быть понятны и просты для интерпретации, чтобы пользователи могли быстро находить и исправлять проблемы. Самый странный протокол в моей жизни содержал 57 печатных страниц с расшифровкой кодов ошибок.
5️⃣ Полная информация об ошибках: Если в процессе выполнения запроса обнаружено несколько ошибок, сообщайте о всех одновременно. Это позволяет пользователям быстрее и эффективнее устранять проблемы. Пример: отправлены данные пользователя. Но одно из обязательных полей пропущено, а в паспорте нехватает цифры. Если обе проверки выполняются на API (а скорее всего - да, так как это валидация данных) - отдайте сразу обе ошибки и о нехватке данных, и об ошибке в номере паспорта.
6️⃣ Отсутствие дублирующих параметров: Избегайте создания параметров с похожими названиями и разной логикой. Пример: 'is_visible' и 'visible_flag'. Если хотите в поле 'visible_flag' поместить причину - назовите 'visibility_reason', если "буль" передающий информацию о ручной установки видимости из админки 'is_visible_manual'.
7️⃣ Один метод — одна функция: Избегайте создания универсальных методов, которые меняют своё поведение в зависимости от передаваемых параметров. Это усложняет поддержку и отладку. Иногда встречается попытка создать единый метод для старта однофазного и двухфазного платежа, внутри которого флагом отмечается какой это платеж. Вместо того чтобы явно прописать, что за метод вызывает. К сожалению, это путь к проблемному дебагу и сложному мониторингу.
8️⃣ Продуманность структуры данных: Лучше заранее подумать о данных, которые могут понадобиться в будущем (в части сущностей, где вы не main система), чем впоследствии их добавлять. Например, клиент-создается на стороне Мерчанта, вы только обогащаете его параметрами. Но клиент может иметь «галочку», которая вам если и понадобится, то не раньше чем через год. При большой пользовательской базе и части процессов идущих напрямую через вас, добавление параметра через год, может стоить дорого.
9️⃣ Изолированность данных в методах: Убедитесь, что каждый метод работает с данными только одной сущности. Это облегчает понимание и поддержку API. Не стоит в клиентские методы прокидывать параметры счета и наоборот. Если признак тестовости у клиента, а счет не имеет признака тестовости, то методы аккаунтов не должны содержаить параметь 'is_test'.
🔟 Подробные описания кодов: Если ваш API использует специфичные числовые коды, обязательно предоставьте рядом текстовое описание. Это поможет другим разработчикам и поддержке быстрее разобраться в работе системы.
Надеюсь, эти правила помогут сделать наш API не просто функциональным, но и удобным в использовании!
#architecture
🔥8👍5❤2
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