Материалы в категории: Гайды – CreatikSoft

Зачем цифровой рубль банкам, бизнесу и обычным россиянам

Egor Zayakin — Wed, 07 May 2025 06:21:33 +0000

Центробанк активно развивает цифровой рубль — третью форму национальной валюты, наряду с наличными и безналичными деньгами. Первые цифровые кошельки уже проходят пилотную проверку, а платежи по QR-коду в цифровых рублях скоро станут привычной частью жизни. Но это не просто запустит новую платёжную технологию — это приведёт к пересборке всей финансовой инфраструктуры страны.
Что нужно знать бизнесу, банкам и простым пользователям прямо сейчас?

The post Зачем цифровой рубль банкам, бизнесу и обычным россиянам first appeared on CreatikSoft.

ArchDays 2023. Что было интересного и что поменялось с 2019 года

Dmitry Barabanov — Sun, 14 Jan 2024 12:17:41 +0000

ArchDays 2023. Что было интересного и что поменялось с 2019 года В конце октября 2023 года я посетил конференцию по архитектуре IT-решений ArchDays в Москве. Я привез доклад, где рассказал о двух практических кейсах из области баз данных, с которыми столкнулся в наших проектах. И это был мой второй приезд на эту конференцию. Первый раз я был здесь в 2019 году, тоже в качестве спикера — рассказывал о контрактных тестах для микросервисов. Как выяснилось, эта была вообще самая первая конференция ArchDays. Так что для самого мероприятия позади остался большой путь в 5 лет, а у меня есть счастливая возможность сравнить обе конференции и поделиться впечатлениями в виде вопросов и ответов. Для чего проводятся ArchDays? Как заявляют сами организаторы: Мы определяем цель конференции как «распространение имеющихся и создание новых знаний об архитектуре программных решений». Мы решили пойти дальше принятого формата и в дополнение к докладам, преследующим своей целью распространение знаний, попытаться найти решения еще не решенных проблем в архитектуре. И они действительно последовательны в достижении этой цели. А еще, о чем ребята не сказали, но добавлю уже от себя я — это позволяет целиком, на один день, что называется, «повариться» среди архитекторов, сеньоров и крутых разработчиков, пообщаться запросто, как водится в IT-индустрии, поймать какие-то инсайды, идеи, взглянуть на проекты и архитектуру свежим взглядом, увидеть, где сейчас бьётся архитектурная мысль. Другими словами, перезагрузить и сформировать правильный mindset. А ещё (что замечаю не только я), благожелательность и драйв, которые царят весь этот насыщенный день, дают максимально позитивный настрой и невероятно заряжают. В заключение ответа на первый вопрос даю слово организаторам и участникам: Хроники ArchDays’23 https://youtu.be/qTjHSA_5Et0?si=9OUJNKfatgGiwdin Вообще, все видео с докладами обязательно выкладываются спустя несколько месяцев, ловить их можно на канале www.youtube.com/@archdays и в Rutube, а слайды уже доступны. Что изменилось с 2019 года? Популярность конференции растет с каждым годом. Если в 2019 году было 300 участников и 15 докладов, то в году уходящем — уже 900 участников и 30 докладов. Но что поменялось еще, кроме статистики? В 2019 году цель конференции формулировалась чуть иначе: Распространение имеющихся и создание новых знаний о микросервисах и эволюционной архитектуре. Как вспоминал во вступительном слове организатор конференции из компании Scrumtrek Сергей Баранов, в 2019 году был «хайп вокруг микросервисов». Сейчас этого уже нет, микросервисная архитектура прочно заняла свое место и стала стандартом отрасли. Так что сегодня фокус переместился непосредственно на архитектуру, стандартизацию архитектурных решений и даже их автоматизацию. И я тоже при выборе докладов для посещения делал акцент именно на архитектурные решения. Что еще отметил — красной нитью везде проходила мысль, что всё является кодом. Было несколько крайне интересных выступлений, с конкретными практиками по использованию этого подхода применительно к архитектуре и даже… как её тестировать, настоящий космос. Но об этом ниже. Что унёс и что было интересного в докладах? Обобщая, можно выделить несколько основных идей, прозвучавших в разных выступлениях. Архитектура как код. Это — ключевой принцип, из которого вытекает всё нижеследующее. Стандартизация описания архитектурных решений. Для достижения этого надо использовать единый глоссарий, хранение в репозитории, а также применять общий инструментарий во всех разрабатываемых продуктах. Например: Формат MARKDOWN для описательной части (что позволяет одновременно иметь и код, с историей изменений, и форматированный текст), PLANTUML для схем и диаграмм(что также позволяет иметь и код, и изображение одновременно), Модель C4 (Context, Containers, Components, and Code) для визуализации архитектуры. Тестирование архитектуры. Если описание архитектуры стандартизовано, её можно тестировать, о чем было много докладов. Автоматизация архитектурного и сервисного контроля. Тоже самое — стандартизация позволяет выйти на ещё более высокий уровень и автоматизировать даже сам контроль принятых архитектурных и сервисных решений, экономя буквально человеко-месяцы. Из всех докладов, где я был (а они все были интересные и полезные), отмечу особо некоторые архитектурно-обобщающие. “Расширяемая Архитектура: универсальность продукта, эффективность разработки” Дмитрия Мамонова из компании WrikeWrike это платформа для оптимизации и организации всех рабочих процессов и проектов.Интересны грабли, с которым столкнулся Wrike при изначально неправильном проектировании архитектуры, что не позволило осуществлять линейную расширяемость с течением времени. Этого можно было избежать с самого начала проектирования системы. Рецепты вкратце: плагины, метаданные и связанный конкест (bounded context). “Governance as Code / Технология автоматизации архитектурного контроля” Ярослава Панасюка из Agoda (Booking Holdings) Хотя, на самом деле, он обобщал опыт Сбера. Этот доклад и последующие ниже, о которых упомяну, были примерно об одном — практическое использование подхода “архитектура как код”. Описанная в докладе технология — один из ключевых компонентов системы архитектурного проектирования в Сбере под названием МЕТА. Система позволяет делать архитектурный контроль и учет полностью автоматически, неважно на каком языке написан сервис, на каком стеке и с какой технологией, причем используя любые настраиваемые правила и критерии, и даже — обратный инжиниринг. Космос. “Архитектура Шредингера и способы борьбы с ней” Сергея Кучина из компании LadСвоеобразный доклад, связанный с предыдущими по части использования архитектуры как кода, но с элементами философии.Что такое “Архитектура Шредингера” по автору? Это отсутствие системного подхода к архитектуре, который бы придал ей осознанную форму. От себя добавлю, если мы рассматриваем знаменитый мысленный эксперимент Шредингера, кот одновременно жив и мертв. Так что IT-хаос можно описать и с помощью физики. Автор рассматривает жизненные циклы по Адизесу в природе, перенося их на разработку, показывает способы борьбы с энтропией в проекте, что делать на эндгейме продукта, когда развитие остановилось. “Раз архитектура — «as Code», почему бы её не покрыть тестами?!” Руслана Сафина из Byndyusoft Следующий уровень в использовании архитектуры как кода. Руслан заострил внимание на проблемах описания архитектур: Неактуальность; Декларативность; Отсутствие контроля. Рассказал как с этим можно бороться и, более того, тестировать и выявлять проблемы архитектуры и ее реализации, мертвые конфигурации, зависимости, эндпоинты, несанкционированные исходящие и входящие запросы и все, что угодно, — в зависимости от написанных тестов. Другими словами, он разработал совершенно уникальную технологию тестирования архитектуры, поддерживающую различные типы тестирования. Например: Актуальна ли архитектура реальному положению дел на проде? Соблюдает ли архитектура выбранные принципам проектирования и договоренностям команды? Разработка тестов продолжается. Ребята из Byndyusoft любезно выложили текущее решение в гитхабе. Я спросил: нет ли желания сделать его опенсорсным и организовать коммьюнити вокруг технологии? Руслан ответил, что руководство думает, и такие планы есть. Будем наблюдать. Отдельно упомяну реактивные манифесты, о которых упоминал Андрей Василевский из Lamoda Tech в своем докладе “Проектируем распределенные системы без боли

