Илья Зыкин. Pro Жизнь

Классик ситуэйшн.

Найм Джуна/мидла.
- Вот тебе 1500 вопросов из всех сфер ИТ, дизайн, и онлайн кодинг на 3 часа. 5 этапов интервью.
- ой, ну вы не все ответили, не знаем, достойны ли вы ваших 500$ в месяц. Мы подумаем.

Найм синьера-помидора.
Встреча с СТО/вице президентом по инжинирингу на 30 минут.
Чувак, времени нет. Давай по быстрому. Есть реакт, тейлвинд, nextjs, тесты и ci/cd. Умеешь такое? Чего не знаешь, ребята покажут. Ну давай, завтра желательно выходи. Денег мульен, работать не спеша. Соблюдай ворк баланс, не выгорай. Пока 👋

Кандидаты на выброс из проектов

Меньше народу (файлов и зависимостей) — больше кислороду (лучше фокус, навигация, поддержка).

Уже давольно давно я активно разгружаю основной код проектов от всего того хлама, который разработчики напихивают внутрь и потом в корне проекта у них 250 файлов c настройками, 100500 зависимостей, которые используются только по праздникам, и тд и тп.

Что бы такого можно выкинуть?

— Код деплой-инструментов. Ну, этого точно в проекте держать не надо.
— Докер файлы, скрипты инициализации и прочее для запуска окружения для разработки. — это все можно легко вынести в отдельный репозиторий и организовать удобную и простую в поддержке запускалку проектов любой сложности.
— Любые дополнительные инструменты разработки, дебага, отладки — типа сторибука.

Так, Илья, ты что-то упоролся. Может еще и тесты предложишь вынести во вне?

Нет, а вот тесты их запускалки точно выностить из основного проекта не надо — тесты это неотьемлемая часть технологического процесса. Тесты это не опциональные элементы; Выделяя и отрывая из основного проекта опциональные и логически автономные фрагменты главное не перестараться.

Капистрано (часть 2)

Главное преступление, на мой взгляд, которое сделали авторы капистраны — научили руби экосистему хранить код деплоилки в каталоге рельсового проекта.

Так просто кто-то придумал. Так написали в документации и все стали бездумно делать.

Капистрано как зависимость стала идти с кодом проектов. Поверх капистраны еще шли не менее уродливые плагины на капистрану под разные случаи деплоя. Все они были написаны в формате капистрановского DSL (я уже упоминал, что он явно не красивый и не удобный).

Конфиги капистраны хранились в проекте и раздували его. Да, обычно не сильно. Но все равно не приятно.

Посмотрев на эту дичь, и немного подумав, я сделал простой и очевидный вывод — Инструмент деплоя не имеет никакого отношения к проекту и находится в проекте не должен.

Так еще 15 лет назад, а то и больше, я выкидывал из проектов код деплоилки в отдельный каталог и репозиторий и жить становилось веселее всем.

1) Решения не смешивались
2) Читать код и поддерживать отдельный инструмент деплоя намного проще, когда тебе не мешают файлы основного проекта, которые находятся где-то рядом и хрен его знает где и как и что найти.
3) Команда разработчиков могла ничего не знать о капистране, и тонкостях деплоя. А им обычно и не надо об этом знать. Обычно разрабы в это нос совать не должны.
4) Я избавил окружение разработки и зависимости от лишнего мусора. Меньше кода — быстрее загрузка.

В общем одни плюсы со всех сторон. Да и при переключении на другую деплоилку не надо заботится о том, чтобы почтистить проект от капистраны. Ведь ее в проекте нет.