UML умер, но никто этого не заметил?

Один знакомый сейчас идет работу в Европе. Он продакт, CPO. Вы, возможно, слышали, а может и сами сталкивались с поисками работы вне России — внезапно сейчас в ИТ довольно сложно. Очень много соискателей, очень много интервью проходит впустую.

Вот и он так же: ходит на множество собеседований. И вот на одном интервью заходит речь про UML. Соискатель напрягается, и аккуратно выясняет — а не российские ли корни у компании? Оказывается, да, основатели из России, программисты, учились в российских институтах. Потому что никто, кроме российских программистов, UML при разработке продуктов давно уже не использует 😂
(Ну, по крайней мере, на верхнем уровне проработки. Такой опыт у моего знакомого.)

Как, в его опыте, обычно устроено управление продуктовыми требованиями:
🔸 Job Stories для формулировки продуктовой проблемы (кажется, фактически этот формат победил User Stories во многих проектах).
🔸 сценарии работы пользователя (не в виде юскейсов, а менее формально)
🔸 критерии приемки в виде BDD-сценариев.

Возможно, UML появляется где-то внутри в команде разработки — в основном в виде диаграмм классов, последовательности/активности и иногда состояний. Он этого не знает, это внутренний язык общения разработчиков друг с другом.

Слухи о смерти UML циркулируют ещё с 2010-х годов. Из последнего — много обсуждений вызвала статья Эрнесто Гарбарино 'Has UML Died Without Anyone Noticing?'.
Впрочем, встречаются и мнения, что "UML не мог умереть, потому что он никогда не был живым".

Интересными мне показались два поинта в статье:

1. UML — это формальный графический язык. Элементы в нём зафиксированы в стандарте. Но бизнес-заказчикам такой язык не нужен! Им нужны диаграммы, которые показывают то, что им нужно увидеть здесь и сейчас. И если на диаграмму нужно добавить описание персон — нужно его добавить. Возражение "в UML это не предусмотрено" не принимается.

2. А проиcходит так потому, что на организационном уровне разработка программных систем больше не является инженерной практикой. Где-то в глубине — да, разработчики всё ещё являются инженерами (а ещё более ими являются инженеры по надежности, которые даже иногда используют тервер и математическое моделирование!), но на уровне бизнеса — больше нет.

Принцип fail fast, fail often (and fail cheap) убил практику инженерии требований, бизнес-анализа и проектирования. UML просто умер вместе с ними. Программирование фокусируется на том, чтобы быстро накодить что-то, а потом быстро переделать. Инженерам нужен язык для общения друг с другом, для проектирования и анализа моделей, а кодерам — нет, им нужны фреймворки, библиотеки, low-code и copilot.

В прекрасном новом мире нет бизнес-анализа и детализированных моделей бизнес-процессов. Всё очень легковесно: DDD и Event Storming вместо сложных моделей, JTBD для интерфейсов, C4 для архитектуры.

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

А вы применяете UML? Насколько часто, и что именно из него?

Пост про "смерть UML" оказался очень неоднозначным и спорным. Поэтому я бы хотел провести опрос, чтобы иметь какие-то количественные оценки. В 2014 году исследователи из Трирского университета проводили опрос про использование диаграмм, эскизов и набросков при разработке и проектировании ПО в Германии и США. Я взял их опросник и перевел на русский: https://forms.gle/zU7PncWsWc9u3cXZ6

Я был бы вам очень благодарен, если бы вы прошли его. Это займет буквально 5-7 минут. В опросе у германских исследователей приняло участие 350 респондентов, и я надеюсь, мы сможем собрать не меньшее по мощности исследование. В результате мы точно узнаем — кто и как использует диаграммы при разработке ПО.

Если у вас есть возможность — отправьте опросник своим коллегам и знакомым, в том числе программистам; так мы обеспечим представительство большего числа профессий в ИТ. Результаты опубликую в канале. И тогда мы узнаем — кто, где и как использует диаграммы и UML!

Промежуточные итоги по опросу:

164 ответа (надеюсь, наберем ещё)
47% — системные аналитики, 24.4% — архитекторы, 16.5% — бизнес- или фуллстеки.
Почти все из средних (37,2%) или крупных (48,8) компаний, почти все из России.
По отраслям: 38,4% — финтех(!), 11,6% — ритейл, 11% — госпроекты, 9,1% — автоматизация производства.
Проекты в основном крупные: от 11 человек и выше (суммарно 58,5%), и 33,5% — от 4 до 10 человек.

