[2/2] 100 Principles of Game Design (100 принципов гейм-дизайна. Универсальные принципы разработки и решения проблем) (Рубрика #Design)

Продолжая рассказ про эту книгу с принципами дизайна (1 и 2), покажу еще примеры принципов и расскажу об источниках дополнительных знаний, на которые ссылаются авторы. Но начнем с принципов

1. Циклы обратной связи
Регулярный анализ и корректировка игровых процессов позволяют поддерживать баланс и динамичность игрового опыта. Циклы обратной связи могут быть положительными (усиливающими определенное поведение) или отрицательными (сдерживающими). Правильно спроектированные циклы обратной связи помогают поддерживать напряжение в игре, предотвращая как слишком быстрое доминирование сильных игроков, так и безнадежное отставание слабых. Понимание этих механизмов критически важно для создания справедливой и увлекательной игровой динамики.
2. Основной геймплейный цикл
Повторяемость и структурированность базовых игровых этапов создают фундамент для устойчивости и вовлеченности игрока. Основной геймплейный цикл определяет ключевые действия, которые игрок выполняет снова и снова в процессе игры. Хорошо спроектированный цикл должен быть достаточно простым для быстрого освоения, но при этом глубоким для длительного интереса. Он служит основой всего игрового процесса, и его качество напрямую влияет на общее впечатление от игры.
3. Дизайн опыта
Данный принцип фокусируется на создании уникальных и запоминающихся эмоций через продуманные визуальные и звуковые эффекты. Вместо простого набора механик и правил, современный гейм-дизайн рассматривает игру как целостный опыт, который должен вызывать определенные эмоции и состояния у игрока. Этот подход требует интеграции всех аспектов игры – от сюжета и визуального стиля до звукового сопровождения и игровых механик – для создания цельного и эмоционально насыщенного игрового опыта.
4. Повествование через окружение
Использование окружающей среды для передачи сюжетной информации позволяет создать глубину и атмосферность без излишней экспозиции. Этот принцип предлагает альтернативный подход к повествованию, отличный от традиционных диалогов и катсцен. Через тщательно спроектированные игровые локации, детали интерьера, записки, аудиозаписи и другие элементы окружения игроки могут самостоятельно собирать фрагменты истории, что повышает их вовлеченность и поощряет исследование игрового мира.

А вот упоминаемые в книге источники, оказавшие влияние на формирование принципов современного гейм-дизайна
1. Книга "A Theory of Fun for Game Design»", Раф Костер, 2004 год - основополагающий труд, объясняющий природу удовольствия от игрового процесса через призму когнитивной психологии и нейробиологии.
2. Книга "Frames of Mind: The Theory of Multiple Intelligences", Говард Гарднер, 1983 год - теория множественного интеллекта, адаптированная для понимания разнообразия игровых предпочтений аудитории.
3. Статья "Hearts, Clubs, Diamonds, Spades: Players Who Suit MUDs", Ричард Бартл, 1996 год и книга "Designing Virtual Worlds", Ричард Бартл, 2003 год - классификация игроков по Бартлу
4. Доклад "Why We Play Games: 4 Keys to More Emotion", Николь Лаццаро, 2004 год - модель "4 Keys 2 Fun"
5. Книга "The Art of Game Design: A Book of Lenses", Джесси Шелл, 2008 год - работа, повлиявшая на методы анализа игровых механик.
6. Концепция "The Laws of Occult Game Design", Дэвид Говард - без отдельной публикации
7. Книга "Homo Ludens", Йохан Хёйзинга, 1938 год - философское исследование игры как культурного феномена

#Games #Design #Architecture #Economics #Engineering

Postgres против MySQL: что решает выбор базы данных | Петр Зайцев (Рубрика #Engineering)

Посмотрел интересное двухчасовое интервью Петра Зайцева, создателя компании Percona. Такое ощущение, что вернулся в начало карьеры, когда особо еще не было облаков и все хвастались тем, как они свой Mysql готовят к высоким нагрузукам:) Ну а если серьезно, то Кирилл Мокевнин, автор подкаста, и Петр Зайцев за 2 часа успели обсудить кучу тем, среди которых

1. Эволюция и история развития баз данных и компаний
Ребята вспоминали истории Percona, MySQL, PostgreSQL, MariaDB, а также влияние крупных игроков (Oracle, Sun) на рынок и развитие экосистемы баз данных.
2. Бизнес-модели и монетизация open-source
Обсудили особенности бизнес-моделей Percona, MySQL, вопросы монетизации open-source-проектов, проблемы коммерциализации и поддержка клиентов.
3. Технические отличия и сравнение MySQL и PostgreSQL
Базово сравненили архитектуры, производительности, типов данных, масштабируемости, соответствия стандартам SQL, особенностей работы с большими данными и сложными запросами.
4. Влияние облачных технологий
Обсудили роль облаков (Amazon, Google Cloud, Яндекс.Облако), опыт миграций, плюсы и минусы облачных решений, вопросы доверия и безопасности, влияние санкций и переход на европейские облака.
5. Миграция между СУБД и связанные сложности
Привели примеры перехода с Oracle на PostgreSQL, сложности миграции крупных проектов, зависимость от типа приложения, риски и опыт успешных/неудачных миграций.
6. Рынок, конкуренция и экосистема баз данных
Описали рост рынка, появление новых игроков (Redis, MongoDB, InfluxDB), конкуренция между решениями, роль форков и коммерческих версий, а также поддержка множества СУБД для удовлетворения разных потребностей.
7. Роль и влияние крупных компаний и специалистов
Поговорили про влияние Oracle, Amazon, Google на рынок, формирование профессиональной элиты, обучение специалистов, создание монополий и альтернативных решений.
8. Технические аспекты и особенности работы с СУБД
Поговорили про движки баз данных, вспомнили MyISAM, а также InnoDB, а также как на этом поднялась Percona Server. Поговорили про особенности работы с транзакциями, блокировками, индексами, поддержка расширенных типов данных и языков программирования.
9. Проблемы безопасности, управления и надежности
Вспомнили примеры сбоев, хакерских атак, важность резервного копирования, меры по обеспечению безопасности и управления данными в облаке и on-premise.
10. Будущее рынка и тенденции развития
Обсудили темы разнообразия баз данных, появление специализированных решений (Vector Search, Redis), влияние разработчиков и облаков на выбор технологий, перспективы развития PostgreSQL и других СУБД.

В общем, я выпуск посмотрел с удовольствием:)

