Ну вы пишете что он использует подход авторитетное мнение. Этот подход подразумевает, что автор не аргументирует свою позицию, а обосновывает исключительно своим авторитетом.
Ну ок, я понял. То что он использует провокационные стиль мизлодения - тут соглашусь. Но не вижу в этом ничего такого страшного. Суть от этого не меняется.
Вообще -то на мой взгляд боб Мартин приводит очень много аргументации и старается насколько возможно обосновывать каждое свое утверждение или приводить ссылки намконкретные ситуации. Авторитетное мнение -это когда он бы говорил вот так правильно те я сказал. Но может я заблуждаюсь. Интересно можете привести примеры где он так говорит?
Ну знаете иногда когда кто-то высказывает точку зрения сильно отличную от вашей и при этом является всемирно признанным экспертом, то очень странно так пренебрежительно отзываться о его логике. Не обязательно , конечно, что он любой кто написал пару тройку супер популярных книг не имеет проблемы с логикой, но я бы использовал этот момент чтобы самому призадуматься, а не отмахиваться… а вдруг это я чего-то не понимаю?
Я так понял у вас был алгоритм, который выполнялся в одном потоке с последовательной цепочкой вызовов операций. Вы же оценили зависимости и переделали алгоритм так чтобы какие-то его части выполнялись параллельно. Так? Я понимаю что за счет параллельности это может привести к ускорению каждого отдельного запроса, но вот как это улучшило читабельность кода? По мне так это наоборот должно было существенно усложнить код.
второй вопрос. А что именно вы оптимизировали? Время обработки отдельного запроса (latency) или общую пропускную способность? (Throughput). Если latency, то ок. Но если пропускную способность, то тогда почему просто нельзя было увеличивать число экземпляров сервисов (или потоков) без перехода на параллельность?
Да, на этот счет есть много мнений. Многие считают также как и вы. Но лично я не согласен. Причем мне кажется вы себе противоречите немного.
>> проверяют исключительно то, что кандидат достаточно сильно хочет получить работу в FAANG
не соглашусь, что исключительно это, но само по себе то, что соискатель готов потратить 1,5 мес на подготовку говорит о его мотивации - а это уже немало
также это говорит об умении учится и о том насколько его мозги заточены на решение подобных задач
уверяю вас, что человек, который не имеет особого аналитического/математического склада ума никогда не осилит подготовку к таким интервью. Заучивание будет легко расколото интервьювером.
>> Прохождение таких интервью ничего не говорит о том, способен ли кандидат выполнять реальные задачи в данной компании
как так? если вы согласны со мной что подобные задачи встречаются часто в работе, то значит прохождение таких интервью прямо вот тестирует это.
>> и даже не говорит о том, что он плохо знает алгоритмы и структуры данных!
тут я вообще не понимаю вас! тестирование на DSA ничего не говорит насколько кандидат владеет DSA???
>> И знать их необходимо вовсе не на уровне "разбудите меня ночью и я легко напишу реализацию quick sort, назову её асимптотическую сложность, отличия от merge sort, и дам рекомендацию который из алгоритмов лучше подходит в конкретном частном случае".
вы так говорите, как будто это что-то сложное
это опять из той же серии - если вы не знаете DSA, то вам кажется что их нигде нет и пользы от них никакой. Но вы себе не представляете сколько я видел проблем из-за того, что разработчики не владеют базовыми DSA. Реальный пример: реализация загрузки ФИАС 20 минут против 50 часов. И это не мелочь и не прихоть разработчика олимпиадника, тк просто на два порядка снижает затраты на оборудование и на эксплуатацию.
Я вот когда не знал алгоритмы, то тоже думал, что они нигде не встречаются. А потом после того как в течение нескольких лет серьезно в них погрузился и прокачался с удивлением обнаружил, что они встречаются везде и повсюду. 🤣 по мне так изучение алгоритмов и структур данных - чуть ли не лучшая инвестиция своего времени для разработчика
У нас есть отдельный стенд для НТ (там близкая к боевой конфигурация и больше реплик). На нем мы гоняем тесты двух типов - "быстрый" НТ и обычный НТ.
Скрипты у быстрого и обычного одинаковые и пишутся на https://k6.io/. Быстрый прогоняется за 2 минуты - мы его специально сократили по времени чтобы вставить в пайплайн. Обычный - порядка 10-15 минут.
Наш подход - мы делаем стресс тест по самым основным функциям. Мы не заморачиваемся со специфичными сценариями и не пытаемся угадать профиль нагрузки реальный. Считаем, что в этом нет смысла , тк все равно не сможем и овчинка не стоит выделки. До сих пор наш подход позволял минимальными силами отлавливать основные нагрузочные косяки - не сделали индекс или еще чн в этом роде.
Данные мы генерируем этими же скриптами k6 в рамках самого запуска. Супер толстые базы редко нужны. Этот вопрос решается в индивидуальном порядке.
DevOps инженеры нам настроили всю инфраструктуру, а сами скрипты уже пишутся и поддерживаются самой командой разработки. У нас правило, что задача должна быть сделана под ключ. Если разработчик сделал фичу, но из-за этого у нас падает НТ - это косяк этого разработчика.
В целом НТ - это сложная штука и мы пытаемся держать баланс - с одной стороны чтобы наши накладнгые расходы были минимальные, с другой стороны, чтобы мы находили основные косяки. С другой стороны мы не пытаемся найти все косяки вообще, тк мы можем в случае чего ошибку исправить очень быстро.
У вас слабое представление о функциональности "порталов". Она на два порядка сложнее, чем вы думаете. Вы себе представить не можете каким количеством НПА и ФЗ регулируется работа подобных порталов, что закупок, что торгов. Зайдите почитайте на досуге.
>> Ну да, таких задач команда из 50 туловищ может фигачить по 40 в неделю. И почему вы считаете возможным говорить о нашей команде в таким выражениях?
Нет, присутствуют. Собственно тестирование каждой задачи функциональной делают тестировщики или аналитики (реже). Надо сказать, что тестировщиков у нас сейчас гораздо меньше, чем на предыдущих проектах без схемы DevOps. Раньше у нас было примерно соотношение 8 разработчиков к 10-12 тестировщикам. Сейчас же 8 разработчиков к 2-3 тестировщикам.
вы договариваетесь сначала с разработчиками, что все важные и существенные моменты реализации должны быть покрыты автотестами они начинают их писать (вы можете еще и смотреть на процент покрытия)
вы делаете предположение, что квалификации/компетенции/инструментария/покрытия достаточно чтобы релизить на основе результатов тестов
мы первое время релизы делали всегда после мини-регресса, смотрели сколько у нас регрессионых дефектов и разбирались в их причинах
потом мы увидели, что у нас таких дефектов очень мало и даже те которые есть - с ними вполне можно делать релиз, ну и мы решили попробовать релизится сразу по готовности задачи без регресса
увидели, что ошибок на пролде больше не стало - значит профит!
вот так через постоянный анализ ошибок/ретроспеутивы постепенно вы поймете как писать тесты, чтобы верить им
Я подумал, что может не совсем понял ваш вопрос. У нас тестирование фич делается руками тестировщиков или аналитиков. Мы пока автотестами в большей мере пытаемся сокращать затраты на регрессионное тестирование.
Кстати, есть достаточно продвинутые компании, которые отказались даже от ручного тестирования фич - даже тестирование делает разработчик. Мне кажется это интересная идея для дальнейшей апробации.
Хороший вопрос. Подобная уверенность у вас может возникнуть только на основе статистики и ее анализа. Как мы делаем? Мы собираем разные метрики и анализируем их каждую неделю. Например, одна из метрик - кол-во ошибок с прода. Далее любые изменения в процессах мы анализируем с прицелом влияния на эти метрики. Мы шли постепенно. Сначала у нас был большущий и подробный регресс. Мы подумали, что он избыточен и решили его сократить. Сделали - посмотрели, что у нас ситуация не ухудшилась. Потом мы решили что нас регресс даже такой тормозит, подумали давайте мы будем релизить даже без регресса. Попробовали - оказалось, что негативно не повлияло. и тд и тп. Мы регулярно анализируем регрессионные ошибки и смотрим а почему они возникли и стараемся устранить причину и сделать выводы.
Короче, рецепта готового нет, скорее вы в вашем случае должны методом проб и ошибок найти свой подход.
А по тестам лично я где-то примерно с Бобом Мартином согласен ;-))
это где было две тестовые площадки? в страшной истории? ну там да
сейчас у нас одновременно могу запускаться десятки пайплайнов,
плюс у нас есть основные стенды DEV -> QA -> DEMO1-2 -> KPAK -> PROD
и также есть много (порядка 20) т.н. review стендов - это полнофункциональный стенд, который поднимается из какой-то ветки. Review стенд поднимается минут за 15 для каждого микросервиса и там можно погонять какую-то новую фичу, показать ее аналитику или потестировать изолировано.
В целом мы стремимся минимизировать использования таких review-стендов и по возможности быстрее мержить в мастер, прятать за фича-флагами и уже тестировать на наших основных стендах. Это быстрее и удобнее.
Вопрос в точку. Мы прямо долго над этим думали. Вообще в общем этот вопрос решается через rolling upgrade через кубр/докер + ExpandAndContract , либо никогда не ломать обратную совместимость ни схемы БД, ни API.
Мы поэкспериментировали с Expand & Contract получается очень медленно и дорого. Обратную совместимость тоже невозможно прямо никогда не ломать и постоянно отслеживать. Поэтому мы решили рискнуть и оставить только rolling upgrade ;-)) . По нашей статистике за полгода у нас возникла только одна проблема причем не на уровне БД, а на уровне UI (пользователь загрузил предыдущую версию UI , мы выпустили обновление, которое сломало обратную совместимость backend API и пользователь получил системную ошибку. Однако после рефреша у него все заработало опять). Итого - все оказалось гораздо проще, чем мы думали.
Ну, конечно, в некоторых сложных случаях мы делаем ExpandAndContract по полной программе, например, если нужно внести несовместимые изменения в поисковые индексы и пересобрать их с нуля и тп.
Я думаю, что нам помогает как раз то, что у нас мелкие и частые релизы. Если изменений мало, то тогда меньше шанс что что-то сломается и разработчик может лучше увидеть какие-то риски и что-то предпринять.
Так же нам помогает то, что у нас система разбита на относительно маленькие микросервисы, которые обновляются очень быстро.
Ну вы пишете что он использует подход авторитетное мнение. Этот подход подразумевает, что автор не аргументирует свою позицию, а обосновывает исключительно своим авторитетом.
Ну ок, я понял. То что он использует провокационные стиль мизлодения - тут соглашусь. Но не вижу в этом ничего такого страшного. Суть от этого не меняется.
Вообще -то на мой взгляд боб Мартин приводит очень много аргументации и старается насколько возможно обосновывать каждое свое утверждение или приводить ссылки намконкретные ситуации. Авторитетное мнение -это когда он бы говорил вот так правильно те я сказал. Но может я заблуждаюсь. Интересно можете привести примеры где он так говорит?
Ну знаете иногда когда кто-то высказывает точку зрения сильно отличную от вашей и при этом является всемирно признанным экспертом, то очень странно так пренебрежительно отзываться о его логике. Не обязательно , конечно, что он любой кто написал пару тройку супер популярных книг не имеет проблемы с логикой, но я бы использовал этот момент чтобы самому призадуматься, а не отмахиваться… а вдруг это я чего-то не понимаю?
Я так понял у вас был алгоритм, который выполнялся в одном потоке с последовательной цепочкой вызовов операций. Вы же оценили зависимости и переделали алгоритм так чтобы какие-то его части выполнялись параллельно. Так? Я понимаю что за счет параллельности это может привести к ускорению каждого отдельного запроса, но вот как это улучшило читабельность кода? По мне так это наоборот должно было существенно усложнить код.
второй вопрос. А что именно вы оптимизировали? Время обработки отдельного запроса (latency) или общую пропускную способность? (Throughput). Если latency, то ок. Но если пропускную способность, то тогда почему просто нельзя было увеличивать число экземпляров сервисов (или потоков) без перехода на параллельность?
Позор 🤦♂️
Да, на этот счет есть много мнений. Многие считают также как и вы.
Но лично я не согласен. Причем мне кажется вы себе противоречите немного.
>> проверяют исключительно то, что кандидат достаточно сильно хочет получить работу в FAANG
не соглашусь, что исключительно это, но само по себе то, что соискатель готов потратить 1,5 мес на подготовку говорит о его мотивации - а это уже немало
также это говорит об умении учится и о том насколько его мозги заточены на решение подобных задач
уверяю вас, что человек, который не имеет особого аналитического/математического склада ума никогда не осилит подготовку к таким интервью. Заучивание будет легко расколото интервьювером.
>> Прохождение таких интервью ничего не говорит о том, способен ли кандидат выполнять реальные задачи в данной компании
как так? если вы согласны со мной что подобные задачи встречаются часто в работе, то значит прохождение таких интервью прямо вот тестирует это.
>> и даже не говорит о том, что он плохо знает алгоритмы и структуры данных!
тут я вообще не понимаю вас! тестирование на DSA ничего не говорит насколько кандидат владеет DSA???
>> И знать их необходимо вовсе не на уровне "разбудите меня ночью и я легко напишу реализацию quick sort, назову её асимптотическую сложность, отличия от merge sort, и дам рекомендацию который из алгоритмов лучше подходит в конкретном частном случае".
вы так говорите, как будто это что-то сложное
это опять из той же серии - если вы не знаете DSA, то вам кажется что их нигде нет и пользы от них никакой. Но вы себе не представляете сколько я видел проблем из-за того, что разработчики не владеют базовыми DSA. Реальный пример: реализация загрузки ФИАС 20 минут против 50 часов. И это не мелочь и не прихоть разработчика олимпиадника, тк просто на два порядка снижает затраты на оборудование и на эксплуатацию.
Я вот когда не знал алгоритмы, то тоже думал, что они нигде не встречаются. А потом после того как в течение нескольких лет серьезно в них погрузился и прокачался с удивлением обнаружил, что они встречаются везде и повсюду. 🤣 по мне так изучение алгоритмов и структур данных - чуть ли не лучшая инвестиция своего времени для разработчика
Хорошо, наверное. Не знаю каково это 🤣
У нас есть отдельный стенд для НТ (там близкая к боевой конфигурация и больше реплик). На нем мы гоняем тесты двух типов - "быстрый" НТ и обычный НТ.
Скрипты у быстрого и обычного одинаковые и пишутся на https://k6.io/.
Быстрый прогоняется за 2 минуты - мы его специально сократили по времени чтобы вставить в пайплайн. Обычный - порядка 10-15 минут.
Наш подход - мы делаем стресс тест по самым основным функциям. Мы не заморачиваемся со специфичными сценариями и не пытаемся угадать профиль нагрузки реальный. Считаем, что в этом нет смысла , тк все равно не сможем и овчинка не стоит выделки. До сих пор наш подход позволял минимальными силами отлавливать основные нагрузочные косяки - не сделали индекс или еще чн в этом роде.
Данные мы генерируем этими же скриптами k6 в рамках самого запуска.
Супер толстые базы редко нужны. Этот вопрос решается в индивидуальном порядке.
DevOps инженеры нам настроили всю инфраструктуру, а сами скрипты уже пишутся и поддерживаются самой командой разработки. У нас правило, что задача должна быть сделана под ключ. Если разработчик сделал фичу, но из-за этого у нас падает НТ - это косяк этого разработчика.
В целом НТ - это сложная штука и мы пытаемся держать баланс - с одной стороны чтобы наши накладнгые расходы были минимальные, с другой стороны, чтобы мы находили основные косяки. С другой стороны мы не пытаемся найти все косяки вообще, тк мы можем в случае чего ошибку исправить очень быстро.
У вас слабое представление о функциональности "порталов". Она на два порядка сложнее, чем вы думаете. Вы себе представить не можете каким количеством НПА и ФЗ регулируется работа подобных порталов, что закупок, что торгов. Зайдите почитайте на досуге.
>> Ну да, таких задач команда из 50 туловищ может фигачить по 40 в неделю.
И почему вы считаете возможным говорить о нашей команде в таким выражениях?
Нет, присутствуют. Собственно тестирование каждой задачи функциональной делают тестировщики или аналитики (реже). Надо сказать, что тестировщиков у нас сейчас гораздо меньше, чем на предыдущих проектах без схемы DevOps. Раньше у нас было примерно соотношение 8 разработчиков к 10-12 тестировщикам. Сейчас же 8 разработчиков к 2-3 тестировщикам.
статистикой и анализом своих неудач
вы договариваетесь сначала с разработчиками, что все важные и существенные моменты реализации должны быть покрыты автотестами
они начинают их писать (вы можете еще и смотреть на процент покрытия)
вы делаете предположение, что квалификации/компетенции/инструментария/покрытия достаточно чтобы релизить на основе результатов тестов
мы первое время релизы делали всегда после мини-регресса, смотрели сколько у нас регрессионых дефектов и разбирались в их причинах
потом мы увидели, что у нас таких дефектов очень мало и даже те которые есть - с ними вполне можно делать релиз, ну и мы решили попробовать релизится сразу по готовности задачи без регресса
увидели, что ошибок на пролде больше не стало - значит профит!
вот так через постоянный анализ ошибок/ретроспеутивы постепенно вы поймете как писать тесты, чтобы верить им
Очень интересно. Расскажите про ваш опыт! Что за проект вкратце. Сколько делали релизов в день? Была ли от этого польза?
Я подумал, что может не совсем понял ваш вопрос. У нас тестирование фич делается руками тестировщиков или аналитиков. Мы пока автотестами в большей мере пытаемся сокращать затраты на регрессионное тестирование.
Кстати, есть достаточно продвинутые компании, которые отказались даже от ручного тестирования фич - даже тестирование делает разработчик. Мне кажется это интересная идея для дальнейшей апробации.
Хороший вопрос. Подобная уверенность у вас может возникнуть только на основе статистики и ее анализа.
Как мы делаем? Мы собираем разные метрики и анализируем их каждую неделю. Например, одна из метрик - кол-во ошибок с прода.
Далее любые изменения в процессах мы анализируем с прицелом влияния на эти метрики.
Мы шли постепенно. Сначала у нас был большущий и подробный регресс. Мы подумали, что он избыточен и решили его сократить. Сделали - посмотрели, что у нас ситуация не ухудшилась. Потом мы решили что нас регресс даже такой тормозит, подумали давайте мы будем релизить даже без регресса. Попробовали - оказалось, что негативно не повлияло. и тд и тп.
Мы регулярно анализируем регрессионные ошибки и смотрим а почему они возникли и стараемся устранить причину и сделать выводы.
Короче, рецепта готового нет, скорее вы в вашем случае должны методом проб и ошибок найти свой подход.
А по тестам лично я где-то примерно с Бобом Мартином согласен ;-))
Спросил у саппорта, они говорят таких предложений пока не было. Напишите в саппорт обращение с типом вопрос.
Саппорт у нас рассматривают с Заказчиком все такие обращения, если посчитают нужным - сделаем.
это где было две тестовые площадки? в страшной истории? ну там да
сейчас у нас одновременно могу запускаться десятки пайплайнов,
плюс у нас есть основные стенды DEV -> QA -> DEMO1-2 -> KPAK -> PROD
и также есть много (порядка 20) т.н. review стендов - это полнофункциональный стенд, который поднимается из какой-то ветки. Review стенд поднимается минут за 15 для каждого микросервиса и там можно погонять какую-то новую фичу, показать ее аналитику или потестировать изолировано.
В целом мы стремимся минимизировать использования таких review-стендов и по возможности быстрее мержить в мастер, прятать за фича-флагами и уже тестировать на наших основных стендах. Это быстрее и удобнее.
а что у вас за специфика, что у вас высокие инфраструктурные затраты?
Я вот решил не рекомендовать Непрерывную поставку - уж очень старая она, читать тяжело, много чего устарело. Я так и не осилил.
Aссelerate, да, хорошая книга, можно рекомендовать как некоторый обзор.
Вопрос в точку. Мы прямо долго над этим думали. Вообще в общем этот вопрос решается через rolling upgrade через кубр/докер + ExpandAndContract , либо никогда не ломать обратную совместимость ни схемы БД, ни API.
Мы поэкспериментировали с Expand & Contract получается очень медленно и дорого. Обратную совместимость тоже невозможно прямо никогда не ломать и постоянно отслеживать. Поэтому мы решили рискнуть и оставить только rolling upgrade ;-)) . По нашей статистике за полгода у нас возникла только одна проблема причем не на уровне БД, а на уровне UI (пользователь загрузил предыдущую версию UI , мы выпустили обновление, которое сломало обратную совместимость backend API и пользователь получил системную ошибку. Однако после рефреша у него все заработало опять). Итого - все оказалось гораздо проще, чем мы думали.
Ну, конечно, в некоторых сложных случаях мы делаем ExpandAndContract по полной программе, например, если нужно внести несовместимые изменения в поисковые индексы и пересобрать их с нуля и тп.
Я думаю, что нам помогает как раз то, что у нас мелкие и частые релизы. Если изменений мало, то тогда меньше шанс что что-то сломается и разработчик может лучше увидеть какие-то риски и что-то предпринять.
Так же нам помогает то, что у нас система разбита на относительно маленькие микросервисы, которые обновляются очень быстро.