Теперь самое интересное:
🔹 67,1% составляли диаграммы буквально на днях или в этом месяце, 10,4% — прямо в течение дня, когда проходили опрос.
🔹 88,4% вносили несколько изменений в диаграмму после создания(!)
🔹 Суммарно потраченное время на диаграмму: несколько часов (43,3%) или даже дней! (11,6%). За час уложились 34,8%.
🔹 При этом в основном над диаграммой работает 1-3 человека (51,2% работают в одиночку).
🔹 Срок жизни диаграммы в основном около года (34,8%) или больше (25,6%), и здесь впервые значимая величина ответов "не знаю" (10,4%)

Диаграммы в основном скорее формальные, но не идеально формальные.
Чисто UML-ных диаграмм около трети, с некоторыми элементами — больше половины. Совсем без UML — 18,4%

Для чего рисуют (только ответы >50%):
➡️ Зафиксировать требование
➡️ Презентовать решение
➡️ Объяснить задачу
➡️ Спроектировать архитектуру
➡️ Проанализировать требования

Что чаще всего описывает диаграмма:
➡️ Архитектуру
➡️ API / интеграцию

Понятно, что с большим отрывом лидирует Sequence Diagram: более 70% ответов, следующие за ней — Use Case (45,7%) и State Machine (43,9%). Совсем не используют UML 6,7%.


Средний возраст респондентов — 35 лет, средний стаж — 5 (правда, есть выбросы на 20, 25 и 30 — видимо, на таких сроках уже пятилетками считают, детали смазываются 😂).

Корреляции показателей пока не считал, там должно быть интересно.

Ещё очень интересные комментарии — спасибо огромное всем, кто развернуто написал!


В общем, что хочу сказать — пока каких-то крупных инсайтов нет, но что бы я выделил:

⭐️ Большинство аналитиков рисуют диаграммы, но многие не для того, чтобы разобраться или что-то спроектировать, а потому, что в документации есть такой раздел. Некоторые даже не знают, куда эта документация дальше пойдет. Такие дела.

⭐️ UML жив, тут даже сомнений нет. Но жив он частично. И используется совсем не так, как был придуман. От всего UML осталась диаграмма последовательности (и она ого-го как используется!), диаграмма вариантов использования (вот это меня удивило, думал, её мало кто использует) и диаграмма состояний. При этом сиквенс в основном фиксирует уже спроектированное решение — тут, конечно, нужен корреляционный анализ, но пока кажется это так.

⭐️ С другой стороны, почти 20% живут без всякого UML, и им норм.

⭐️ Лично меня удивила популярность диаграммы юскейсов — правда так много людей её используют? А зачем?

В чём результаты опроса сошлись с экспертами индустрии:
Sequence diagrams, the only good thing UML brought to software development. Это статья от создателя mermaid.js. Там и про смерть UML с разных позиций, и про пользу сиквенсов, и про то, как их использовать. С цитатами типа "The reward of the clarity of sequence diagrams is worth the pain and boredom of learning all the others at university" и "Sequence diagrams are the only type of diagrams I use anymore."

Статья классная, попробую перевести её, как будет время.

А итоговый вывод: UML — как латынь для некоторых наук. Мёртв-не мёртв, а лучше знать хотя бы основы и понимать, как его правильно применять сейчас. Lingua Franca для разработки.

Хм. Почему-то отвалился чат. Если хотите обсудить диаграмму робастности — комментируйте это сообщение.

Что я делаю с ChatGPT прямо сейчас (и это выглядит как чертова магия!)

В ChatGPT теперь можно вставлять файлы и скриншоты. И если вставить скриншот таблицы, то можно попросить сделать SQL-стейтмент для создания этой таблицы в БД, и INSERT INTO со всеми значениями из таблицы!!!1

Скреппинг данных никогда не был таким простым.

Upd: это мне в бесплатный аккаунт раскатили модель 4o, возможно, вы про неё слышали. Это сейчас самый топ, она по всем показателям пока впереди других LLM.