#Database #Engineering #Architecture #Management #Software #Data

Exclusive: the most-cited papers of the twenty-first century (Рубрика #Science)

Интересная статья от Nature, в которой авторы попробовали подсчитать самые цитируемые статьи 21 века. Точно подсчитать было довольно сложно, так как существует целая пачка ресурсов, что считают цитирования по своему, но авторы взяли взвешенный подход. Кроме того, в области computer science и ML довольно часто авторы сначала публикуют препринты, а потом эти же статьи публикуются по итогам конференций, в итоге, часто ссылки на препринт версии не учитываются при расчетах цитируемости основной статьи.

Из интересного можно отметить, что в 25 лучших статей попало много ML статей, вот их список с занимаемыми ими местами
1. Deep Residual Learning for Image Recognition (ResNet), (2016), He, K., Zhang, X., Ren, S., & Sun, J.
Эта статья описывает архитектуру ResNet, которая описывает архитектуру нейросетей с примерно 150 слоями - примерно в 5 раз больше, чем было принято ранее. Эта архитектура позволила преодолеть проблему затухания сигнала при увеличении числа слоев, что стало прорывом для развития глубокого обучения и последующих достижений в ИИ, таких как AlphaGo, AlphaFold и ChatGPT.
6. Random forests ,(2001), Leo Breiman
Эта работа представляет алгоритм машинного обучения, который существенно улучшил предыдущие методы ансамблей деревьев решений. В этой работе описан новый способ построения ансамбля: множество независимых деревьев решений обучаются на случайных подвыборках данных и случайных подмножествах признаков, а итоговое решение принимается большинством голосов (для классификации) или усреднением (для регрессии)
7. Attention Is All You Need, (2017), Ashish Vaswani, Noam Shazeer, Niki Parmar, Jakob Uszkoreit, Llion Jones, Aidan N. Gomez, Lukasz Kaiser, Illia Polosukhin
В этой статье исследователи из Google представили архитектуру Transformer, которая произвела революцию в обработке естественного языка и других последовательных данных. Главной инновацией стал отказ от рекуррентных нейронных сетей в пользу механизма self-attention (самовнимания), позволяющего модели определять важность каждого элемента последовательности относительно других и учитывать контекст на любом расстоянии.
8. ImageNet Classification with Deep Convolutional Neural Networks (2012), Alex Krizhevsky, Ilya Sutskever, Geoffrey E. Hinton
В этой статье описывалась архитектура AlexNet - глубокая сверточная нейронная сеть (CNN), которая совершила прорыв в компьютерном зрении, победив в конкурсе ILSVRC-2012 с ошибкой top-5 в 15.3% против 26.2% у ближайшего конкурента. AlexNet продемонстрировал, что глубокие CNN, обученные на больших данных, способны распознавать объекты с высокой точностью даже без ручной настройки признаков, заложив основы современного глубокого обучения
12. U-Net: Convolutional Networks for Biomedical Image Segmentation (2015), Olaf Ronneberger, Philipp Fischer, Thomas Brox
Эта статья представила революционную архитектуру для сегментации биомедицинских изображений, сочетающую кодирующий путь (свёрточные слои для извлечения признаков) и симметричный декодирующий путь (транспонированные свёртки для восстановления разрешения), соединённые skip-связями для сохранения пространственной информаци
16. Deep learning (2015), Yann LeCun, Yoshua Bengio, Geoffrey Hinton
Обзорная статья про глубокое обучение от корифеев этой темы
24. ImageNet: A large-scale hierarchical image database (2009), Jia Deng; Wei Dong; Richard Socher; Li-Jia Li; Kai Li; Li Fei-Fei
Статья описывает создание масштабной базы данных изображений ImageNet, организованной по иерархии WordNet. Цель проекта - собрать для большинства из 80 000 синсетов WordNet по 500–1000 полноразмерных и тщательно размеченных изображений, что обеспечивает десятки миллионов аннотированных примеров. Интересно, что в 8 статье AlexNet показывала свои топ-результаты как раз обучаясь на ImageNet.

P.S.
Кстати, если посмотреть на остальные топ-статьи, то там много статей про медицину в общем и рак в частности, а также про софт, который использовался для ведения исследований.

#Science #ML #AI #Software #Engineering

[1/3] BitsAI-CR: Automated Code Review via LLM in Practice (Рубрика #AI)

Интересная научная статья от ByteDance, создателя TikTok на тему автоматизированного code review с использованием GenAI. Интересно, что чуть раньше я уже разбирал как Google подходит к этому вопросу при разборе "Resolving Code Review Comments with Machine Learning" в трех частях: 1, 2 и 3. Но у ребят из ByteDance немного другой подход - они сделали систему, в которой LLM пишет на MR (merge requests) комментарии в code review, а у ребят из Google сам комментарий писал инженер, а LLM делало code suggest, который предлагал фикс, что соответствует этому комментарию. Но давайте посмотрим какие проблемы авторы из ByteDance пытались решить, создавая BitsAI-CR:
- Избавиться от трудоемкого узкого места в виде традиционного code review
- Устранить ошибки и непоследовательности в комментариях при code review

Вообще, тема использования LLM для code review плодотворна, но там есть проблемки, которые авторы учли и попробовали устранить (кстати, в списке ссылок больше 50 других научных статей, десяток из которых про code review)
1. Низкая точность и надёжность: многие LLM-решения генерируют неточные или нерелевантные комментарии, тратя время разработчиков.
2. Недостаточная практичность: текущие системы часто не дают полезной обратной связи, которую реально используют разработчики.
3. Отсутствие механизма постоянного улучшения: большинство решений не учатся на обратной связи пользователей и не эволюционируют со временем.

Для решения этих проблем авторы придумали архитектуру из двух частей, что сочетает высокоточный pipeline генерации комментариев к review и механизм data flywheel. Такой подход не только выявляет потенциальные проблемы в коде с высокой точностью, но и запускает цикл постоянного улучшения на основе реальной обратной связи от разработчиков. Интересно, что для генерации комментариев используется таксономия правил code review, где есть категории security vulnerability, code defect, maintainability and readability, performance issue.

Давайте заглянем в то, как устроен каждый из двух компонентов модели

Review Comment Generation Pipeline
Pipeline работает в четыре последовательных этапа:
1. Context Preparation: на этом этапе входные изменения кода структурируются для дальнейшего анализа. Изменения разбиваются на сегменты по header hunks, добавляются полные определения функций - это даёт LLM достаточно контекста для качественного анализа.
2. RuleChecker: это дообученная LLM, обученная на широкой таксономии из 219 правил review. RuleChecker выявляет потенциальные проблемы в каждом сегменте кода, классифицируя ошибки по типам: уязвимости, проблемы производительности, нарушения стандартов кодирования и др. На выходе - первоначальные комментарии к review.
3. ReviewFilter: этот слой верификации - ключевой механизм контроля качества, который фильтрует ложные срабатывания и галлюцинации RuleChecker. ReviewFilter - тоже дообученная LLM, использующая три паттерна рассуждений: Direct Conclusion, Reasoning-First, Conclusion-First. После тестов наиболее эффективным оказался Conclusion-First - он лучше всего балансирует точность и производительность.
4. Comment Aggregation: на этом этапе схожие комментарии группируются с помощью cosine similarity, чтобы не перегружать разработчиков дублирующей обратной связью. В каждой группе сохраняется один представитель.

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

#Software #AI #Engineering #Process #DevEx

[2/3] BitsAI-CR: Automated Code Review via LLM in Practice (Рубрика #AI)

Продолжаем рассмотрение интересного whitepaper о code review со второй части модели, а именно механизму data flywheel

Data flywheel — это системный подход к постоянному улучшению за счёт:
1. Annotation Feedback Integration: BitsAI-CR собирает и использует обратную связь пользователей для дообучения и улучшения датасетов.
2. Outdated Rate Measurement: введён новый метрик — Outdated Rate, который измеряет процент строк кода, изменённых после того, как BitsAI-CR их пометил. Это даёт объективную оценку того, насколько часто разработчики реально принимают предложения системы.
3. Dynamic Rule Adjustment: cистема постоянно корректирует правила review на основе точности и Outdated Rate, убирая те, что генерируют малоценные комментарии (низкий Outdated Rate при высокой точности).
Вместе эти компоненты создают цикл обратной связи, который шаг за шагом повышает качество code review на основе реального поведения разработчиков.

Авторы применили продвинутую стратегию обучения и оптимизации BitsAI-CR, включающую несколько ключевых элементов:
- В качестве базовой модели выбран Doubao-Pro-32K-0828 (собственная LLM ByteDance), что обусловлено требованиями безопасности и приватности данных. Размер последовательности выбран 8192 токена, так как 99% примеров review укладываются в этот лимит.
- Для дообучения RuleChecker и ReviewFilter использовалась техника LoRA (Low-Rank Adaptation)
- Также они учились на основе подробной таксономии правил code review, что дало
-- Структурированную основу для выявления и классификации проблем в коде
-- Системный сбор и разметку данных для обучения
-- Чёткие критерии для оценки качества системы
- Такой подход показал себя эффективным: BitsAI-CR, обученный на таксономии, достиг точности 57.03%, тогда как версия без таксономии (на случайных человеческих review) — лишь 16.83%.

Для оценки модели авторы новую метрику - Outdated Rate, измеряющий долю строк кода, изменённых после комментариев BitsAI-CR. Это позволяет:
1. Автоматически оценивать реальное влияние комментариев на практике
2. Понимать, насколько предложения системы действительно внедряются разработчиками
Такой подход закрывает недостатки традиционных метрик точности, которые требуют ручной разметки и не отражают реальную пользу для бизнеса.

При внедрении в production система показала впечатляющие технические результаты
1. Точность (Precision): Без таксономии и двухступенчатой архитектуры точность была около 25%. После внедрения этих элементов точность RuleChecker выросла с 27.9% до 62.6%, а ReviewFilter — с 35.6% до 75.0%. Это доказывает эффективность двухступенчатой архитектуры в снижении ложных срабатываний.
2. Outdated Rate: Для языка Go (основного в ByteDance) Outdated Rate вырос до 26.7% через 18 недель оптимизации. Для сравнения, у людей этот показатель колеблется между 35-46%. Постепенное приближение к человеческому уровню — свидетельство практической ценности BitsAI-CR.

Кроме того, BitsAI-CR быстро стал частью процесса разработки:
1. Аудитория: Более 12 000 Weekly Active Users (WAU), свыше 210 000 Weekly Page Views (WPV) — система интегрирована в рабочий процесс.
2. Retention: Retention на второй неделе — 61.64%, через восемь недель — около 48%. Это первый опубликованный бенчмарк retention для подобных инструментов code intelligence.
3. Оценка пользователей: В опросе (N=137) и интервью с экспертами (N=12) 74.5% (102/137) пользователей подтвердили пользу и эффективность BitsAI-CR.
Все эксперты отметили пользу BitsAI-CR, указав на пожелания по скорости, кастомизации и поддержке языков.

Авторы обозначили чёткие планы по развитию BitsAI-CR:
1) Расширение языковой поддержки до всех языков программирования, а не только пяти основных.
2) Улучшение контекстного понимания. Сейчас BitsAI-CR анализирует код на уровне функций с ограниченным контекстом. В планах — кросс-файловый анализ (cross-file review), чтобы находить проблемы, связанные с архитектурой и зависимостями между файлами.
3) Постоянное развитие и доработки системы

