Версионность 🌱🌿🌴🌳
💭 Только представьте:
Заходишь в папку коллеги, а там файл «обработка_данных_v3_new_final.py», и не понятно, чем же он отличается от версии «v2_fixed.py». Даже сам коллега уже не в силах это припомнить 😱
Или на почту прилетает новое письмо от заказчика с вложенным «отчёт_продажи_финальный.docx» и внутри — данные месячной давности 👍
Думаю, для всех знакомая ситуация 😁
А у кого-то и в личных папках найдутся шедевры типа "_new_final_v6" или "_new_old_buckup_111" 😎
Поэтому, сегодня разберём такую полезную тему как Версионность.
🔥 Версионность — это система учёта изменений объектов (скриптов, документов, конфигураций).
🔖Зачем?
1️⃣Избегаем коллизий 🥺
Файлы типа «final», «updated», «backup» не несут смысловой нагрузки. Кто и когда их создавал? Что в них изменилось?
2️⃣Не теряем историю 📖
Можем восстановить, как объект выглядел неделю назад, или понять, кто и что изменил.
3️⃣Снижаем риск ошибок ⚠️ при использовании устаревшей версии скрипта или данных
4️⃣Экономим время ⏰
Когда поиск «правильной» версии не превращается в квест.
💡 Клёво, когда этот процесс автоматизирован с помощью Git/SVN или других инструментов, позволяющих управлять изменениями. Однако даже тут правила нейминга значительно упрощают работу.
🔖Как же разработать эти правила нейминга?
Для начала, давайте посмотрим на мир с точки зрения ООП:
⚫️Человеческие понятия - это классы - инструкции. (Представь себе яблоко)
⚫️Все что вокруг нас - объекты - экземпляры классов. (Это уже про конкретное яблоко на столе)
⚫️В объектах уже очень конкретно определены свойства, которые приехали из класса. (У любого яблока есть цвет, но у яблока на столе он зелёный)
⚫️У каждого экземпляра есть своя история изменений и последнее состояние - актуальная версия.
📎 Рассмотрим пример:
У документа "Бизнес требования" есть шаблон: 📝"Шаблон_БТ_<код_проекта>_<номер_задачи>_v.1.0.0" - это класс.
Для конкретной задачи своего проекта аналитик оформил БТ и сохранил как "БТ_BNB_REP754_v1.1.0" - это уже экземпляр класса БТ.
А потом в ходе разработки заказчик решил изменить часть требований (и не раз, как обычно 🙃), поэтому аналитик менял документ и получил уже "БТ_BNB_REP754_v1.1.4" - это последняя версия экземпляра класса БТ.
🔥 Итого:
1️⃣Название объекта состоит из <имени>+<версии>. Это своего рода «натуральный ключ» объекта 🗝.
2️⃣Имя должно содержать информацию о классе (что это?) и детали об экземпляре класса (что конкретно?) ℹ️.
3️⃣У имени должен быть шаблон, чтобы легко отличать одни классы от других и экземпляры в рамках одного класса 🍴
4️⃣Версия содержит информацию об изменениях экземпляра и состоит из 3х цифр (подход называется семантическое версионирование):
📝MAJOR.MINOR.PATCH📝
⚫️MAJOR - главная версия, меняется при значительных изменениях функционала
⚫️MINOR - дополнительная версия, меняется при добавлении новых функций
⚫️PATCH - исправление, меняется при внесении правок.
Иногда цифр указывают 4.
В примере с Бизнес требованиями первая цифра может как раз отвечать за версию шаблона.
А в некоторых проектах обходятся и двумя или вовсе одной цифрой (это своего рода показатель зрелости проекта 🍎).
Сколько цифр использовать - решать конечно вам 😉, но три - наиболее распространенная best practice.
5️⃣Внутри самого объекта полезно вести историю изменений: для каждой версии добавлять описание - что и кем изменено.
😒Здорово, я и так вроде про это знал... И все-равно в спешке кажется, что проще уже как-нибудь назвать и сохранить 😐
Но как пел капитан Врунгель:
Как вы яхту назовёте - так она и поплывет! ⛵️
❗️Тут и правда большую роль играет обучение команды и выстраивание дисциплины в правилах нейминга.
Ведь работать и приносить пользу они начнут тогда, когда все будут их соблюдать 😌.
Поэтому начните с малого:
✔️Наведите порядок сначала в своих объектах, добавьте к ним версию 📂.
✔️Потом предложите шаблон для нейминга 🎭.
✔️А там глядишь коллеги войдут во вкус и тоже начнут получать эстетическое удовольствие от красивых имён 🖼 .
🙂А с какими смешными названиями файлов или тем писем приходилось сталкиваться вам?