Как правильно отмечают в комментариях к посту про  Robustness Diagram, в UML её нет отдельно, потому что её можно сделать, например, из Communication Diagram.

Ранее она называлась Collaboration — как, собравшись вместе, части системы решают задачу. В конце концов, это просто объекты и стрелочки. Такую диаграмму можно и сейчас собрать в каком-нибудь PlantUML, хотя её нет в списке диаграмм, которые он поддерживает. Но стереотипы для Entity, Control и Boundary есть, и стрелки тоже.

Забавно, что Ивар Якобсон в расширении UML, описывающем Entity-Control-Boundary подход — у него он назывался Objectory — имел в виду скорее диаграмму классов. Собственно, он ведь какую задачу решал? Как правильно выявить структуру классов в приложении при использовании объектно-ориентированных языков. Это был 1992 год, ОО-языки уже появились, а методологии их применения — ещё нет. И дискуссия про пользу ОО-подхода против структурированного программирования стояла очень остро.

Ивар Якобсон и придумал Use Case'ы, как способ проектирования структуры классов. Методически это выражалось как последовательность:
1) реестр юскейсов (взгляд на систему с точки зрения задач пользователя) — диаграмма юскейсов;
2) шаги юскейса, и необходимые для них интефейсы, сущности и логика — диаграмма устойчивости;
3) классы, реализующие выявленные интерфейсы, сущности и логику — диаграмма классов.

Для своего времени это была прорывная идея, так как адепты ООП всё время твердили, что классы — это отражение объектов реального мира, и строить их нужно исходя из модели предметной области, не задавая вопроса, что с ними будет делать пользователь.

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

Разговоры по объектно-ориентированное программирование или проектирование сейчас, наверное, не так уж актуальны, но те же идеи на более верхнем уровне присутствуют в DDD и микросервисах.

Вот, например, идея с разбиением архитектуры на элементы с разной скоростью изменения. Что-то может меняться, что-то остаётся. Это и обеспечивает устойчивость, робастность.

Я долго задавался вопросом — почему диаграмма робастности? Ведь в статистике, электротехнике, инженерии и ML робастность — свойство сохранения работоспособности при резких и странных изменениях внешних параметров (выбросы, помехи). Так вот потому и робастности, говорит Якобсон: свойство системы сохранять работоспособность и целостность при поступлении неожиданных и странных требований!

Пришло от заказчика дикое, но неизбежное требование — а мы уже готовы! У нас архитектура так построена, что для дикого требования поменять-то нужно в одном месте небольшой сервис, ну может в двух. И работаем дальше! Система устойчива к выбросам и взбрыкам заказчика.

Сколько информации в ваших требованиях? Сложный пост с математическим уклоном.

Задача аналитика — снизить неопределенность при проектировании системы, чтобы выйти на ограниченный набор возможных решений. Важное слово здесь — "ограниченный", потому что чем больше неопределенность (непонятно, что нужно), тем больше вариантов решений. Фактически, речь идёт об энтропии — числе способов, которыми можно расположить и связать компоненты системы.

А это напрямую связано с количеством информации, описывающей систему. Не сильно вдаваясь в математические модели, можно сказать, что энтропия — это разница между новой информацией, содержащейся в сообщении, и хорошо известной информацией (о которой, может, и говорить-то не стоит). Например, хорошо известно, что любая сущность в системе должна быть создана и предъявлена/прочитана/использована. С большой вероятностью она должна быть удалена или архивирована. С некоторой вероятностью — изменена. Это обычный CRUD, которым можно контролировать полноту, но который почти ничего нового не сообщает об устройстве системы: можно было бы просто перечислить список сущностей, и завести CRUD для каждой. А вот когда мы начинаем задавать вопросы — когда и кем создается сущность? кому, когда и для чего её показывать? зачем и кто её изменят? — мы можем извлечь дополнительную информацию, передать в требованиях что-то, что не очевидно с самого начала. Таким образом снизив энтропию — уменьшив количество вариантов и рассказав что-то интересное.

Интересное нам нужно, чтобы можно было выбирать обосновано. Если все варианты решений одинаковы — энтропия максимальна, это хаос, ну или нормальное распределение — верно нечто среднее. Такую картину мы получим, если требования собраны случайным образом, бессистемно: будет средняя система, непойми что, информации мало. Если вариантов нет и всё очевидно — энтропия будет минимальной или нулевой, но и информации никакой нет — нечего решать.

