Словари и термины

Словари и термины

В любом техническом проекте есть концепции, сущности и действия, которые должны быть поименованы. Особенно их много на ранних этапах. Как известно, в компьютерных делах есть всего две сложные задачи - инвалидация кэша и выбор имен, так что горячие дискуссии на тему выбора названий неизбежны. Cоздание общего “словаря” для команды - одна из важнейших задач технического командира проекта, а подводные камни могут встретиться здесь на каждом шагу.

Во-первых, велик соблазн пустить все на самотек. Типа, сами разберутся. Скорее всего, действительно разберутся, но результат вряд ли будет оптимальным. На самом деле, конфликты во время выбора имен для сущностей и действий нередко указывают на разногласия по поводу архитектуры. Руководителю следует эти несогласия обнажить и подтолкнуть команду к обсуждению и компромиссу. Например, если один разработчик предлагает название "query engine", а другой хочет назвать тот же блок "processing manager", то вероятно, что у этих двух инженеров в голове есть некоторый следующий уровень детализации системы, который надо обсудить и прийти к общему знаменателю и названию.

Далее, многие команды грешат частым выбором безликих названий: “engine", "manager", "server", "node", "item" и тому подобные комбинации. В принципе, ничего неправильного в этом нет, и это может быть подходящим выбором. Но для важных компонентов лучше выбрать имена, которые станут легко узнаваемыми. Например, если система использует некоторый специальный DSL, то можно назвать кусочки этого DSL довольно безликим "configuration entry", а можно - "recipe" (англ. "рецепт"), что будет лучше выделяться. Аналогично, если есть некоторый блок, обрабатывающий запросы, который предлагается назвать "query engine", имеет смысл рассмотреть более редкие имена. Например, если вы его назовете "Buratino", то это хоть и выглядит смешно, но станет очень популярной частью системы и поддержит дух команды в сложные времена. Тут, правда, есть момент - сильно необычные имена больше годятся для блоков с нетривиальным функционалом. То есть называть Буратино некую простую обертку над генерацией SQL запросов не стоит - это будет выглядеть пафосно. С другой стороны, стремиться к наличию глубины в блоках системы стоит в любом случае.

После того, как имя для сущности или действия появилось, важно, чтобы оно использовалось всюду - во всех командах проекта, в документации, в коде, в комментариях. Здесь руководителю следует быть начеку и сохранять чистоту словаря языка команды. Иногда становится понятно, что название перестало соответствовать сути из-за естественного развития системы. Появляется соблазн его поменять. Здесь надо понимать последствия и цену этого шага. Частичное переименование вызовет путаницу, поэтому если нет четкого полного плана по его завершению, часто лучше оставить все как есть, пусть имя и неидеально.

Пожалуй, самые ответственные места в плане именования - это APIs и схемы данных, так как поздние изменения в них трудоемки. При этом удачный выбор имен и ответственное их использование может сделать API гораздо проще в использовании. Инвестиции времени в этот аспект на раннем этапе для продуктов, где API является одним из аргументов в продажах, окупятся с лихвой. Реализацию API всегда можно переписать, а вот форма и концепции - это та одежка, по которой вас будут встречать.

При этом одна из причин, по которой именование сущностей и действий в компьютерных делах считается сложным, это то, что мнений по этому вопросу в команде будет множество. Кто-то будет не готов к компромиссам в отстаивании своей точки зрения. Кто-то будет пытаться уйти от неприятных тем через “какая разница, потом переименуем”. Для достижения успеха команде нужна будет четкая модель принятия решений, где мнения могут быть услышаны, но в случае разногласий слово остается за лидером. Без этого развитие проекта рискует стать кладбищем недопринятых решений. Впрочем, неудачные имена в этом случае, скорее всего, будут меньшей из проблем.