The post ArchDays 2023. Что было интересного и что поменялось с 2019 года first appeared on CreatikSoft.

Эффективное управление рисками с помощью машинного обучения

Dmitry Barabanov — Tue, 26 Dec 2023 07:23:04 +0000

Эффективное управление рисками с помощью машинного обучения Машинное обучение (ML) играет важную роль в управлении рисками в финтех-компаниях, позволяя им более точно и эффективно оценивать, мониторить и управлять различными видами рисков. Вот несколько способов, как ML может использоваться для управления рисками: 1. Кредитный скоринг и оценка кредитоспособности: ML модели могут анализировать множество данных о клиенте, включая кредитную историю, доходы, занятость и многие другие факторы, чтобы точно определить вероятность невозврата кредита. Это помогает финтех-компаниям принимать более обоснованные решения о выдаче кредитов. 2. Мониторинг мошенничества: ML может анализировать транзакции и клиентские активности, чтобы выявлять аномалии, которые могут указывать на мошенническую активность. Автоматизированные системы могут быстро обнаруживать подозрительные транзакции и предпринимать соответствующие меры. 3. Прогнозирование кредитных убытков: ML модели могут предсказывать потенциальные кредитные убытки, основываясь на анализе исторических данных и текущей экономической ситуации. Это помогает компаниям адекватно резервировать средства для покрытия потенциальных убытков. 4. Оценка риска инвестиций: ML может использоваться для анализа портфелей инвестиций и определения рисков, связанных с различными активами. Это позволяет инвесторам и управляющим активами принимать более информированные решения. 5. Анализ рыночных данных: ML модели могут анализировать рыночные тенденции и события, чтобы предсказывать риски, связанные с изменениями цен на активы, валютные курсы и другие факторы. 6. Управление операционными рисками: ML может помочь идентифицировать операционные риски, связанные с процессами и технологией компании. Это включает в себя анализ данных о сбоях в системах, ошибках в операциях и других аспектах операционных рисков. 7. Риск соблюдения законодательства (комплаенс): ML может использоваться для автоматизации мониторинга соблюдения законодательства и стандартов в финансовой сфере, помогая предотвращать нарушения и связанные с ними штрафы. 8. Автоматизация процессов мониторинга и управления рисками: ML позволяет создавать автоматизированные системы мониторинга и управления рисками, что позволяет компаниям быстрее реагировать на изменяющиеся условия и риски. Машинное обучение обеспечивает более точное и быстрое прогнозирование рисков, что помогает финтех-компаниям принимать более обоснованные решения, снижать потери и обеспечивать безопасность своих операций. Пример расчета возврата инвестиций (ROI) от внедрения ML в финтех-компанию Предположим, вы внедрили ML-модель для автоматизированного кредитного скоринга в вашей финтех-компании. Вас интересует оценка ROI на протяжении первого года после внедрения. 1. Инвестиции: Затраты на разработку и внедрение ML модели. Затраты на обучение персонала и интеграцию модели в существующие процессы. Расходы на инфраструктуру и оборудование (если применимо). Лицензионные сборы и поддержку для используемых ML-инструментов и библиотек. 2. Выгоды Снижение затрат на ручную оценку кредитоспособности и принятие решений о выдаче кредитов. Увеличение точности кредитного скоринга и, как следствие, снижение доли невозвратов. Увеличение объема выданных кредитов благодаря более точной оценке риска. Увеличение клиентской удовлетворенности благодаря более быстрым и точным решениям. 3. Расчет ROI: ROI = ((Выгоды — Инвестиции) / Инвестиции) * 100 Предположим, что внедрение ML-модели обошлось вам в $200,000, а вы получили следующие оценки выгод: Снижение затрат на ручное принятие решений о кредитах: $100,000 Снижение доли невозвратов на 10%, что принесло дополнительные $50,000 прибыли. Увеличение объема выданных кредитов на $500,000. Тогда расчет ROI будет следующим: ROI = (($100,000 + $50,000 + $500,000) — $200,000) / $200,000 * 100 = 275% Таким образом, ROI от внедрения ML в этом примере составляет 275%. Это означает, что каждый доллар, вложенный в разработку и внедрение ML-модели, приносит $2.75 в виде выгод. Предыдущая записьСледующая запись