Мы обычно находимся в интересной промежуточной ситуации, когда расхождение между очевидным и хаотичным велико. А значит, нужно много информации для снятия неопределенности. Поэтому требования должны быть неожиданными! Если вы читаете требования, и всё выглядит усредненно-понятным, значит, требования не передают много информации. То ли система очень простая (нет), то ли работа аналитика выполненная так себе.

Требования должны быть неожиданными! И требования должны быть разными! Помните, как работает архиватор? Он выбирает одинаковые последовательности и заменяет их одним символом — повторение не несет информации. Если вы видите, что в ваших требованиях постоянно что-то повторяется: формулировка, обоснование, решение — остановитесь и задумайтесь. Не пропускаете ли вы здесь важную информацию? Стоит покопать поглубже, и получше разобраться? Или это хорошо известная информация? тогда и повторять её не имеет смысла, нужно упаковать в более компактный вид.

А сколько у вас в документе неожиданных требований? Знаете, как в шахматной нотации ставят ! и !! и иногда !? Хороший ход, отличный ход, и неожиданный ход (возможно, ловушка).

Скольким требованиям в документе вы может поставить такие значки?

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

А вот что меня натолкнуло на написание предыдущего поста. Это из таблицы с бизнес-требованиями, столбец с обоснованием требования.

Фактически, ответ на вопрос "Зачем мне, как <роли> это нужно?". Это работа аналитика-стажера, но я видел такое и у штатных аналитиков. Это мощный сигнал! Если вы видите такое — это повод разобраться, что тут происходит. Простое повторение не несет новой информации. Если несколько требований нужны для одного и того же — может быть, это одно требование и оно зря разбито на несколько? А может быть, обоснование взято слишком высокоуровневое, пропущен уровень один рассмотрения.

В любом случае, так быть не должно, это недоработка.

Я изучаю довольно много информации, в основном статей: научных и постов на сайтах. Далеко не каждая статья становится поводом к посту, и даже наоборот — когда я пишу пост, сначала возникает идея, а потом я ищу материалы. Ну и просто вкидывать в канал ссылки мне не кажется правильным, тут в основном мои персональные мысли.

Но если вам вдруг интересно, что мне интересно и что я читаю каждый день — я создал отдельный канал https://news.1rj.ru/str/yksdailylinks.

Там как раз наоборот — будут только ссылки с небольшими комментариями. Возможно, что-то их этих ссылок когда-нибудь превратится в отдельный пост. А какие-то ссылки будут дополнениями к посту в основном канале.

В общем, если вам вдруг любопытны ссылки от меня — welcome!

Я редко делаю репосты, но тут просто огненная тема! Ну и Киру в принципе рекомендую, если интересуетесь процессами найма и HR.

Для аналитиков, о чем можно рассказать, помимо примеров в посте, и что меня бы, например, интересовало при собеседовании аналитиков (кстати, меня, если что, можно звать на собеседования, чтобы оценить кандидата):

⭐️ пример автоматизации бизнес-процесса или отдельной функции (сквозное описание: от выявления требований до технических решений и тестирования, если было);

⭐️ пример участия в проектировании технической архитектуры (или выбора способа реализации, выбора готового решения с учетом технических требований);

⭐️ пример задачи описания требований для проектирования интеграции систем или API;

⭐️ пример решения какой-то сложности в проекте — когда было непонятно, что делать, или заказчик не мог сформулировать требования, или когда требования были противоречивые; в общем — когда вы пришли и поправили всё, спасли бизнес и/или команду разработки;

⭐️ пример применения какой-то техники бизнес- или системного анализа (например, того же DDD или Impact Mapping) — с обязательным указанием, в чем была польза, в чем положительный эффект;

⭐️ пример организации управления требованиями: как фиксировали, как согласовывали, как управляли версиями, как передавали в работу, как принимали выполненную работу.

В идеале, всё это нужно раскладывать по методу STAR: Ситуация — Задача — Действие — Результат, прямо так и рассказывать. Я рекомендую при подготовке к интервью составить себе несколько таких примеров, расписанных по STAR, заучить и при случае вставлять. Рекрутеры сами по этому STAR работают, им зайдет. (то есть, если вы нанимаете людей, вы из спрашивать можете в той же логике!)

