Если порыться на внутренней кухне софтверных компаний, то можно обнаружить, что разрабатываемые приложения и сервисы часто имеют весёлые имена. Это могут быть имена мультперсонажей, мифических героев, космических объектов, географических объектов, героев книг, героев комиксов и фильмов… Пожалуй, это наиболее популярные категории имён, но есть и другие. Разработчики софта – люди креативные, чего только не придумают. Мне попадались даже названия ягод и элементарных частиц.
Справедливости ради подчеркну, что не во всех компаниях, где разрабатывают софт, ему дают весёлые имена. Но во многих.
Насколько хороши весёлые имена? Какие есть альтернативы? Как лучше всего называть софт? Какие имена используют в зрелых софтверных компаниях?
Об этом и поговорим…
Начну с пары примеров.
В одной достаточно крупной компании существовал и существует до сих пор внутренний сервис с названием «Философский камень». Этот сервис осуществляет «очистку» поступающих ему на вход данных. Что это за данные и от чего конкретно их очищают, здесь не важно. Скажу только, что этот сервис из входных данных удаляет элементы, которые могут затруднить их последующую обработку либо не важны для дальнейшего. Думаю, не совру, если скажу, что прочитав имя сервиса, вы не поняли, чем он занимается. И думаю, что даже после приведённого мной пояснения вопрос «А при чём здесь Камень?» у вас всё равно остался. Автор этого имени объясняет его так: «Философский камень превращает неблагородные металлы в золото. Так же и этот сервис превращает плохие данные в хорошие».
Ура! Кажется, теперь у нас есть имя, которым можно назвать практически любой сервис или приложение. Потому что почти любая софтина делает что-то ценное на основе входных данных.
В действительности сервис назывался не «Философский камень», а немного иначе, но очень похоже. Настоящее имя я здесь привести не могу, по понятным причинам, однако суть я максимально сохранил.
Иногда за креативными именами приложений и сервисов стоят захватывающие истории. Вот одна из них. В одном крупном российском банке некий разработчик (очень хороший, кстати! Привет, бро!) написал скрипт, который мониторит некоторые параметры RedShift-кластеров, развёрнутых в банке. Если значения параметров выходят за границы заданных диапазонов, то соответствующий кластер «прибивается», то есть его насильно останавливают. Скрипту нужно было дать имя. Разработчик рассудил следующим образом: у нас есть RedShift кластер, его нужно «убить». Соответственно, скрипт – это RedShift Cluster Killer. Берём первые буквы этих слов, получается Rck. Нужен какой-то известный убийца, в имени которого есть эти буквы. Если добавить гласные, то получится Rocky. Явно получается отсылка к знаменитому Rocky Balboa. Роки Бальбоа – это почти что убийца. Поэтому сервис нужно назвать Rocky. Так он и был назван.
Здесь я опять немного изменил реальную историю, чтобы не выдавать конкретный банк, конкретный кусок софта и конкретного человека. В действительности нужно было мониторить и «убивать» не RedShift кластеры, а другие куски инфраструктуры. Поэтому согласные буквы в аббревиатуре получились другие, и между ними были вставлены другие гласные, что привело к имени другого киношного персонажа. И вот тот персонаж был уже настоящим убийцей, в отличие от Роки Бальбоа, который вообще-то не совсем убийца (надеюсь вы мне это простите; не так просто изменить реальный жизненный пример, чтобы и пароли-явки не выдать, да еще и мельчайшие детали воспроизвести).
Хорошее ли, в итоге, получилось имя у небольшого сервиса? Rocky – звучит! И история красивая! Очень остроумно, многослойно… однако у людей нет шансов самостоятельно, без подсказки, раскопать все эти слои остроумия. Более того: проходит время; человек, создавший эту историю, увольняется… В реальности так оно и было: человек, написавший сервис и придумавший ему имя, уволился из компании спустя несколько месяцев после того, как сервис появился на свет. Что остаётся в итоге? А остаётся какой-то Rocky. И уже никто не поможет докопаться до сути и оценить шикарное название. Совершенно не ясно назначение сервиса. Но даже если вы это назначение выяснили, то не понятно, почему кусок софта, который прибивает RedShift кластеры, называется почему-то Rocky. По коду и какой-то документации – если есть – можно определить, что сервис умеет делать в настоящий момент. Но укладывается ли текущее поведение в начальную задумку? Какой была эта задумка? Какова область ответственности сервиса? Раз это просто Rocky, то почему бы его не расширить? Пусть он, может, ещё и какие-нибудь нотификации клиентам банка рассылает или ещё чего… Тут я уже фантазирую. Дальнейшая судьба этого Rocky мне неизвестна. Однако такое «расширение» — это именно то, что часто происходит с сервисами, за которыми явным образом не закреплена какая-то область ответственности: в них начинают пихать всё, что ни попадя… А лучший способ закрепить за сервисом какую-то область ответственности – это дать ему подходящее имя.
Коротко о главном
Сервис должен называться таким образом, чтобы из имени была понятна его область ответственности, то есть то, чем занимается этот сервис (или приложение). Поэтому не следует называть сервисы именами ягод, мультперсонажей или своих любовниц.
Это основная мысль данной статьи. Казалось бы, можно закончить, но… я уже вижу, как многие закипели у экранов… Поэтому продолжим. Я обосную свою мысль, а также расскажу о проблемах, к которым приводят весёлые имена; разберу аргументы сторонников весёлых имен и приведу пару примеров того, как нужно и как не нужно именовать внутренние компоненты облачных сервисов. (Облачные сервисы - это нынче модная тема, поэтому на них остановимся отдельно).
Минутка занудства
Для начала нужно определиться, что это за «приложения и сервисы», об именах которых мы здесь говорим. И я даже написал огромное формальное определение… которое затем стёр. Думаю, проще опираться на интуитивные представления, которые наверняка есть у каждого, кто плотно связан с разработкой софта. Ниже я часто буду говорить об именах «программных компонент», или просто «компонент», потому что имена могут быть не только у сервисов и приложений. Вот несколько типов программных компонент, которые могут иметь имена:
законченное исполняемое приложение
библиотека, которая релизится независимо и используется несколькими разными приложениями
библиотека, которая является неотъемлемой частью только одного приложения; отдельно не релизится, но так как компилируется в отдельный артефакт, то имеет собственное имя
web-сервис
serverless функция в облаке, например, AWS Lambda
Это далеко не все возможные примеры. Но все и не нужны, иначе это было бы верхом занудства с моей стороны, и при этом я всё равно что-нибудь упустил бы. Я здесь буду исходить из того, что у вас есть, как минимум, интуитивное представление, о чем идёт речь.
Ниже я буду во взаимозаменяемой манере использовать слова «компонента», «сервис», «микросервис», «приложение», «система» (под «системой» я понимаю большую софтверную компоненту, которая может состоять из миллионов строк кода и имеет сложную внутреннюю структуру, то есть сама в свою очередь состоит из большого количества компонент, например, приложений. Но при этом отдельные компоненты «системы» не используются или редко используются самостоятельно). Если где-то в тексте я использовал только какое-то одно из перечисленных слов, сказанное всё равно остаётся справедливым и для всего остального.
До верха занудства я, может, и не дойду, однако еще немного позанудствую. Сделаю еще один дисклаймер. Мы не будем здесь говорить о том, как приложения и сервисы должны называться во внешнем мире, то есть за пределами компаний или сообществ, которые их разрабатывают. Во внешнем мире существует конечный продукт. Однако у любого крупного конечного продукта под капотом есть множество компонент, которые не видны его пользователям и имеют самостоятельное значение только внутри компании или сообщества, разрабатывающего продукт. Например, есть продукт «Маркетплейс Озон» или есть продукт «Соцсеть ВКонтакте», или «ОС Windows», но за каждым из этих названий скрывается зоопарк из большого количества сервисов и подсистем, из которых складывается конечный продукт. Нас здесь интересует именно этот внутренний зоопарк. Именованием конечных продуктов пускай занимаются маркетологи. Им виднее (хотя явно не все маркетологи одинаково хороши в этом деле).
На этом возможные дисклаймеры у меня, конечно же, не закончились. И я бы с удовольствием накинул ещё парочку. Например, про нюансы open source разработки и разработки с закрытым кодом или про то, что именно понимается под продуктом. Потому что иногда конечный продукт – это «железка» – например, система хранения данных – внутри которой могут крутиться десятки миллионов строк кода. Однако я перестану накидывать дисклаймеры. Думаю, все всё поняли: большое количество строк кода могут разрабатываться для разных нужд, конкретная специфика не важна. Важно то, что если это действительно миллионы строк, то проблема нейминга стоит перед разработчиками по-любому.
Ну и небольшое напутствие: не пугайтесь, если встретите в этом тексте название технологии или рыночного продукта, с которыми не знакомы. Я постарался не привязываться к конкретным технологиям или продуктам, однако иногда на них всё-таки ссылаюсь в иллюстративных целях. Соответственно, если вы встретите незнакомое название, то можете либо поискать его в интернете, либо не париться и продолжить читать дальше, потому что из последующего текста всё равно станет примерно понятно, о чём идёт речь.
Если я ссылаюсь на облачные продукты, то это продукты Amazon (просто потому что Amazon крупнейший в мире облачный провайдер; его прощё всего взять за референс).
Невесёлые проблемы весёлых имён
Хотя именование продуктов для внешнего мира подчиняется своим – по большей части, маркетинговым – законам, часто даже во внешнем мире софт называется так, что из названия понятно назначение продукта. Например, компания Amazon вполне себе любит и умеет давать сервисам описательные имена: Simple Queue Service, Simple Storage Service, Simple Workflow Service и т.п. Слово «simple», с точки зрения описания назначения сервиса, выглядит довольно бесполезным. Вероятно, оно служит маркетинговым целям. Однако видно, что Amazon явно что-то понял ещё в начале своего «облачного» пути. Сейчас у них уже сотни сервисов, и если бы Amazon изначально стал называть их «Винни-Пух», «Пятачок», «Кристофер Робин» и тому подобное, то это привело бы к большой проблеме: у них просто закончились бы имена персонажей из этой книжки! И что тогда??? Шучу…
В каждой шутке есть доля шутки...
Я хоть и сказал, что шучу, но иногда бывает не до шуток… Мне довелось наблюдать несколько ситуаций, когда у команд разработчиков заканчивались «весёлые» имена. Например, у одной достаточно крупной команды закончились имена героев любимого комикса. Это привело ко множеству дискуссий и голосований на тему «как жить дальше и как же теперь называть компоненты?»
Проблема, конечно же, не в том, что могут закончиться весёлые имена. Проблема в том, что сейчас, когда у Амазона сотни сервисов, у потребителя были бы все шансы свихнуться от пятачков и винни-пухов. Вы бы никогда не запомнили, какое имя какому сервису соответствует, а если и запомнили, то к тому моменту уже уволились бы с прежнего места работы и устроились в компанию, которая использует сервисы уже не Амазона, а допустим, Майкрософта… и вокруг вас завертелись бы персонажи уже другой сказки. И это не говоря уже о том, как тяжело вам приходилось бы находить общую почву с людьми из глобального сообщества. Пришли вы, допустим, на конференцию по облачной разработке, а там речь про сплошных пятачков и винни-пухов…
Вернёмся теперь к именованию программных компонент внутри компании. Здесь справедливы те же самые соображения. В больших компаниях на горизонте одной команды разработчиков обычно находятся 3-5, иногда 10, именованных компонент. Однако в тех же самых компаниях есть люди, на горизонте которых могут находиться десятки или даже сотни таких компонент. Это архитекторы решений, бизнес-аналитики, интеграционные тестировщики. Именно на этих людей ложится основная боль работы с «весёлыми» именами.
Вот мы и подошли к важному противоречию, связанному с funny-неймингом (так я буду иногда называть присвоение компонентам «веселых» имен; а иногда буду использовать выражение «весёлый нейминг»). Весёлые имена дают компонентам люди, для которых конкретные имена не критичны. Не критичны, потому что на горизонте этих людей находится довольно небольшое количество имён/компонент. Люди же, для которых имена компонент действительно имеют огромное значение, весёлых имён давать не стали бы, но по какой-то причине эти люди оказались непричастны к неймингу и вынуждены страдать, пытаясь запомнить, кто есть кто в огромном зоопарке компонент.
В одной транснациональной корпорации, где мне довелось работать, существовала и существует до сих пор такая штука как архитектурный комитет. Это собрание, на котором архитекторы представляют высокопоставленным представителям различных бизнес-функций наиболее сложные архитектурные решения.
Так вот: на каждом заседании одни и те же люди – например, вице-президент по безопасности или вице-президент по разработке – задавали один и тот же вопрос: а чем занимается сервис под названием «Человек-паук»? В действительности там было имя другого персонажа комиксов, но сути это не меняет. А суть в том, что не так-то просто запомнить область ответственности сервиса с таким именем. Это был один из ключевых сервисов, поэтому он фигурировал практически в каждом новом продуктовом «решении», поэтому постоянно попадался на глаза одним и тем же людям-членам архитектурного комитета. Но даже при всём при этом им всё равно никак не удавалось запомнить, чем занимается сервис. Ситуация усугублялась тем, что область ответственности этого сервиса была очень размыта. Несмотря на то, что сервис существовал всего несколько лет, он уже успел превратиться в изрядную помоечку и решал множество задач, несвязанных друг с другом.
И вот здесь мы подошли к основной проблеме весёлых имён. Давая такие имена, люди в подавляющем большинстве случаев не продумывают место компоненты в общей канве продукта. За компонентой не фиксируется конкретная область ответственности. То есть дело-то, на самом деле, не в именах.
Нейминг — это не какая-нибудь сугубо лингвистическая самостоятельная проблема, а лишь отражение того, насколько хорошо был проработан технический дизайн.
Чтобы дать компоненте хорошее имя, необходимо решить техническую задачу встраивания этой компоненты в общую канву продукта и определиться с её областью ответственности. Весёлые имена обычно указывают на то, что в дизайне продукта плохо проработаны области ответственности компонент. А это уже очень серьезная проблема с далеко идущими последствиями. Со временем большинство весело поименованных компонент превращаются в помойки, потому что в них постоянно добавляют то, что в текущий момент проще/удобнее положить именно в них. Какие у всего этого последствия?
Тяжело восстановить логику продукта, глядя на его высокоуровневую реализацию. Каждый раз, когда возникает необходимость добавить в продукт новый нетривиальный функционал, люди, которые проектируют архитектурное решение, тратят уйму времени на то, чтобы понять, куда вставить новые куски логики. При этом снова и снова придётся впихивать эти куски куда попало и как попало. Этот процесс занимает много времени. И даже когда решение уже готово и почти созрело для релиза, обязательно вылезет проблема, которую никто не мог предсказать, просто потому что никто досконально не знает, как все компоненты-макароны перепутаны между собой. Иногда решение такой проблемы может привести к полной переделке решения. А это срывы сроков, нарушенные маркетинговые обещания и тому подобное... Чуть выше я сказал про «нетривиальный функционал», однако иногда добавление даже тривиальной фичи может привести к массе проблем и потребовать колоссального времени на реализацию
Невозможно организовать эффективное многоуровневое тестирование. Когда у вас макароны, то тяжело предположить, на что могут повлиять те или иные локальные изменения. По-хорошему, нужно тестировать «всё». Но часто такой вариант тестирования недоступен до практически полного завершения разработки из-за его дороговизны и длительности. Однако в хорошо структурированных продуктах даже финальные тестирования можно значительно ограничивать в объёме. И чем лучше структурирован продукт, тем меньше лишних тестов нужно гонять. В случае макарон вы вынуждены либо перестраховываться и гонять всё подряд, либо рисковать --> сокращать тестирование --> огребать проблемы уже после релиза
Размазанность однотипных данных по разным программным компонентам и хранилищам данных, а также дублирование данных. В результате, для некоторых логических объектов (например, для объекта «клиент компании») может быть не понятно, из каких крупиц данных складывается их полное состояние; и даже более того: единого согласованного состояния может вообще не существовать
Я, пожалуй, прерву этот список после трёх пунктов. Продолжать его можно долго, но так и от темы легко уйти, потому что здесь мы подошли к фундаментальным вопросам архитектуры софта. Их можно обсуждать до бесконечности. Я просто хотел подчеркнуть, что нейминг – это не просто нейминг, но индикатор и одновременно следствие того, каким образом вы подошли к решению этих фундаментальных вопросов.
Перед тем, как двинуться дальше, остановлюсь ненадолго на пункте про «размазанность и дублирование» данных. Кажется, он требует пояснения. Тем более что всё, что связано с хранением, организацией и моделями данных — моя любимая тема. На мой взгляд, это ключевая тема при построении архитектуры. Проколы в этой части стоят очень дорого. Ошибки в других областях, как правило, исправляются гораздо легче. Также если вы хорошо проработали модель данных, всё остальное обычно органичным образом насаживается на неё. Так вот… пример из реальной жизни. Есть одна компания, которая изготавливает сложные глубоко кастомизированные продукты под специфические нужды каждого клиента. Здесь не важно, что это за продукты. Важно, что разработчики софта в этой компании упустили из виду такую область ответственности, как управление клиентскими "хотелками". Привело это к следующему… Когда клиент компании оформляет заказ на веб-сайте, он задаёт необходимую ему конфигурацию продукта. Далее, так как управление пожеланиями клиента по отношению к заказу не было выделено в отдельную область ответственности, несколько сервисов создают копии предоставленной клиентом конфигурации; и разные приложения/сервисы начинают работать с разными копиями. Всё это более-менее работало, пока существовали только один-два способа, которыми клиент мог задать желаемую конфигурацию продукта или внести в неё изменения. А потом бизнес компании развился, и клиенты получили ещё бОльшую гибкость: стало возможным вносить изменения в желаемую конфигурацию продукта на разных этапах жизни заказа и при этом – кучей разных способов. И вот тут началось веселье… Потому что копии конфигурации, создаваемые разными сервисами в разные моменты времени, стали различаться. То есть единая конфигурация заказа теперь отсутствует в принципе. Разные системы видят её по-разному. Проблема эта не решена до сих пор. Исправлять её в момент обнаружения было дорого, поэтому решили заткнуть. И затыкают до сих пор. Надо ли говорить, что с каждой новой затычкой решать проблему становится ещё дороже?
Итак, зафиксируем: имена – они не сами по себе. Хоть мы и фокусируемся в этой статье именно на нейминге, в действительности он редко является самостоятельной проблемой и в большинстве случаев отражает то, как люди подходят к решению фундаментальных архитектурных вопросов. При правильном подходе к дизайну, имена компонент являются следствием того, как в архитектуре продукта были распределены области ответственности между компонентами.
Аргументы сторонников funny-нейминга
Вернёмся теперь непосредственно к неймингу. Посмотрим, каким образом весёлый нейминг вообще возникает.
Я бы сказал, что funny-нейминг — это показатель незрелости компании. В зрелых компаниях весёлого нейминга либо уже нет, либо не появляется новых весёлых имён и при этом активно избавляются от старых. Кстати, по моей информации, один российский маркетплейс уже некоторые время интенсивно работает над уходом от funny-нейминга. Молодцы! Поздравляю с новым этапом зрелости. Успехов им в этом непростом деле.
Приходит же весёлый нейминг в компании почти всегда на этапе стартапа. Слово «почти» я здесь поставил только из соображений теоретической полноты, ибо не знаком со всеми компаниями всего мира. Однако во всех стартапах, которые мне известны, есть/был весёлый нейминг. И пока компания является стартапом, в таком нейминге нет проблем. Разработчики пилят несколько приложений/сервисов, которые можно назвать как угодно. Среди разработчиков есть один-два наиболее влиятельных, которые обычно и прививают какую-нибудь близкую им концепцию весёлых имён. Например, один из таких разработчиков может до безумия любить итальянскую кухню, и тогда он может планомерно продавливать концепцию, в соответствии с которой приложения и сервисы должны называться как блюда итальянской кухни. Далее компания растёт. Это если повезёт; не все стартапы вырастают в большие компании, так что не все весёлые имена становятся проблемой. Но если компания вырастет, то в ней может появиться уже несколько более-менее независимых «кластеров» разработки. Например, каждый кластер может работать над отдельным продуктом или крупным логическим куском единого продукта. В этом случае в каждом кластере уже могут быть свои правила весёлого нейминга. В предельном случае каждая небольшая команда разработчиков может называть свои компоненты, как им покажется нужным, а точнее — как им покажется веселее.
К сожалению, funny-нейминг может цвести не только в стартапах и небольших компаниях. Мне известна крупная международная компания, которая разрабатыват софт почти три десятка лет, и в ней по-прежнему поощряется funny-нейминг. Точнее, там всё-таки есть довольно крупная «поляна», на которой удалось уйти от весёлого именования к именованию в соответствии с областями ответственности компонент. Однако в остальной компании — а это где-то процентов 80 от полной разработки — весёлый нейминг не только сохраняется, но и поощряется высоким начальством. Даром это не проходит. В компании не задерживаются хорошие разработчики, а разработка даже элементарных фичей может тянуться многие месяцы. Но это не только из-за нейминга, конечно же. Сам по себе весёлый нейминг в компаниях такого размера — это симптом. В данном случае симптом далеко не единственный, отсюда и ком нарастающих проблем.
Что сторонники весёлого нейминга обычно говорят в защиту своей позиции? Я сделал для вас подборку типичных аргументов, ибо разговоров на тему нейминга в разных компаниях у меня было очень много.
Аргумент 1: зачем давать хорошие имена? Ведь в результате развития компонент имена потеряют актуальность
Это аргумент из разряда «Зачем мыть машину? Она всё равно запачкается» или «Зачем делать дома уборку? Потом всё равно придётся убираться». Это будто пристрелить ребёнка, на дав ему пожить, потому что его в будущем дофига проблем ждёт. Да, дать компоненте «вечное» идеальное имя, скорее всего, не получится. Вряд ли, вы сможете сделать идеальный дизайн раз и навсегда, так же как не сможете раз и навсегда написать код, который не понадобится рефакторить. Как минимум, потому что вы не умеете предсказывать будущее. (Ну, я надеюсь, что не умеете). Вы не знаете, куда пойдёт бизнес/продукт через пару лет или даже завтра. Однако это не повод не пытаться делать хороший дизайн. Да, его придётся постоянно корректировать и дополнять. Но это лучше, чем вообще никогда не пытаться сделать хороший дизайн. Более того: если что-то перестало «влезать» в старую концепцию, то это подсказка, что пора её переосмыслить и, возможно, предпринять какие-то практические шаги (например, распилить сервис на несколько или явным образом расширить его область ответственности, закрепив это в документации; можно даже переименовать, хотя в очень крупных продуктах это может быть достаточно болезненно). Даже если в какой-то момент времени имя сервиса и его область ответственности разойдутся — чего всё-таки надо стараться избегать — то это всё равно лучше, чем если бы сервис вообще никогда не имел «говорящего» названия.
Аргумент 2: наша команда владеет этой компонентой, поэтому мы называем её как хотим
Во-первых, компонентой юридически владеет не команда, а компания. Во-вторых, команда разработки создаёт код, но она не создаёт и не владеет требованиями к нему. Так обычно устроен бизнес. Высокоуровневые требования исходят от продуктовых команд, маркетинга, сэйловых подразделений. Технические требования исходят от solutions- и application- архитекторов либо людей, которые, может, не по должности, но по факту, играют эти роли.
Примечание: про архитекторов и архитектуру разных уровней
Application-архитектурой я называю внутреннюю архитектуру отдельных приложений/сервисов/систем. А solution-архитектурой называю более высокий уровень абстракции, на котором отдельные приложения/сервисы/системы «склеиваются» в единый продукт. Соответственно, именование сервисов находится в ведении solutions-архитектора (таких архитекторов может быть один или несколько на продукт), а именование внутренних компонент сервиса находится в ведении application-архитектора (который у каждого сервиса или группы сервисов должен быть свой). При этом выделенного application-архитектора в команде разработки может и не быть. В этом случае его роль может исполнять менеджер команды или кто-то из старших разработчиков.
Говоря про "именование внутренних компонент сервиса", я имею в виду, что современные сервисы могут иметь больше, а иногда – значительно больше, одного deployment-артефакта, то есть могут состоять из большого количества независимо разворачиваемых компонент. При этом разработка такого (микро-)сервиса всё равно часто ведётся силами одной небольшой команды, ибо совокупный объём кода одного (микро-)сервиса обычно невелик, даже если количество независимых deployment-единиц в составе сервиса относительно велико.
При этом надо помнить, что из любого правила существуют исключения, а также существуют разные методологии разработки. Но общепринятый референс сейчас примерно такой: небольшие сервисы, которые находятся в ведении небольших команд разработки.
Если в команде или в группе команд нет выделенного application-архитектора, то в этом случае есть вероятность, что на уровне внутреннего устройства сервиса будет реализован funny-нейминг. Однако это не будет супер-большой проблемой, если хотя бы на уровне solution-архитектуры поддержан responsibility-нейминг (то есть именование в соответствии с областью ответственности), ибо весело поименованные компоненты будут «заперты» внутри команды разработки, а на более высоком уровне – где подразумевается взаимодействие команд – весёлых имён не будет. С этим, наверное, можно как-то жить, но разработка тех сервисов, внутри которых реализован funny-нейминг, может страдать по мере того, как сервисы разрастаются и в них становится больше внутренних компонент.
Приведу также слова моего бывшего коллеги-архитектора: «Имя сервиса никак не затрагивает команду разработчиков этого сервиса, зато сильно затрагивает людей, которым приходится работать с этой командой или же координировать работу нескольких команд. Так что именование сервиса находится вне зоны ответственности его разработчиков».
Аргумент 3: мы специально назвали сервис именем героя комиксов, чтобы не привязываться к конкретной области ответственности; таким образом мы не создали себе лишних ограничений и при необходимости можем добавлять в сервис что угодно
Это мой любимый аргумент. Просто топчик! Из сервиса уже изначально пытаются создать «помоечку». Кстати, тот сервис, от автора которого я услышал этот аргумент — а это был менеджер по разработке, — буквально за несколько лет превратился не просто в помоечку, а в огромную свалку. Сейчас он является одной из основных болевых точек для компании, которая владеет им.
Аргумент 4: работа - это не только потребности бизнеса, но еще и потребности сотрудников. Благодаря funny-неймингу люди получают фан
Фан, веселье на работе — это круто. Но во-первых, фан не должен затрагивать сферу ответственности других людей. Например, мне может не нравиться цвет стен в офисе, но я же не иду по фану их раскрашивать. Есть специальные люди, в зону ответственности которых входит оформление офиса. Да, они могут (и наверное, должны!) прислушаться к пожеланиям разных людей, работающих в офисе, но решение принимают, в конечном итоге, именно они. То же самое должно быть с неймингом. Он должен входить в зону ответственности архитекторов либо людей, которые выполняют эту роль. Во-вторых, место фану можно найти и без ущерба для нейминга. Я не буду здесь перечислять все те тысячи способов, которыми развлекают себя сотрудники IT-компаний. С разнообразием здесь проблем точно нет.
Аргумент 5: имена должны быть короткими. Отсюда и funny-нейминг
Имена, в первую очередь, должны быть описательными, а уже потом всё остальное. Да, при выполнении условия описательности, имя желательно делать покороче. Это творческий процесс. И имя, данное в соответствии с областью ответственности, вовсе не обязано быть длиннее, чем весёлое имя. Иногда полное имя может быть длинным, но при этом может существовать хорошая аббревиатура. И эту аббревиатуру люди запомнят, потому что она связана с осмысленным названием. Например, когда-то весь мир знал, что CVS – это Concurrent Versions System.
Аргумент 6: маркетинг
Этот аргумент никто никогда не произносит вслух, поэтому с ним тяжелее всего работать. Дополнительных сложностей добавляет то, что из соображений «маркетинга» обычно действует менеджмент: от менеджеров перового уровня и вплоть до директоров по разработке. Суть маркетингового аргумента в том, что имя приложения должно его «продавать», то есть увеличивать ценность приложения в глазах тех, кто слышит или видит его имя. Следовательно – по мнению тех, кто даёт «маркетинговые» имена – продающее имя будет продавать также и их самих в глазах начальства. Приведённый в самом начале пример с «Философским камнем» – это, как раз, история про продающее имя. Часто продающие имена могут содержать высокопарные слова, вроде «ultra», «ultimate», «smart». Например, «smart что-нибудь», и это при том, что «stupid что-нибудь» никогда не существовало. По мнению авторов таких имён, «крутое» имя говорит о том, что сами авторы делают крутую работу. Поэтому чем круче имя, тем лучше.
Повторюсь: с «маркетинговым» аргументом тяжелее всего работать, ибо присущ он обычно менеджменту, а «продажа» своей работы более высокому начальству часто является для менеджеров чуть ли не основной деятельностью. Конечно же, речь не обо всех на свете менеджерах. Есть менеджеры, которых продают не слова, а дела. Такие менеджеры сами нередко настаивают на именовании компонент в соответствии с областями ответственности, ибо бывают достаточно глубоко погружены в проблемы разработки софта.
Я назвал аргумент «маркетинговым», потому что он сильно перекликается с тем, как даются имена продуктам во внешнем мире. Часто имя для внешнего мира подбирает именно маркетолог. В настоящий, профессиональный, маркетинг я здесь не полезу. Как я уже говорил выше, если нужно имя для внешнего мира, то там обычно начинают действовать соображения, не связанные с дизайном софта. Хотя даже при всём при этом в современном мире наметились, как мне кажется, интересные тенденции. Вспомним ещё раз Amazon, который использует комбинированный нейминг. Имена многих его сервисов начинаются со слова «simple», и это продающая часть имени. А дальше следует описание области ответственности: «storage service» (также известен как S3), «workflow service» (также известен как SWF) и т.п.
По моему мнению, в дизайне софта (а имя сервиса — это часть дизайна) не должно быть места маркетингу. За маркетинг отвечают другие люди, и они занимаются маркетингом вне компании. «Продавать» же сервисы внутри компании — довольно деструктивная идея, на мой взгляд. Тем не менее, существует компромиссный вариант. Менеджеры и директоры по разработке могут придумывать продающие имена проектам. Проекты приходят и уходят. После того, как проект сделан, о нём довольно быстро забывают, и уже не важно какое у него было имя. Так что оно вполне может быть «super smart game changer». А вот сервисы остаются надолго, и важно, чтобы у них были имена, которые описывают их места в глобальном дизайне продукта. (Хотя я и считаю, что обозначенный компромисс допустим, лучше всё-таки обходиться без него и прибегать к нему только если совсем уж туго. Проектов в крупных компаниях обычно параллельно ведётся значительно больше одного. И людям, которые соприкасаются одновременно со множеством из них, каждый раз придётся сильно напрягаться при встрече с их весёлыми именами. Поди вспомни, что это за проект с названием «Moonshot»).
Одно время я думал, что у меня есть убийственный аргумент против весёлого нейминга. Я говорил оппонентам: «Вы же не называете функции или классы в коде именами мультперсонажей. Уровень приложений и сервисов — это тоже уровень организации кода. Да, уровень абстракции выше, но большинство проблем те же самые, которые нужно решать на уровне функций, классов, модулей, библиотек». Но однажды случилось вот это... Вот, что я узнал от товарища:
В этот момент мой мир рухнул. Шучу. В этот момент я понял, что даже в случае с именованием функций могут быть... ммм... как бы это сказать... нюансы...
Тем не менее... со скидкой на единичные нюансы, классы и функции почти всегда имеют описательные имена, даже если приложение, частью кода которого они являются, носит весёлое имя. Таким образом, подход к неймингу показывает, где заканчивается круг забот у людей, дающих имена. Когда человек даёт описательное имя классу, это означает, что он рассматривает этот класс как часть более крупной системы. Если же человек даёт весёлое имя приложению, это означает, что на границах этого приложения его круг забот заканчивается. То есть он не склонен рассматривать приложение в контексте более крупной системы. Этот человек, конечно же, понимает, что приложение является частью чего-то большего, но конкретно его это не очень сильно заботит. Если обязанность человека — разработка конкретного приложения или сервиса, то такой круг забот совершенно оправдан. Просто это означает, что имена приложениям и сервисам должны давать люди, в чей круг забот входят взаимодействия между приложениями и сервисами.
«Наносервисы»
С появлением облачного компьютинга — и в особенности serverless-компьютинга — funny-нейминг заиграл новыми красками. Благодаря serverless-компьютингу появилась возможность дробить микросервисы на более мелкие компоненты, каждая из которых является отдельной deployment-единицей (то есть её можно релизить независимо от других аналогичных компонент, входящих в состав микросервиса). Такие компоненты я здесь условно называю «наносервисами». Как пример, наносервисы могут быть реализованы на базе AWS Lambda, а микросервис может складываться из нескольких AWS Lambda-функций.
Наносервисы — раз уж они являются частями единого микросервиса — конечно же, относятся к кругу забот той команды, которая разрабатывает соответствующий микросервис. И казалось бы: раз так, то можно рассчитывать, что разработчики микросервиса отнесутся к ним примерно как к классам или функциям в коде и дадут им описательные имена. К счастью, так часто и происходит. Тем не менее, иногда происходит иначе. Некоторые фанаты funny-нейминга обрадовались тому, что теперь — благодаря serverless-компьютингу — даже замухрышная 100-строчечная компонента может получить отдельное весёлое имя. Ещё бы! Ведь теперь это не какая-нибудь текстовая функция в коде, а полноценная deployment-единица. Лично мне уже удалось получить несколько психологических травм от вида микросервисов, состоящих внутри из условных Пятачков и Винни-Пухов. Начинались такие микросервисы буквально с пары-тройки внутренних Винни-Пухов и Пятачков, но по мере «взросления» — раз уж был взят курс на дробление микросервиса на независимые deployment-единицы — появлялись Совы, Иа, Кростоферы Робины и тому подобное. И да, зачастую размеры этих сущностей были в районе 150-200 строк кода.
Как лучше поступать с наносервисами? Есть ли какой-то хороший рецепт для их именования?
У меня на этот счёт есть два соображения.
Стоит избегать слишком мелкой нарезки микросервисов на наносервисы. Если наносервис имеет размер в пару сотен строк, и тем более если наносервисов такого размера в составе одного микросервиса несколько, то для меня это повод задуматься: не слишком ли мелкая нарезка? Иногда это может быть оправдано. Например, необходимостью независимого масштабирования наносервисов, экономей денег и/или вычислительных ресурсов. Но часто это не так, и тогда мелкая нарезка приводит только к вытаскиванию лишних деталей реализации на более высокий уровень абстракции. Мелкая нарезка превращает менеджмент текстового кода в менеджмент deployment-единиц, что может добавлять лишнего головняка со стабильностью, производительностью и т.п. Тем не менее, подобные дизайны сейчас набирают популярность. Думаю, это отчасти связано с усилиями облачных провайдеров. В их интересах продвигать такие дизайны, потому что для них это дополнительные деньги. Однако если кто-то сильно хочет что-то продать, это само по себе ещё не повод покупать «что-то». Даже если на профильных конференциях евангелисты только об этом и говорят. На то они и евангелисты, чтобы активно продвигать то, во что верят/за что получают деньги.
Впрочем, даже если мелкая нарезка не оправдана, она не является какой-то супер-пупер проблемой. Я не думаю, что цена неверного решения по мелкой нарезке — если такое решение принесёт проблемы в будущем — будет высока.
Второе соображение ничем не отличается от основного принципа, озвученного в начале статьи: нужно просто давать наносервисам описательные имена, отсылающие к области ответственности наносервиса.
Разберём пример. Он будет довольно искусственным, потому что реальные примеры — это куча ненужных сейчас деталей.
Допустим, нам нужен HTTP-сервис, который умножает два целых числа и возвращает результат, обращаясь к внешнему HTTP-эндпойнту (то есть во входном запросе клиент указывает web-адрес — URL — по которому сервис-умножитель должен будет обратиться, чтобы вернуть результат).
Требуемый сервис может выглядеть, например, вот так:
Всё очевидно, не правда ли?
Похоже на плохую шутку, но нет… Мне пришлось повидать сервисы со схожей компоновкой и схожим именованием внутренних компонент. Здесь в качестве названий выбраны имена супер-героев Марвела.
Итак, что же здесь изображено? Весь сервис целиком называется «Wolverine» (то есть «Росомаха»). На входе в сервис стоит serverless-функция «Batman». Она принимает входящие запросы и кладёт их в очередь. Может и ещё что-нибудь делать; например, выполнять авторизацию клиента.
Чтобы сервис был доступен внешнему миру через HTTP-интерфейс, перед «Бэтменом» стоит API-гейтвей.
Все существенные вычисления выполняются внутри приложения «Spiderman» (он же «Человек-паук»). Допустим, разработчикам показалось, что умножение двух чисел – это сложная вычислительная задача, которую нужно решить максимально эффективно, поэтому «Человека-паука» они реализовали в виде приложения на С++. Далее, они решили, что интегрировать «Человека-паука» с ближайшим окружением всё на том же C++ не оптимально, поэтому написали на языке Go обёртку под названием «Супермен». Эта обёртка/фасад умеет брать из входной очереди задачу, запускать Человека-паука, анализировать его коды возврата, а также класть возвращённый им результат в выходную очередь. При этом у Человека-паука могут ещё быть пара прямых интеграций с внешним миром, например, для отправки метрик и логов в соответствующие облачные сервисы. Но эти интеграции реализованы не напрямую через API внешних сервисов, а с помощью native-библиотек, предоставленных производителями сервисов; это позволяет не заниматься сетевыми заморочками на C++. Человек-паук и Супермен упакованы в Docker-контейнер, который умеет автоматически масштабироваться за счёт того, что погружен в соответствующий сервис облачного провайдера (например, Amazon ECS). Далее, обе очереди – и входная, и выходная – являются внутренними компонентами сервиса «Росомаха», снаружи сервиса они не видны.
Выше было сказано, что Росомаха взаимодействует с внешним миром через HTTP-протокол. В связи с этим после выходной очереди у нас стоит «Халк» – serverless-функция, которая по HTTP отправляет результат умножения сервису-клиенту, тому самому, по запросу которого это умножение и было выполнено. Очередь между Суперменом и Халком поставлена для большей отказоустойчивости. Если сервис-умножитель попытается отправить клиенту результат умножения, а клиент в это время будет «лежать», то результат вычислений останется в выходной очереди, и через какое-то время Халк сможет снова попытаться достучаться до клиента.
Оранжевым цветом я выделил компоненты, которые облачный провайдер предоставляет как полностью готовые к использованию сервисы, для которых не нужно писать код; а голубым цветом раскрашены компоненты, которые были написаны разработчиками Росомахи. При этом голубые компоненты работают под управлением каких-то других сервисов облачного провайдера (например, сервиса масштабирования контейнеров, сервиса исполнения serverless-функций и т.п.)
Почему умножение двух чисел реализовано именно таким образом? На самом деле, не почему. Такой сервис можно реализовать множеством разных способов. Это просто какой-то случайный вариант, да и сама задача искусственная, поставленная исключительно в иллюстративных целях. Впрочем, дизайны такого рода довольно часто встречаются на практике.
Также отмечу, что диаграмма очень упрощённая. На ней не показано, на какие конкретные сервисы облачного провайдера опирается реализация Росомахи. У всех у нас может быть опыт работы с разными облачными провайдерами, а у кого-то такого опыта вообще может не быть, поэтому я здесь не привязываюсь к специфике конкретного провайдера. Также опускаю некоторые другие детали, которые обязательно присутствовали бы в практической реализации.
Итак, этот пример демонстрирует, что в мире облачных вычислений каждый маленький «чих» потенциально может получить своё уникальное весёлое имя. К сожалению, так действительно происходит в некоторых компаниях.
Но какой могла бы быть картина в условиях responsibility-нейминга? Например, такой:
Аббревиатура SLF здесь означает «Server-less function». Если наш облачный провайдер, к примеру, Amazon, то аббревиатуру SLF на диаграмме можно заменить словом «Lambda». Сервис здесь уже называется «IntMultiplier», то есть прямым текстом говорится, что это умножитель целых чисел. Приложению на C++, выполняющему само умножение, совсем не обязательно давать уникальное имя. Мы явным образом указываем, что это «движок» («engine») всего сервиса-умножителя. Слово «engine» вполне конкретно сообщает, что это высокопроизводительная компонента, которая делает всю основную работу.
Прослойку между «движком» и соседними компонентами я здесь назвал «Integration front». Здесь могут быть варианты: «Network wrapper», «Façade» и т.п. В условиях облачной разработки появляется много служебных компонент, которые схожи между собой, но при этом являются частями разных микросервисов. Например, в рамках одного продукта может быть несколько или даже много микросервисов, внутри которых есть свои уникальные, ни с чем не схожие «движки», перед которыми находятся похожие друг на друга «интеграционные фасады». Так вот: очень желательно, чтобы существовало соглашение, согласно которому все схожие компоненты во всех микросервисах будут называться одинаковым образом. Тогда любой технарь из любой команды сможет взглянуть на любой сервис внутри компании и сразу понять его логическую компоновку. Для служебных компонент, которые выполняют одни и те же функции, но в разных сервисах, уникальные имена не только не нужны, но даже вредны. Если нужно сослаться на конкретную служебную компоненту, которая является частью конкретного микросервиса, то для этого к стандартному имени компоненты достаточно добавить имя самого микросервиса. Например, «IntMultiplier Engine Integration front». Здесь я добавил не просто имя микросервиса, а имя конкретной компоненты, перед которой находится Integration front. Это имя выделено курсивом. То есть интеграционная прослойка стоит перед IntMultiplier Engine – движком сервиса IntMultiplier. Такое подробное описание может быть полезно в случае, если внутри сервиса есть несколько компонент, перед которыми находятся интеграционные прослойки. Однако на практике это очень редкая ситуация, поэтому обычно достаточно только имени сервиса.
Далее… я очень не верю во всякие джентельменские соглашения на словах и соглашения на бумаге, когда дело доходит до крупных проектов и больших продуктов. Если соглашение не реализовано на уровне кода, оно будет нарушено. Соответственно, необходимо позаботиться о том, чтобы имена служебных компонент были каким-то образом стандартизованы именно в виде кода, а не в виде абзаца на 22-ой странице coding-стиля.
На рисунке выше входная serverless-функция так и названа «Входной», а функция, которая делает call-back, так и названа Callback-функцией. Что-то изобретать здесь не нужно. Чем проще – тем лучше.
Влияние сервисов оркестрации на нейминг
Забавно, что использование сервисов оркестрации, типа конечных автоматов (state machine), для связывания различных компонент между собой значительно улучшает ситуацию с неймингом. (Пример такого сервиса оркестрации – AWS Step Functions).
Допустим, мы решили реализовать наш гипотетический сервис для умножения двух чисел из предыдущего раздела с помощью конечного автомата. Если мы при этом являемся фанатами funny-нейминга, то наш сервис мог бы выглядеть так:
Я немного видоизменил пример, чтобы он лучше ложился на использование конечного автомата. Итак, что мы здесь имеем? Всё тот же сервис «Wolverine», но теперь внутри него уже используется изображённый оранжевым цветом конечный автомат – сервис оркестрации, предоставленный облачным провайдером. Для конечного автомата разработчики умножителя реализовали четыре состояния: 1) для загрузки входных данных в приватное хранилище сервиса, 2) собственно для умножения двух чисел, 3) для выгрузки результата на сторону клиента и 4) для оповещения клиента об окончании работы над запросом. Повторюсь, что пример искусственный, поэтому не важно, для чего могла бы понадобиться загрузка входных данных и выгрузка результата.
Но если пофантазировать…
... то можно сказать, что пускай числа будут оооочень большими, и клиент оправляет нам ссылку, по которой эти огромные данные можно скачать. При этом пускай мы поддерживаем много разных способов получения входных данных. Например, интерфейс умножителя может «торчать» во внешний мир, чтобы люди/компании могли за денежку им пользоваться; и эти люди/компании могут хранить свои огромные числа на инфраструктуре разных облачных провайдеров; а мы хотим поддерживать интеграции с как можно большим количеством облачных провайдеров, чтобы привлечь как можно больше пользователей к нашему продукту. Поэтому мы решили выделить все поддерживаемые способы загрузки входных данных в отдельный шаг, чтобы на шаге непосредственно умножения можно было уже унифицированно работать с данными из приватного хранилища и не заморачиваться с внешними интеграциями. В этом же духе можно было бы обосновать и шаг выгрузки результата, но суть сейчас не в этом…
Так вот: на каждом из перечисленных шагов вызывается отдельный наносервис, который выполняет необходимую работу. Это наносервисы Elektra, Enigma, Maggott и Groot (используется всё та же концепция имён марвеловских супергероев из предыдущего раздела). Что из себя представляют эти наносервисы с точки зрения деплоймента – не важно. Например, это могут быть serverless-функции. Также на картинке опущено множество других подробностей: состояния конечного автомата, в которые мы будем сваливаться при возникновении ошибок; способ, которым будет инстанциироваться конечный автомат; способ передачи промежуточных результатов между ноносервисами Elektra, Enigma, Maggott, Groot; и т.п. Главное здесь, что несмотря на то, что имена наносервисов по-прежнему весёлые, логика полного сервиса-умножителя легко читается, потому что состояния конечного автомата уже никто не назовёт именами комикс-героев. По крайней мере, мне не доводилось такого видеть. Если вам вдруг такое встречалось, то обязательно напишите об этом в комментариях. Будем восхищаться многогранностью мира вместе 😊
Позитивное влияние сервисов оркестрации на нейминг ни в коем случае не означает, что я призываю обязательно использовать сервисы оркестрации. То, как связывать нано- и любые другие сервисы между собой (прямые HTTP-запросы из сервиса в сервис, конечные автоматы, очереди, топики и т.п.), определяется кучей разных требований, но требования к неймингу при этом никакой роли не играют. У конечных автоматов есть свои плюсы и свои – довольно весомые – минусы. Примером с конечным автоматом я хотел показать, что выбор используемых в разработке технологий может влиять на нейминг и понимание логики организации отдельных систем и продукта целиком. Иногда этим можно и нужно пользоваться.
В одном из разделов выше я уже говорил, что весёлые имена на уровне внутренностей сервиса представляют меньшую проблему, чем весёлые имена самих сервисов и систем. Ибо в этом случае весёлые имена более-менее «заперты» на уровне одной команды разработчиков. Тем не менее, система или сервис может со временем разрастись. Внутри него может появиться множество новых компонент, и в какой-то момент может даже возникнуть необходимость разделить его на несколько независимых сервисов (и соответственно, разделить команду разработки на несколько независимых). Поэтому не стоит недооценивать потенциальный негативный эффект от funny-нейминга на уровне наносервисов. Проблемы funny-нейминга в некоторых современных энтерпрайзах зародились ещё тогда, когда энтерпрайзы были стартапами. Однако потенциал этих стартапов позволил бизнесу многократно вырасти, а вместе с безнесом вырос и масштаб проблем, связанных с funny-неймингом. Также и некоторые микросервисы имеют потенциал когда-нибудь превратиться во что-то сильно большее, чем они есть сейчас, и «выплеснуться» за пределы одной команды.
Резюмируем
весёлое имя не позволяет понять место сервиса в контексте более широкой системы или продукта целиком
имя — это не просто имя. Хорошее имя проистекает из продумывания области ответственности компоненты и планов её развития. Если вы не даёте компоненте такое имя, то скорее всего, у вас нет чёткого понимания места этой компоненты в глобальном дизайне продукта и нет концепции её дальнейшего развития. А раз нет такого понимания, то у вас не будет чётких границ между областями ответственности разных компонент. И тогда вы со временем получите монолит. Даже если формально это будут десятки/сотни разных сервисов, концептуально это всё равно будет монолит. У вас не получится вести по-настоящему независимую разработку этих сервисов
когда весёлых сервисов много, понять дизайн продукта становится почти невозможно. Во-первых, потому что не ясно, как из сотен Пятачков, Винни-Пухов и Сов должен складываться, допустим, какой-нибудь маркетплейс или служба доставки еды. Думать о дизайне продукта в правильных категориях становится очень тяжело. Процитирую здесь одного моего хорошего товарища-архитектора: «То, что система делает, и то, как она называется, не должно быть двумя разными вещами. Люди никогда этого не запомнят. У нас слишком много систем, чтобы такой вариант сработал». Во-вторых, границы Пятачков и Винни-Пухов со временем становятся сильно размытыми, и даже если постоянно держать в голове или на бумаге список того, чем занимается Пятачок, этот список со временем будет сильно переплетаться с тем, что делает Винни-Пух
если у компонент весёлые имена, то люди из разных областей экспертизы, которые могли бы привнести ценность в дизайны разных систем, в итоге её не привнесут, потому что из-за того, что у них другие прямые обязанности, они не смогут потратить полжизни на понимание того, чем занимаются Пятачки и Винни-Пухи. Чем понятнее ваш дизайн для широкого круга людей, тем больше разносторонних экспертов смогут приложиться к развитию этого дизайна. Впрочем, иногда цель дизайнера — «спрятать» детали устройства от окружающих. Дизайнеру кажется, что таким образом он повышает собственную ценность для компании, потому что только он владеет сакральным знанием. Но такие «эксперты» - это уже совсем другая история... тема для другой «архитектурной записки»
имя, которое даётся компоненте, должно способствовать пониманию более широкой системы или продукта. Если имя не способствует достижению этой цели, то логично задаться вопросом: «А что это за цели тогда у автора имени? Они точно связаны с развитием компании и её бизнеса?»
Всё!
<Здесь будет ссылка на английскую версию статьи, когда и если у меня дойдут руки сделать перевод. Коллеги часто просят>
Ссылка на предыдущую "записку": Записки архитектора. Чек-лист