The post Эффективное управление рисками с помощью машинного обучения first appeared on CreatikSoft.

Кибербезопасность в Финтехе: технологии защиты от угроз

Dmitry Barabanov — Tue, 19 Dec 2023 07:47:28 +0000

Кибербезопасность в Финтехе: технологии защиты от угроз С развитием финансовых технологий (ФинТех) и переходом к цифровым платежам, кибербезопасность стала одним из наиболее важных аспектов в сфере финансовых услуг. Угрозы кибербезопасности становятся все более сложными и изощренными, поэтому важно постоянно разрабатывать и внедрять новые методы обеспечения безопасности. В этой статье мы рассмотрим инновационные технологии защиты от угроз в финтех-проектах и как разработчики могут укрепить защиту своих систем. 1. Блокчейн и Криптография: Блокчейн — это не только технология для криптовалют. Он также служит отличным средством защиты данных. Технология блокчейн обеспечивает децентрализацию и непреложную целостность данных, что делает невозможным вмешательство со стороны злоумышленников. 2. Многофакторная Аутентификация: Методы аутентификации на основе нескольких факторов (что-то, что вы знаете, что-то, что у вас есть, что-то, что вы являетесь) становятся стандартом в финансовых приложениях. Это включает в себя использование паролей, биометрических данных, а также одноразовых кодов, что делает взлом учетных записей практически невозможным. 3. Искусственный Интеллект и Машинное Обучение: Искусственный интеллект (ИИ) и машинное обучение (МО) используются для анализа больших данных и выявления аномалий в поведении пользователей. Это помогает в реальном времени выявлять подозрительные активности и предотвращать потенциальные угрозы. 4. Квантовая Криптография: Квантовая криптография — это новая горизонталь в области кибербезопасности. Она использует принципы квантовой механики для защиты данных. Квантовая криптография предоставляет абсолютную безопасность коммуникаций, поскольку любая попытка перехвата данных приводит к изменению их состояния и тем самым к обнаружению вмешательства. 5. Системы Реагирования в Реальном Времени: Системы, способные реагировать на угрозы в реальном времени, становятся все более важными. С использованием алгоритмов машинного обучения, эти системы могут автоматически выявлять и блокировать подозрительные активности, минимизируя временной промежуток между обнаружением угрозы и принятием мер по ее предотвращению. Заключение: ФинТех и кибербезопасность неразрывно связаны в современном цифровом мире. Разработчики финтех-проектов должны быть в курсе последних технологий и методов обеспечения кибербезопасности, чтобы гарантировать безопасность данных клиентов и сохранность финансовых операций. Инновационные решения, такие как блокчейн, искусственный интеллект и квантовая криптография, предоставляют надежные инструменты для борьбы с современными киберугрозами, делая финансовые технологии более безопасными и устойчивыми. Предыдущая записьСледующая запись