Как вариант, можно использовать метод PARLA: Проблема — Действие — Результат — Опыт — Применение. Последние два — это Learned и Applied: что вы вынесли из этой ситуации, чему научились, и как теперь это применяете. В принципе, даже без задачи подготовки к собеседованию это хорошие вопросы для ретроспективы любого проекта или его этапа.

Главное слово кандидата на собеседовании: «НАПРИМЕР»

📌 Никто не телепат. К сожалению, если вы не будете приводить примеры из своего опыта, нанимающий менеджер не сможет оценить, насколько вы действительно реализовывали те задачи, про которые говорите.

Сравните:

❌ Я закрывала сложные вакансии быстро и качественно.

✅ Я закрывала сложные вакансии быстро и качественно.
Например, однажды нам в компании срочно потребовался ещё один разработчик баз данных, а подходящих кандидатов на рынке не было, сроки поджимали. В итоге я лично опросила всех имеющихся в команде разработчиков баз данных и попросила рекомендаций на их бывших коллег, получила контакты 10 кандидатов, с каждым связалась и нашла троих, кто был готов не только рассмотреть нашу вакансию, но и выйти в короткие сроки. Всех трёх мы отсобеседовали за 2 дня, выбрали одного, который вышел сразу после согласования оффера. Весь процесс занял у меня неделю.

📌 Примеры нужны для иллюстрации каждой компетенции или ключевого тезиса, которую вы презентуете работодателю.

Пример:

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

✅ Я откликнулась на вашу вакансию, потому что мне очень нравится ваш банк, я давно хотела работать в финтехе, потому что у вас сложные и интересные задачи.
Например, я вижу в вашей вакансии, вы решили внедрить Confluence в качестве единой базы знаний. У меня есть похожий опыт в предыдущей компании, где я, в качестве бизнес-аналитика, помогала внедрять эту систему в команду из 3000 человек. Я хорошо знаю плюсы и минусы этой системы, например, у Confluence есть проблемы с производительностью и я знаю, как их решать.

📌 Любое утверждение становится весомее и понятнее, если вы подкрепляете его примером.

Например:

❌ Что я больше всего не люблю в работе? Когда внутренний заказчик возвращается с правками 🙁

✅ Что я больше всего не люблю в работе?
Расскажу пример: мы работали как внешний подрядчик и я, как проджект, очень много внимания уделил брифингу клиента, выявлению потребности и формированию полного ТЗ, которое полностью устроит клиента. Каждые 2 недели мы сверялись с клиентом по процессу, чтобы сразу же выявлять проблемные места. Всё шло гладко, мы резво двигались по плану, клиент вносил минорные правки и мы уже подошли к финалу проекта. И тут, когда до дедлайна оставался месяц, на стороне клиента поменялся руководитель, который остановил весь процесс, а потом кардинально поменял ТЗ и потребовал, чтобы мы уложились в изначальные сроки. Я очень не люблю такие ситуации. Хорошо, что я внимательно документировал каждый шаг и мы были документально защищены от такой ситуации. В итоге, я смог наладить контакт с новым руководителем, обсудить с ним его пожелания и наши возможности. Мы сформировали новый план действий и смогли реализовать то, что клиенту было необходимо.

👉 Быстрый совет: напишите на бумажке слово «НАПРИМЕР», приклейте возле экрана на время собеседования, чтобы почаще использовать это слово и подкреплять свои слова наглядными примерами 🙏

Опубликовали статью по мотивам выступления на Flow'2023 (вот тут в формате видео https://www.youtube.com/watch?v=HzynqWGKehQ)

Опубликовали статью Юрия Куприянова на тему «Скрытая работа аналитика по проектированию систем»

В этой статье рассказано о том:
— как системные аналитики незаметно для себя могут принять проектное решение при анализе требований
— где проходит грань между требованиями и проектными решениями
— что такое скрытая работа аналитика по проектированию
— какие компетенции развивать системному аналитику, чтобы проектные решения были качественными.

Статья будет полезна системным аналитикам уровня junior и middle

