Эти 4 момента выделены в подзаголовки:
1) Архитектура и дизайн решения
2) Соблюдение правил и соглашений, принятых в команде
3) Корректность решения
4) Тестируемость кода и наличие юнит-тестов
А сколько у вас таких пограничных случаев и как часто они возникают? Если есть урон «духу товарищества», то как вы это исправляете?
Поделитесь, очень интересно.
В статье на мой взгляд излишне много дартаньянства
Вы так говорите, как будто это что-то плохое :)
И команды, и проекты в разных компаниях бывают очень разные. И код ревью в них служит разным целям. И на часто повторяющийся вопрос «а не поздновато ли» значительная часть таких команд с чистой совестью ответит — нет.
Совершенно верно. Разумеется, я описываю в статье наш опыт. И разумеется, он может отличаться от других команд и других компаний. Я надеюсь что основной посыл «думай, потом делай, потом подумай еще раз: все ли правильно», так или иначе я донес.
К сожалению, описанные в статье проблемы — не мнимые. Это личная практика. Как бы это странно или нереально ни выглядело.
В моем случае масса проблем была как раз в том, чтобы установить «изначальные правила». В командах, которые уже думают что итак все знают и умеют. Отсюда и проблемы.
По поводу машинного обучения — можем, умеем, практикуем. Обязательно напишем что-нибудь интересное. Спасибо что читаете наш блог.
Красиво расписали. А теперь представьте что серверов не 3 и не 5, а несколько тысяч. И что выкладка делается без остановки всего и вся, «наживую». И подумайте еще раз.
Способов решить задачу быстрофикса в продакшене — масса. Мы решили для себя что текстовые патчи в код на интерпретируемом языке нас вполне устраивают. Быстро, понятно, дешево, сердито, логируемо и т.д.
В чем преимущество усложнения системы дополнительными обвязками в виде контейнеров? К тому же там, где подобное необходимо, мы докер вполне используем. banuchka даже про это доклады и статьи делал.
werklop gitflow это миф. Почитайте другие статьи в блоге Баду пожалуйста. У нас много интересного, уверяю — вам понравится. Начать можно вот с этого.
По поводу волевого решения — не сомневайтесь, там где нужно поднажать, поднажимаем. Но необходимо так же помнить о том, что рабство запрещено некоторое время назад. К тому же наша компания (как и многие другие) — не армия. И способов мотивации сотрудников тогда, когда это действительно нужно, сильно больше чем «кнут» и «пряник».
Изначально в гите встроенных средств для коллективного ревью кода нет. Поэтому пришлось искать что-то подходящее.
В то время как для мержа веток все есть из коробки. git merge нас устраивает чуть более чем полностью.
Вот тут в комментариях выше, я описал вводную. Эксперименты с Upsource у нас закончились тем, что в течении двух недель инструмент не смог индексировать историю самого большого репозитория. Мы писали в Jet Brains (у нас есть там контакты со времен укрощения teamcity). Нам ничего вразумительного не смогли посоветовать, а только попросили предоставить им этот самый репозиторий, чтобы они на живых данных проверили что там так долго индексируется. Этого мы, разумеется, себе позволить не смогли.
Да, видимо было бы неплохо сделать обзорную статью со сравнением :) Давайте так: я дам вводную, а после попробую найти время на полный обзор, но не обещаю что время найдется. Это же кучу инсталляций и замеров надо делать опять, причем держа в голове что это для публичной статьи :)
Вводная:
1) Инструмент должен быть self-hosted.
2) Инструмент должен иметь возможность доработки по мере появления запросов на новые фичи.
3) Бесплатный опенсорсный лучше платного проприетарного :)
4) Инструмент должен поддерживать разделение доступа по репозиториям.
5) Общее кол-во репозиториев в системе — чуть менее 250.
6) Самый большой репозиторий содержит ~130 тысяч файлов, весит около 5 гигабайт. История коммитов в нем на текущий момент ~ 670 тысяч коммитов.
Большинство инструментов, которые мы пробовали, начинали фейлить на 6м пункте — загружали историю нашего репозитория по нескольку дней, недель и т.д. И потом безумно тупили. codeisok же не делает никаких внутренних индексов и работает поверх гита. Получается быстро.
1) Архитектура и дизайн решения
2) Соблюдение правил и соглашений, принятых в команде
3) Корректность решения
4) Тестируемость кода и наличие юнит-тестов
Поделитесь, очень интересно.
Золотые слова. Как этого добиваться на постоянной основе, не поделитесь?
Вы так говорите, как будто это что-то плохое :)
Совершенно верно. Разумеется, я описываю в статье наш опыт. И разумеется, он может отличаться от других команд и других компаний. Я надеюсь что основной посыл «думай, потом делай, потом подумай еще раз: все ли правильно», так или иначе я донес.
В моем случае было по-разному. Поэтому я и постарался описать ситуацию с разных сторон.
По моему скромному мнению, можно и так и эдак. Главное чтобы все понимали что делают и для чего это делается.
В моем случае масса проблем была как раз в том, чтобы установить «изначальные правила». В командах, которые уже думают что итак все знают и умеют. Отсюда и проблемы.
По поводу машинного обучения — можем, умеем, практикуем. Обязательно напишем что-нибудь интересное. Спасибо что читаете наш блог.
В чем преимущество усложнения системы дополнительными обвязками в виде контейнеров? К тому же там, где подобное необходимо, мы докер вполне используем. banuchka даже про это доклады и статьи делал.
По поводу волевого решения — не сомневайтесь, там где нужно поднажать, поднажимаем. Но необходимо так же помнить о том, что рабство запрещено некоторое время назад. К тому же наша компания (как и многие другие) — не армия. И способов мотивации сотрудников тогда, когда это действительно нужно, сильно больше чем «кнут» и «пряник».
Изначально в гите встроенных средств для коллективного ревью кода нет. Поэтому пришлось искать что-то подходящее.
В то время как для мержа веток все есть из коробки. git merge нас устраивает чуть более чем полностью.
Вводная:
1) Инструмент должен быть self-hosted.
2) Инструмент должен иметь возможность доработки по мере появления запросов на новые фичи.
3) Бесплатный опенсорсный лучше платного проприетарного :)
4) Инструмент должен поддерживать разделение доступа по репозиториям.
5) Общее кол-во репозиториев в системе — чуть менее 250.
6) Самый большой репозиторий содержит ~130 тысяч файлов, весит около 5 гигабайт. История коммитов в нем на текущий момент ~ 670 тысяч коммитов.
Большинство инструментов, которые мы пробовали, начинали фейлить на 6м пункте — загружали историю нашего репозитория по нескольку дней, недель и т.д. И потом безумно тупили. codeisok же не делает никаких внутренних индексов и работает поверх гита. Получается быстро.