The post Кибербезопасность в Финтехе: технологии защиты от угроз first appeared on CreatikSoft.

Новые горизонты возможностей в мире Финтеха — Искусственный Интеллект

Dmitry Barabanov — Wed, 06 Dec 2023 18:59:42 +0000

Новые горизонты возможностей в мире Финтеха — Искусственный Интеллект Современный мир ФинТеха – это не только банкоматы и кредитные карты. Это мир, где технологии меняют наше представление о финансах. Одной из самых захватывающих и перспективных технологий, которая внедряется в финансовую сферу, является искусственный интеллект. Искусственный интеллект – это не просто техническое словосочетание. Это новый способ мышления компьютеров, который делает их умнее и более адаптивными. В контексте ФинТеха, искусственный интеллект становится невероятно мощным инструментом, который помогает улучшить сервисы и сделать финансовые услуги более доступными для каждого. Одним из ключевых применений искусственного интеллекта в ФинТехе является кредитный скоринг. Традиционные методы оценки кредитоспособности могут быть не слишком точными и справедливыми. Искусственный интеллект, анализируя большие объемы данных, может выявить скрытые закономерности и предсказать, насколько надежен заёмщик. Это позволяет выдавать кредиты тем, кто раньше был бы отвергнут, и предоставлять более выгодные условия для клиентов. Еще одной областью, где искусственный интеллект проявляет свою силу, является управление инвестициями. Искусственный интеллект способен анализировать огромные объемы финансовых данных, выявлять тренды на рынке и предсказывать колебания цен. Это позволяет инвестиционным компаниям принимать более обоснованные решения, минимизируя риски и максимизируя прибыль. Кроме того, искусственный интеллект делает финансовые услуги более персонализированными. Системы искусственного интеллекта могут анализировать данные о клиенте и предлагать ему продукты и услуги, которые соответствуют его потребностям и возможностям. Это создает уникальный опыт для каждого клиента, делая его взаимодействие с финансовой компанией более удобным и приятным. Но наряду с бесспорными преимуществами, искусственный интеллект также представляет собой вызовы. Одним из них является вопрос безопасности данных. С увеличением объема обрабатываемых данных возрастает и риск их утечки или взлома. Поэтому разработчики и исследователи активно работают над тем, чтобы обеспечить максимальную защиту данных клиентов. В заключение можно сказать, что искусственный интеллект преобразует мир ФинТеха, делая его более эффективным и удобным для всех. Он открывает новые горизонты и возможности, которые раньше казались невозможными. Но вместе с тем он требует ответственного отношения и внимания к вопросам безопасности. В будущем финансовая индустрия будет неразрывно связана с искусственным интеллектом, и те, кто сможет правильно использовать эту технологию, выиграет гонку за будущее финансовых услуг. Предыдущая записьСледующая запись