#Software #AI #Engineering #Process #DevEx

Precision и recall на пальцах (Рубрика #ML)

Буквально вчера мы разбирали whitepaper про подход ByteDance к code review (1, 2 и 3), где ребята отдавали предпочтения precision и жертвовали recall при проектировании своего решения. Precision (точность) и recall (полнота) - это две важные метрики для оценки качества моделей классификации, особенно когда классы распределены неравномерно или когда важно минимизировать определённые ошибки. Но что это значит на простом языке? Давайте обсудим.

Precision (точность) отвечает на вопрос: из всех объектов, которые модель определила как положительные, сколько действительно являются положительными?
Формула выглядит так
Precision = TP / (TP + FP), где
- TP (True Positive) — правильно определённые положительные объекты,
- FP (False Positive) — ошибочно определённые как положительные объекты
Проще всего объяснить на примере Васи, что сторожит овец и кричит "Волк", когда думает, что пришел волк. Precision показывает, как часто, когда Вася кричал "Волк!", волк действительно приходил. Если Вася часто путает собаку с волком и зря поднимает тревогу, precision будет низкой

Recall (полнота) отвечает на вопрос: из всех реально существующих положительных объектов, сколько модель нашла?
Формула для recall похожая, но не совсем
Recall = TP / (TP+FN), где
- FN (False Negative) — положительные объекты, которые модель пропустила
Продолжим пример Васи с овцами. Recall показывает, насколько Вася внимателен: из всех случаев, когда волк действительно приходил, сколько раз Вася это заметил и крикнул "Волк!"? Если Вася часто спит и пропускает волка, recall будет низкой

Обычно между этими метриками есть компромисс: если повысить одну, другая может снизиться. Например, если модель "перестраховывается" и помечает мало объектов как положительные (только когда уверена), precision будет высокой, а recall — низкой. Если помечает почти всё как положительное, recall будет высокой, а precision — низкой

В итоге, у нас получается
-- Вася часто зря кричит "Волк!", даже не будучи уверен -- Precision низкая: много ложных тревог -- Recall высокая: почти всегда замечает
-- Вася редко кричит, только если стопудово уверен -- Precision высокая: почти не ошибается -- Recall низкая: часто пропускает волка

В итоге, в случае с ассистентом в code review не выгодно слишком часто кричать "Волки", так как в этом случае инженеры просто перестанут обращать внимание на помощь code review ассистента:)

