Первый хороший признак адекватности команды разработки - размер репозитория.
Семь лет назад, в Naumen, я работал в продукте, который писали на java 30 человек около 10 лет и вся репа (не только актуальный код) весила 83 метра.
Руководитель разработки строго следил и вдумчиво объяснял ящерам типа меня, что коммитить блобы нехорошо и если есть бинарник, то в гите должна быть только ссылка с номером версии. По рукам бить успевал.
Второй - умение работать с конфигами.
Здесь можно проследить эволюцию.
В каждом из этих пунктов я поработал какое то время, в том или ином проекте той или иной компании. Каким будет 4й пункт - я хз, наверное об этом знают уже девопсы.
Кажется, вот такие вопросы стоит задавать на собеседовании. Правда я еще не знаю, какие делать выводы.
Семь лет назад, в Naumen, я работал в продукте, который писали на java 30 человек около 10 лет и вся репа (не только актуальный код) весила 83 метра.
Руководитель разработки строго следил и вдумчиво объяснял ящерам типа меня, что коммитить блобы нехорошо и если есть бинарник, то в гите должна быть только ссылка с номером версии. По рукам бить успевал.
Тот руководитель разработки ушел из компании 5 лет назад. Интересно, просрали ли полимеры ребята или держатся?Я не буду перечислять преимущества, получаемые, если этого принципа придерживаться и проблемы, возникающие, если на него забить.
В Контуре, к сожалению, в адекватный размер реп умеют неравномерно. В 15 из 25 команд, про которые я точно знаю (общее число около 60) точно больше 1 Гб. Есть немало команд с размером реп меньше 100 Мб.
Второй - умение работать с конфигами.
Здесь можно проследить эволюцию.
- Конфиги в исходниках, прямо в глобальных переменных, затем в полях классов или чем-нибудь подобном. Удобно, легко ищется и не надо писать менеджер конфигов.
- Конфиги в спецфайлах. Появляется сущность настройки системы.
- В том же репозитории.
- Снаружи репозитория. Приходит понимание, что коммитить и резилить каждый раз ради изменения мелких настроек - странно.
- Конфиги в отдельном репозитории. Появляется отслеживание настроек, осознается сущность "релизный цикл" и понимание, что он бывает разный.
- В релизный цикл настроек входит тестирование, специальным или общим набором тестов.
В каждом из этих пунктов я поработал какое то время, в том или ином проекте той или иной компании. Каким будет 4й пункт - я хз, наверное об этом знают уже девопсы.
Кажется, вот такие вопросы стоит задавать на собеседовании. Правда я еще не знаю, какие делать выводы.
Комментариев нет:
Отправить комментарий