The post Новые горизонты возможностей в мире Финтеха — Искусственный Интеллект first appeared on CreatikSoft.

Definition of Done

Dmitry Barabanov — Mon, 09 Oct 2023 17:13:43 +0000

Definition of Done Как у вас дела с разработкой в целом? Такой вопрос может запросто сбить с толку. Хочется ответить или слишком коротко, или слишком длинно. С чего вообще начинать рассказывать? Лайфхак: в следующий раз, когда вам зададут подобный вопрос, в ответ показывайте ваш Definitiоn оf Dоne. Там есть многое из того, о чём вас спросили. Сейчас объясним на примере DoD на одном из наших флагманских проектов. Строго говоря, помогать отбиваться от неудобных вопросов — не то, чтобы самое прямое назначение DoD. В канонах Agile этот артефакт — список критериев, что команда будет считать выполненной работой. Обсудить; проверить, что все понимают критерии плюс-минус одинаково; повесить на видном месте; сверяться со списком в конце работы над фичей, спринтом или релизом. Алгоритм такой. Критерии не выполнены — такие user story (или job-to-be-done, или на что вы нарезаете бэклог) считаем не готовыми; не учитываем при подсчёте velocity. Выполнены — учитываем. Если посмотреть на DoD внимательно, там можно увидеть не только формальные критерии. Список рассказывает об особенностях проекта. Слишком много пунктов? Возможно, были инциденты и теперь команда перестраховывается, или где-то сбоят коммуникации. Не обновлялся с тех пор, как появился? Возможно, проект так и не вышел на желаемый уровень качества кода; по сроку должна бы уже быть зрелая стадия развития, а по факту ещё нет. Списка нет совсем? Скорее всего, речь о стартапе или уже-не-стартапе, который решительно нуждается в хорошем менеджере проектов. В действительно используемом DoD каждый пункт отражает важные события из проекта. Что-то часто ломалось? Запишем в DoD. Что-то никогда не должно ломаться ни при каких обстоятельствах? Запишем в DoD. Запишем всё, что можно забыть или нужно обязательно проверить. Это что-то вроде свода законов в системе прецедентного права. На упаковке с орехами написано раскрыть перед тем, как начать есть? Значит, кто-то пытался сделать иначе. Пример Вот DoD на одном из наших проектов: + Вся бизнес-логика задачи покрыта юнит-тестами + Обеспечена совместимость с предыдущими версиями API + API задокументировано + все ошибки перечислены и описаны + все устаревшие вызовы перенесены в соответствующий раздел документации соответствующую часть кода + Мониторинг и логирование добавлены в нужном объёме + Процедура отката нового кода с сервера настроена + Все связанные задачи проверены и закрыты + Проверены и закрыты все недостатки, о которых сообщила автоматическая система анализа кода (мы используем Sonar) + Документация обновлена — записаны: + описание задачи + детали реализации + Конечный результат проверен вместе с Product Owner Что здесь можно увидеть? Работу распределённых команд, погоню за зрелыми DevOps-практиками, коммуникацию с заказчиком. Намётанный глаз даже разглядит здесь примерный размер кодовой базы. Ок, что из этого списка можно унести в другие проекты? It depends. DoD у всех уникальные. Но есть общие паттерны. Не гнаться за всеобъемлющим DoD. Там должны быть минимальные требования к тому, что можно считать готовым. Не раздувать DoD. Искать способы автоматизировать проверки и убрать из списка то, что можно проверять системно, без участия человека. Не стремиться создать жёсткий стандарт, запрещающий всё, что в него не вписывается. Для отдельных фичей требуются дополнительные acceptance criteria, которых нет в общем DoD? Ок, пусть для этих задач это будет так. Проверить, что DoD — это не просто формальность в духе «да-да, мы всё обсудили и теперь понимаем критерии готовности задачи одинаково», а озвученные, записанные и вывешенные на видном месте правила. И самое главное: регулярно делать ревизию DoD. Нам эти принципы сильно помогли в своё время. Следующий шаг Когда вас в следующий раз спросят, как дела с разработкой в целом, вспомните про DoD. А вообще, не дожидайтесь, когда спросят. Посмотрите на ваш DoD прямо сегодня. Всего ли там хватает? Нет ли лишнего? Надеемся, пункты из нашего DoD смогут натолкнуть вас на мысли, как можно было бы улучшить ваш. *** Участвовали в создании статьи: Евгений Степченко, Project Manager Сергей Никитин, Frontend Engineer Софья Королёва, System Analyst Евгений Горбачёв, Advanced Java Developer Предыдущая записьСледующая запись Экспресс-консультация 1. Наш специалист свяжется с вами в ближайшее время. 2. В рамках консультации уточним необходимую информацию для анализа вашего проекта. 3. Команда аналитиков и разработчиков подготовят оценку по вашему проекту. Получить консультацию