Содержание:
1. Что такое системный анализ
— Парадокс системного анализа
— Требования вместо системы
— Граница требований и проектных решений
2. Проблемы требований к ПО
— Существуют ли требования?
— Иллюзия требований к ПО
— Рекомендации по работе с требованиями
3. Компетенции аналитика в проектировании
— Проектирование взаимодействие пользователя с системой
— Проектирование хранения данных
— Проектирование интеграций, взаимодействия с внешними системами
— Архитектура системы
4. Что делать системному аналитику? Переквалифицироваться в проектировщики или в архитекторы?

Почитать можно тут

Если бы Ивар Якобсон создавал диаграмму устойчивости сейчас, он бы назвал её "диаграммой антихрупкости". Звучит модно, не то что какая-то там робастность!

На самом деле нет. Термин "антихрупкость" (antifragile) ввел и раскрутил в одноименной книге Нассим Талеб, трейдер и риск-аналитик (до этого он так же раскрутил термин "черный лебедь"). И в книге он много пишет об отличиях антихрупкости от устойчивости: устойчивость — это способность выдерживать шоковые воздействия и восстанавливаться после них, а антихрупкость — не просто восстанавливаться в то же состояние, а становиться лучше.

Как это обеспечить в реальности? Система должна иметь возможность изменять своё поведение без радикальной перестройки внутренней структуры. То есть, структура системы должна обеспечивать возможность таких изменений. Например, один из вариантов — избыточность. Мы почти всегда боремся за отсутствие избыточности и дублирования (принцип DRY), но в случае потенциальной высокой изменчивости среды это может выйти боком (например, см. заметку про это в блоге Гугла).

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

При этом часть функций системы может отмереть, перестать использоваться. А часть — соединиться в другой последовательности для выполнения задачи в изменившихся условиях. Это как раз позволяет проследить диаграмма устойчивости — можно ли соединить её элементы (сущности, контроллеры, интерфейсы) другим способом? На этот вызов отвечает (микро)сервисная архитектура. Для этого нужен HATEOAS с набором ссылок в REST. А жестко зафиксированный сценарий юскейса наоборот мешает.

Сюда же относятся различные средства мониторинга, автоматические размыкатели и балансировщики. У аналитиков есть проблема: смотреть на сценарий юскейса, как будто это единственный экземпляр юскейса в системе. На самом деле почти все интересные системы сейчас многопользовательские, и каждый раз имеет смысл подумать, что будет, если много экземпляров юскейса выполняется параллельно в одно и то же время. Опять же, на диаграмме устойчивости это можно отметить: сколько экземпляров контроллера запущено (и какая очередь перед ним может возникнуть), есть ли конкурирующие обращения к одной и той же сущности. В антихрупкой системе всё это под мониторингом с цепями обратной связи, то есть регулируется само в положительную сторону, и останавливает каскад ошибок при развитии ситуации в отрицательную сторону. На какой диаграмме можно наметить точки мониторинга?..

Талеб также описывает "стратегию штанги", которая рекомендует фокусироваться только на супер-безопасных выборах (безрисковых) и на супер-рискованных (но потенциально приносящих большой эффект), убирая середину и сбалансированные по риску выборы. Это уже к вопросу про выбор фич. Не нужно делать что-то среднее — нужно прокачивать то, что не меняется и гарантировано приносит пользу, и что-то безумное, что скорее всего зафейлится, но если взлетит — окупит предыдущие фейлы. Но это уже тема для отдельного поста.

Пост по заявкам читателей (да, так тоже можно!) про названия.

Тема-то актуальная, регулярно в чатах кто-нибудь спрашивает.

Итак, мы проектируем системы и даём названия разным элементам.
В основном это:
* таблицы в базах данных
* поля в таблицах
* индексы, ограничения и бизнес-правила
* эндпоинты API
* поля в JSON
* названия файлов

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

Что же у нас с рекомендациями? Удивительно, но они разные :) Вот какие вопросы обычно обсуждают.

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

👨‍🎓 PascalCase (без пробелов, с большими буквами в начале слов)

🐫 camelCase (без пробелов, с большими буквами в начале слов, начиная со второго, как горбы у верблюда)

🐍 snake_case (вместо пробелов используется подчеркивание, всё маленькими буквами)

🍢 kebab-case (вместо пробелов используется "минус", слова нанизаны на шампур)