#ML #PopularScience #AI #Engineering #Software

Code of Leadership #37 - Interview with Borish Chernysh about frontend architecture and reliability (Рубрика #Management)

В очередном выпуске подкаста ко мне пришел интересный гость, Борис Черныш, с которым мы обсудили фронтовые архитектуры и вопросы обеспечения надежности клиентских приложений. Борис руководит направлением развития веб платформ в Т-Банке и занимает роль CRO (chief reliability engineer) в управлении разработки клиентских интерфейсов, где находятся наша платформа веба, мобилки и API.

За час мы успели обсудить следующие темы
- Знакомство с гостем, школьные и университетские годы, выбор профессии
- Начало карьеры: первая работа и фриланс
- Переходы между компаниями и опыт в Тинькофф
- Преодоление трудностей и рост до тимлида
- Развитие мониторинга, внедрение дежурств и выстраивание процессов
- Организационные изменения и создание SRE-команды
- Архитектурные изменения: микрофронтенды, Mobile First
- Роль Chief Reliability Officer, баланс между ролями инженера и технического менеджера
- Рекомендации по развитию: самообразование, книги, фундаментальные знания

Рекомендации Бориса для дополнительного изучения
1) Мышление и управление собой
- Левенчук Анатолий «Системное мышление», книга которая помогла Борису научиться превращать большие и сложные проблемы в несколько проблем поменьше и попроще, в дополнение к книге рекомендую сайт https://untools.co/ и редактор mind map - xmind;
- Максим Дорофеев «Джедайские техники». Это книга, которую Борис рекомендует прочитать не меньше трех раз и желательно с разбегом в пол-года год. Результат будет стоить потраченных усилий.
2) Инженерка
- Robert Hammer «Patterns for fault tolerant software», Борис прочитал ее чёрти когда в издании 2007 года, и скорее всего уже есть более актуальная замена, но для него это был просто трамплин в мир отказоустойчивости;
- Martin Kleppmann «Designing Data-Intensive Applications». Банально, но факт, эту книгу Борис рекомендует не только купить, но и прочитать всем инженерам, разработчикам, SRE, QA. Я как-то уже рассказывал об этой книге
3) Управление другими
- Алексей Пименов «Канбан. Базовая практика». По мнению Бориса, это очень понятно написанный и емкий гайд по тому что такое канбан и как им пользоваться, рекомендую всем как чтение на выходные. Я как-то уже рассказывал об этой книге
- Алексей Иванов, Света Шедина «Аутентичная коммуникация». Чем выше позиция, тем больше приходится обсуждать что-то и договариваться. Книга позволяет видеть паттерны во взаимодействии и переводить разговоры в конструктивное русло.

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