The post Definition of Done first appeared on CreatikSoft.

English: An Efficient Object Storage for JUnit Tests

Dmitry Barabanov — Fri, 31 Jan 2020 13:40:00 +0000

English: An Efficient Object Storage for JUnit Tests Юнит-тесты – хорошо. Ок, а если работаем с облаками от Amazon? А если у нас PosgtreSQL? Если ограничения на вытаскивание и хранение данные? Тогда юнит-тесты – хорошо, но есть вопросы, как лучше всё организовать. Разбираемся в нашей новой статье на DZone. Читать статью Предыдущая записьСледующая запись Экспресс-консультация 1. Наш специалист свяжется с вами в ближайшее время. 2. В рамках консультации уточним необходимую информацию для анализа вашего проекта. 3. Команда аналитиков и разработчиков подготовят оценку по вашему проекту. Получить консультацию

The post English: An Efficient Object Storage for JUnit Tests first appeared on CreatikSoft.

English: Гексагональная архитектура для начинающих

Dmitry Barabanov — Mon, 09 Sep 2019 14:32:00 +0000

English: Гексагональная архитектура для начинающих Наши посты на английском бывают на DZone. Из недавнего: статья про гексагональную архитектуру для начинающих, от Александра Кириленко, нашего Backend разработчика на java. Предыдущая записьСледующая запись Экспресс-консультация 1. Наш специалист свяжется с вами в ближайшее время. 2. В рамках консультации уточним необходимую информацию для анализа вашего проекта. 3. Команда аналитиков и разработчиков подготовят оценку по вашему проекту. Получить консультацию

The post English: Гексагональная архитектура для начинающих first appeared on CreatikSoft.

Как работают хорошие комментарии к коммитам

Dmitry Barabanov — Mon, 06 May 2019 14:48:00 +0000

