#путь_DE

✏️ Не так давно я писал про культуру разработки и ведения Git.

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

😮 Но тут на прошлом спринте я впервые столкнулся с моим первым настоящим code review от моего лида. Это выглядело довольно занимательно и интригующе. Я понимаю, что неоптимальный код должен быть отловлен еще до стадии push в репо. И когда я получил обратно свой код с 20 комментами, то словил двоякое ощущение:
1️⃣ у меня много ошибок, как я так много накосячил, это все увидели. То есть это не конечный результат в виде parquet или любого другого файла, а именно логика ETL с моим стилем кода.
2️⃣ ощущение интереса и роста, поскольку более опытные DE прямо указывает места, которые можно подтюнить здесь и сейчас.

На фикс моего pull request я потратил 2 дня, не без помощи коллеги. Но столкнуться и разобраться с этим было довольно здорово.

И тут пришел еще один инсайт: если у вас есть возможность на проекте, после разработки кидайте ваш код не в файлы локально, а в репо (командное или личное).

Это даст вам несколько преимуществ:

🔹 Вы будите получать опыт разработки и ведения проекта в git по всем канонам. То есть не затрагивая master часть приложения / БД / ETL. Разработка новой фичи / витрины / скрипта будет происходить у вас в новой ветке, а выкат этого в master будет безболезненным с code review.

🔹 Коллеги в любой момент смогут обратиться к вашему коду без вас. Удобно, поскольку совсем недавно я разработал логику для нескольких view, которые отдают данные для BI, и хранил скрипты локально. Конечно, можно посмотреть DDL в БД, но лучше иметь человеческий код под рукой.

🔹 на многих проектах нужен опыт с Git (или аналогами), а тут у вас уже будет набита рука на базовых и необходимых действиях с ним.

😠 Фатальный кейс - если кто-то дропнет (случайно) эти view, а код их создания локально, то тут можно понервничать (со мной и это было 👀)