Во-вторых, какие части речи использовать — глаголы, существительные? Особенно актуально для эндпоинтов API

В-третьих, для существительных — во множественном или в единственном числе их называть?

В-четверых, словарь. Какими словами вы называете объекты, и как переводите на английский (надо ли говорить, что называть все объекты нужно на английском, если только у вас не 1С). Как вы назовете счет клиента? Account, Check или Schet?

Любопытно, что рекомендации и лучшие практики для API и для БД иногда противоположны!

Для БД советуют использовать snake_case (так проще различать слова). Для эндпоинтов API — kebab-case, т.к. в вебе ссылки принято подчеркивать, и значок "_" может потеряться. Почему не camelCase? Потому что труднее различать слова и нужно переключать регистр (URI регистрозависимые).

В обоих случаях рекомендуется использовать в качестве названий существительные во множественном числе (для ресурсов REST API и для названий таблиц в БД). Один из аргументов для БД — меньше риск, что имя таблицы совпадет с зарезервированным словом. Хотя есть и контраргумент: давать таблицам и представлениям названия в единственном числе, чтобы не думать, как переводить во множественное (person — это persons или people?). Холиварная тема!

Следующая тема — идентификаторы. Должны ли они называться просто id, или повторять название сущности (team_id?) Есть аргументы за и против. Внешние ключи, понятно, должны назваться по названию внешней таблицы+id.

Названия таблиц и полей должны содержать полные слова, не сокращения. Нет ничего хуже таблицы pmnt23, состоящей из полей P1, NMT, ABBR14, FIELD28, ACC_NO и т.д. Названия типов также не должны становиться именами полей: DATE, TEXT или TIMESTAMP не дают никакого объяснения смысла. Также стоит подумать над более конкретными названиями — source_warehouse_id а не просто source_id.

Для API, кроме того, нужно понимать — запрашиваем ли мы коллекцию или единичный элемент? Если это элемент из коллекции, то будет существительное во множественном числе / id (users/{id}), но это может быть и служебное слово, указывающее на особенный элемент коллекции (users/me).

Про глаголы в REST писать не буду, пуристы скажут, что никаких глаголов в названиях эндпоинтов быть не может, но вот Google, например, считает иначе.

Ну а если у вас не REST, а наоборот даже RPC, то названия методов рекомендуется писать в PascalCase по формату "ГлаголСуществительное" — что мы делаем и над чем мы это делаем, причем существительное должно указывать на тип передаваемого объекта (GetBook возвращает объект Book).

Ну и пока нам не встречался camelCase, куда же без него. Он у нас живет внутри JSON — так записываются названия полей.

В общем, как видите, тема неочевидная, и лучше в проекте договориться на старте (или в рамках всей организации), чтобы не получилось у одних так, а у других эдак. Одинаковые вещи должны выглядеть одинаково, это дает возможность предположить и угадать, а не бегать каждый раз в документацию. Документ, в котором описываются эти принципы, называется "Соглашение об именовании". Программистам с этим проще — у них есть линтеры, которые проверяют исходный код на соответствие установленному стилю. Для спецификаций я такого пока не видел. Но хотя бы договориться об этом стоит.

Ссылки на стили наименования, сборники лучших практик и посты по этому поводу:
https://github.com/RootSoft/Database-Naming-Convention
https://dev.to/ovid/database-naming-standards-2061
https://www.belgif.be/specification/rest/api-guide/#resource-archetypes
https://restfulapi.net/resource-naming/

Практикум радует (правда, статья-то ещё прошлогодняя). А давайте поможем Даше накидаем разные способы классификации интеграций? Вот вы какие знаете?

Чудная статья от Яндекс.Практикума про типы интеграций. Написана как будто специально, чтобы поиздеваться над аналитиками: у нас есть два способа классификации интеграций и по нескольку видов интеграций в каждой классификации. Объединим обе классификации в единый нумерованный список и расскажем вам про них по очереди! 🤯

Считаю, что зря они только две классификации взяли. Нужно было расстараться и штук пять взять! И по одному примеру из каждой классификации в список добавить! В общем, какое-то "системный аналитик изнасиловал журналиста" получилось.

https://practicum.yandex.ru/blog/sistemnaya-integraciya