Как работают хорошие комментарии к коммитам Время — деньги. Время — это дорого. Время вывода продукта на рынок — очень дорого. Время Senior-разработчика — неприлично дорого. Именно поэтому хороший комментарий к коммиту так важен. “Контекст! Контекст! Полцарства за контекст!” Чем дольше вы работаете, в большем числе проектов участвуете, видите больше разного кода — тем выше шансы, что вы видели безобразные комментарии к коммитам. Вот часть лога из реальной кодовой базы: Что это за правки? Почему они так ужасно отформатированы? Почему никто не попытался соблюсти хоть какой-то единый стиль кодовой базы? Кто виноват? “Однажды в далёкой-далёкой галактике мы что-то меняли в нашем коде…”. Давайте сравним этот лог с недавними коммитами в Spring на Github: Какие комментарии вам больше понравится читать? Какие — более чёткие и последовательные? Грамотный комментарий к коммиту— это лучший способ рассказать коллегам о контексте изменений в коде. По диффам можно будет увидеть, что изменилось. Но только комментарий к коммиту расскажет, почему что-то изменилось. Peter Hutterer однажды сказал: Любое программное обеспечение — это командный проект. Там будет, как минимум, два разработчика: тот, кто написал исходный код, и тот же самый разработчик, но несколькими неделями или месяцами позже, когда поезд задумки уже давно покинул станцию отправления. Более поздний будет вынужден восстанавливать контекст для конкретной части кода каждый раз, когда появляется новый баг или нужно добавить новую фичу. Восстанавливать контекст части кода — трудозатратно. Нам придётся это делать, так что давайте направим усилия на то, чтобы минимизировать эти трудозатраты, насколько это возможно. Комментарии к коммитам делают как раз это. В конечном счёте, они показывают, насколько разработчик способен к совместной работе. Как выглядит хороший комментарий к коммиту Точного определения идеального коммита не существует. Но мы в компании стараемся следовать известным best practices. Вот некоторые из них. Три вопроса Peter Hutterer говорит, что хороший комментарий к коммиту должен отвечать на три вопроса: Почему этот коммит необходим? Это может быть исправление бага, добавление новой фичи, улучшение быстродействия, надёжности, стабильности, или просто правка, которую нужно сделать. Как коммит решает задачу? Для небольших очевидных правок эту часть можно пропустить. Но даже в этом случае должно существовать высокоуровневое описание использованного подхода. На что влияет эта правка? (Помимо очевидных эффектов, речь может идти о соответствии бенчмаркам, побочных эффектах и других последствиях) Эти три вопроса описывают контекст конкретных изменений в коде. Коллеги, кто будет проверять правки, и остальные, кто увидит этот код — будут смотреть на изменения в заданных рамках; смогут проверить, что подход к решению задачи был выбран верно. Одно логическое изменение При прочих равных условиях, хороший коммит должен менять логику кода в одном единственном аспекте. Добавлять одну фичу, исправлять один конкретный баг, делать рефакторинг понятной локальной части кода и так далее. Не следует смешивать изменения из разных областей в едином коммите. Большие изменения стоит разделять и разносить по разным коммитам. Это сильно упростит задачу понимания изменений для тех, кто проверяет код. Семь правил Chris Beams выделяет семь правил для написания хороших комментариев к коммитам. Обратите внимание: всё это уже было описано в разных источниках. Ставьте пустую строку между заголовком и описанием. Ограничьтесь 50 символами в заголовке. Пишите заголовок с большой буквы. Не ставьте точку в конце заголовка. Используйте повелительное наклонение в заголовке. Делайте переносы в описании после 72 символов в строке. Используйте описание, чтобы объяснить, что и почему, вместо как. Например: Эти правила выглядят просто, но от этого не начинают приносить меньше пользы. Они позволяют команде быть в едином контексте, сохранять целостность продукта, удобно отслеживать изменения, восстанавливать ход рассуждений без того, чтобы каждый раз дёргать автора изменений. Ирония в том, что этим автором можете быть вы сами, несколькими месяцами ранее. Но как давно были сделаны изменения и даже работает ли по-прежнему человек в том же проекте — с хорошими комментариями к коммитам это не важно. Если свести статью к одной фразе: используйте best practices, чтобы контролировать изменения в коде. Помните: вы не одни в проекте. Позаботьтесь об остальных. Счастливо попрограммировать! Автор Евгений Горбачёв, Software Developer Предыдущая записьСледующая запись Экспресс-консультация 1. Наш специалист свяжется с вами в ближайшее время. 2. В рамках консультации уточним необходимую информацию для анализа вашего проекта. 3. Команда аналитиков и разработчиков подготовят оценку по вашему проекту. Получить консультацию

The post Как работают хорошие комментарии к коммитам first appeared on CreatikSoft.

Чеклист для Code Review

Dmitry Barabanov — Thu, 29 Nov 2018 16:16:00 +0000