#Software #Engineering #SRE #Management #Architecture #Processes #Devops #DevEx

[1/3] Quality Metrics in Software Architecture (Рубрика #Architecture)

Интересная обзорная статья про архитектуру софта, в которой авторы систематизировали и структурировали метрики (metrics) для оценки качества архитектуры (software architecture). Они сфокусировались на метриках, которые можно применять только к архитектурному описанию (architecture-only metrics), без необходимости анализа исходного кода или реализованной системы. В результате проведённого систематического обзора литературы (Systematic Literature Review, SLR) был создан каталог из 52 метрик и 41 атрибута качества (quality attributes), сгруппированных по 8 основным характеристикам качества (quality characteristics) согласно международному стандарту ISO/IEC 25010:2011. Для практического применения этот каталог реализован в виде модели и фреймворка, поддерживающего визуализацию и расширение набора метрик. Сам код доступен на Github, там же доступна визуализация самой модели с метриками, атрибутами и их кластеризацией как статической, так и динамической.

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

Если говорить про модель авторов, то из анализа литературы они собрали фреймворк, что включает следующие компонены
- ArchitecturalQualityModel - корневой элемент, объединяющий все остальные сущности модели.
- QualityElements - элементы качества, которые бывают трёх типов:
-- Metric - конкретная метрика для измерения качества архитектуры
-- QualityCharacteristic - глобальная характеристика качества (например, reliability, maintainability)
-- QualityAttribute — атрибут качества, связанный с одной из характеристик
- QualityRel — отношения между элементами качества, например, какая метрика измеряет какой атрибут
- ResearchContributions — ссылки на научные публикации, в которых определены или предложены элементы или связи.

Каталог организован по 8 характеристикам качества из ISO/IEC 25010:2011 (интересно, что в 2023 году вышло обновление этого стандарта)
- Функциональная пригодность
- Уровень производительности
- Совместимость
- Удобство использования (юзабилити)
- Надёжность
- Защищённость
- Сопровождаемость
- Переносимость (мобильность)
Для каждой характеристики выделены соответствующие атрибуты качества и связанные с ними метрики. Например, для Maintainability это Cohesion, Coupling, Complexity и др.

В следующем посте рассказ о том, как авторы подошли к методологии и реализации своего исследования.

#Architecture #Metrics #Software #Engineering #SystemDesign #Management

JVM Day от Т-Банка (Рубрика #Software)

В конце лета пройдет очередная конференция про JVM технологии от Т-Банка. На конференции будут обсуждаться инженерные практики, сложные кейсы, нестандартные решения. В этом году будут три секции: Java, Scala и Backend. В текущий момент открыт прием заявок (call for papers), причем приветствуются следующие темы для каждой секции
- Java: инструментарий и тулинг, грядущие возможности Java и Kotlin, Java Enterprise, качество и организация кода, JVM, технологии в ретроспективе и истории факапов.
- Scala: новые фичи языка и их использование, подходы к разработке, инструменты, системы эффектов (Cats Effect, ZIO, Kyo), обзор и сравнение библиотек.
- Backend: опыт внедрения архитектурных подходов и практик, микросервисная архитектура, надежность и доступность, инфобез, инфраструктурные оптимизации, AI в разработке, устаревающие технологии и автоматизация тестирования.

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

#Software #Engineering #Architecture