Никита Прокопов (tonsky) wrote,
Никита Прокопов
tonsky

Category:

Как вы лодку назовете...

Не плодите имен. Бывает, что одну и ту же вещь называют двумя-тремя-четырьмя разными способами. Например, переменная окружения, ее имя в коде, ее имя в логе, имя ключа в JSON, глобальное имя в JS и так далее:

resourcePrefix = getenv(“RESOURCE_PREFIX”)
log.info(“resource prefix: “ + resourcePrefix)
JSON payload = { “resource_prefix”: resourcePrefix }

Они все похожи, но разные. Оправдывается это тем, что в разных языках/окружениях приняты разные соглашения и надо соответствовать. Это аргумент валидный, но исключительно эстетический. Программист объективно видит все возможные стили именования каждый день, так что не будем делать вид, что какое-то конкретное написание его испугает.

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

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

Наконец, третье. Процесс переименования сам по себе бесполезен. Он занимает реальные строчки кода, вводит новые сущности. Даже так: вводит новые имена, что когнитивно дороже, чем сущности. Тут работает более общее правило: любое усложнение, любое действие, любое решение — у всего должна быть причина. Конкретная причина, конкретное объяснение, вербальное, формулируемое. Очень легко проверить — просто сформулируйте словами. Здесь же действие налицо, а причина очень зыбкая, почти эфемерная.

Императив достаточно простой: используйте одно и то же имя. Тащите в код переменную окружения COMPANY_RESOURCE_PREFIX? Так и назовите: String COMPANY_RESOURCE_PREFIX = …;. И в JSON засуньте под тем же именем. И в БД. Так же и со всем остальным: имя таблицы и имя ORM-класса. Имя файла и имя переменной с его содержимым. Ключ в хэше и ключ в БД. Это упрощение, а упрощения окупаются многократно.

Да, это не всегда это возможно — в некоторых ситуациях определенные виды имен запрещены. Я могу долго рассуждать, сколько вреда несут искусственные, ничем не оправданные ограничения на имена, придуманные во времена телетайпов и даже тогда взятые, как правило, с потолка; сколько сил и энергии вообще на это тратят программисты, как часто подобные соглашения античеловечны (почему у кого-то нельзя пробел? Дефис? Юникод? И т.п.). Тут ничего не поделаешь, конечно. Моя задача — посеять правильную идею.

Tags: девелопмент, нетрадиционное программирование, учу жизни, формула успеха
Subscribe
  • Post a new comment

    Error

    default userpic
    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 44 comments