Чеклист для Code Review У нас есть принципы проведения code review. Вот прямо в виде отдельного документа. Зачем так заморачиваться? На первый взгляд с code review всё понятно. Вот код, вот его автор, вот ревьюер — он комментирует. Автор смотрит комментарии, делает правки. Код стал лучше; можно мёрджить. Вроде всё просто? На деле всё интереснее. Культура обратной связи, процесс формирования и обновления принципов code style в компании, обучение, knowledge sharing. Всё это влияет на процесс. Code review может быть инструментом для обеспечения нужного качества кода, а может превратиться в кошмар — повод для бесконечных склок, бюрократию, недоразумение. Мы хотим пользоваться потенциалом code review по части пользы и избегать побочных эффектов. Для этого мы решили начать с простого шага — договориться. Сделать так, чтобы все участники процесса понимали суть происходящего плюс-минус одинаково. Список принципов получился вот такой. Базовые договорённости + Нашей целью не является создание идеального кода. Настоящая цель — обеспечить приемлемое качество. + Через процедуру ревью должны проходить все изменения в коде. Апрув от квалифицированного ревьюера — это обязательное условие перед тем, как делать merge в мастер. + Этот процесс нужен, чтобы улучшить качество кода, который мы создаём; управлять распространением знаний о проекте; продвигать общие подходы к дизайну и паттернам. + Ещё, ревью — это инструмент обучения: и ревьюер, и ревьюируемый могут узнать что-то новое. Правила для всех + Мы отдаём себе отчёт в том, что многие технические решения являются частным мнением. Обсуждаем варианты и стремимся достигать компромисса быстро. НЕТ Твой вариант плохой, сделай по-другому. ДА Интересное решение, у меня есть ещё одно. Как тебе такой вариант: … ? + Считаем, что в любой непонятной ситуации лучше обсудить детали в оффлайне; так быстрее. В таком случае в комментариях потом пишем решение, до которого договорились. НЕТ Я совсем не понял, зачем ты сделал это преобразование. ДА Мы договорились, что этот код нужен для того, чтобы … + Задаём вопросы, а не требуем. НЕТ Тебе надо назвать эту переменную x. ДА Как смотришь на то, чтобы назвать эту переменную x? + В любой непонятной ситуации сначала просим прояснить, прежде чем двигаться дальше. НЕТ Тут непонятно. Переделай. ДА Тут мне не совсем понятно. Можешь пояснить? + Помним, что обсуждаем код. Не используем «человеческие» характеристики в комментариях, особенно оскорбительные. НЕТ Что за тупой код?! ДА Этот код не решает исходную задачу. Вот почему: … + Считаем, что каждый участник процесса умный и не стремится намеренно сделать плохо. НЕТ Ты нарочно что ли делаешь ту же ошибку уже в пятый раз? ДА В прошлый раз мы обсуждали вот такой момент. Сейчас он снова появился. Давай поймём, как не допустить его в следующий раз? + Выражаемся простыми словами. Помним, что собеседник в онлайне не всегда может понять наши намерения по высказыванию. НЕТ Создаётся впечатление, что касательно изначальной спецификации были реализованы не все реквестируемые пункты. ДА Выполнены не все требования к задаче. + Если попадаем в ситуацию, когда сильно не согласны с собеседником, не стесняемся взять таймаут. Сначала остыть, подумать и только потом отвечать. НЕТ Так никто не делает! Это же очевидно! Начинаю сомневаться в твоей квалификации! ДА Я не согласен. Вот почему: … + Стремимся быть скромными. НЕТ На этот вопрос тебе никто в компании не ответит! По крайней мере, лучше меня. ДА Тут я не уверен, давай разбираться. + Не используем обобщения. НЕТ Ты всегда делаешь эту ошибку. ДА Смотри, вот это место противоречит нашему код-гайду. + Не используем сарказм. НЕТ Если ты хотел внепланово отпраздновать Хэллоуин и напугать меня кодом, у тебя получилось. ДА К этому месту в коде у меня есть вопросы: … Правила для тех, кто проверяет код Первым делом разбираемся, зачем именно нужно рассматриваемое изменение в коде: исправить баг, улучшить пользовательский опыт, рефакторинг. Затем: + Рассказываем, в каких местах мы уверены, а в каких нет. + Следим за тональностью комментариев. Помним, что нейтральный тон может быть расценен как негативный. Везде, где уместно, используем позитивный тон. + Определяем способы упростить код, сохраняя при этом решение задачи. + Предлагаем альтернативные варианты, но считаем, что автор коммита уже рассматривал их. + Стараемся понять, как рассуждал автор коммита. + Не забываем хвалить удачные места в коде. + Чётко формулируем минимальные требования для успешного прохождения ревью, а также желательные, но не обязательные улучшения. + Ещё раз, стараемся быть позитивными! Правила для тех, чей код проверяют + Благодарим ревьюера за его идеи. + Не принимаем комментарии на свой счёт. Ревьюят наш код, а не нас лично. + Объясняем, почему выбрали то или иное решение. + Стараемся понять точку зрения ревьюера. + Отвечаем на каждый комментарий. + Если есть возможность, обсуждаем комментарии ревьюера лично. Это может сильно ускорить процесс. + После того, как ревью завершилось, а мы уверены в коде и его влиянии на проект — можем делать merge. Этот список принципов — чеклист по форме, но не по сути. С ужасом представляем себе человека, который методично идёт по всем пунктам: «Проследить за тональностью комментариев — сделано; постараться понять ход мысли автора — сделано; быть позитивным — сделано». Главная польза, которую могут дать эти принципы — передать дух, задать правильный настрой на процесс. А ещё зафиксировать именно наш опыт: что работает лучше, а что хуже — знаем, потому что пробовали. Чтобы пользоваться этими правилами, не обязательно помнить все пункты наизусть. Достаточно будет выучить одно мнемоническое правило: уважение друг к другу и польза для проекта. Все пункты списка — следствия из этих двух вещей. Авторы: команда CreatikSoft Активно помогали: Евгений Степченко, Project Manager Сергей Никитин, Frontend Engineer Предыдущая записьСледующая запись Экспресс-консультация 1. Наш специалист свяжется с вами в ближайшее время. 2. В рамках консультации уточним необходимую информацию для анализа вашего проекта. 3. Команда аналитиков и разработчиков подготовят оценку по вашему проекту. Получить консультацию

The post Чеклист для Code Review first appeared on CreatikSoft.