Комментарии 18
Аналогичные вещи хотелось рассказать. Как раз побывал в компании, которая находится примерно там же, где вы были в 2009 в плане организации процессов. И, похоже, все наступают примерно на один и тот же набор грабелек. Это и печально, и хорошо. Печально — многих проблем не удастся избежать. Хорошо — такая стратегия развития может привести к успеху.
А вы пишите «тыкалки»?
Вот Алексей сказал, что ему не понравилось бы работать в support, поэтому отдельного support-а нет. И ещё сказал что есть отдельная команда мониторинга. Как вы формируете команду мониторинга? Если ли люди, которым это нравится?
Сейчас не обладаю полной информацией, к сожалению. Что могу сказать: проект у нас очень большой и триггеров/чеков просто огромное количество, как раз совсем недавно мы превысили некоторую критическую массу плотности событий, это создает определенное давление на команду, но мы боремся. У нас смена всего один-два человека. Касательно формирования: «стандартный» рекрутинг обеспечил примерно треть, две трети — знакомые. Насчет того, нравится народу или нет — у ребят разные навыки и стремления, кто-то доволен, кто-то вообще хочет стать программистом, кто-то ещё выполняет админские задания и хочет стать админом — я думаю, что у каждого своё видение. Времени прошло мало, чтобы сделать выводы. Важно: если без саппорта можно обойтись, то без мониторинга — нельзя. Так что так или иначе роль «расставлять триггеры, втыкать в дашборды и быстро реагировать на проблемы» — такая роль должна быть всегда.
А с виду все просто ) Поиск, профиль, фотки… что же вы там обсчитываете на тестировании или вы мощную статистику собираете по пользователям и поведению, считаете каждый чих? анализируете?
У нас пара-тройка миллиона разных временных рядов для анализа — это не считая метрики ITOPS типа по десяток на сервак умножить на пару тысяч серверов ;) Приведу один простой пример. У нас есть отдел биллинга. Это примерно 1/10 нашей девелоперской мощности. У ребят задача — покрыть платежами все страны (есть статья в этом блоге). По миру вариантов взять денег — очень много. Там где-то сто различных интеграций (подробнее может рассказать кто-то из биллинга). Каждая интеграция — это фактически отдельный софт на встраивание конторой-агрегатором, например. Если что-то где-то не работает — у нас убытки типа десятки тысяч нерублей в час.
Все так, только интеграций не 100, а штук 30-40 сейчас. В этом году будет еще меньше. Мы начали отказываться от старых СМС партнеров представленных в одной-двух странах в пользу более крупных. Но собираемых данных всеравно много. Один мониторинг биллинга обсчитывал столько данных что его пришлось отселять на отдельную машину, иначе мы съедали там все ресурсы и мешали другим командам.
Для примера, у нас есть внутренняя валюты Badoo кредиты. Для мониторинга покупок мы строим 5 разных графиков (разбивка по типам оплаты, по размеру купленного пакета, новые покупки или обвноление подписки и т.п.), следить нам нужно во всех странах, которых помоему сейчас 250 штук и плюс собирать все эти метрики для каждого типа приложений которые у нас есть (web, wap, html5, android, ios, windows phone, blackberry).
Итого: 5 разных метрик * 250 стран * 7 приложений = 8750 графиков. И это только маленькая часть :)
Для примера, у нас есть внутренняя валюты Badoo кредиты. Для мониторинга покупок мы строим 5 разных графиков (разбивка по типам оплаты, по размеру купленного пакета, новые покупки или обвноление подписки и т.п.), следить нам нужно во всех странах, которых помоему сейчас 250 штук и плюс собирать все эти метрики для каждого типа приложений которые у нас есть (web, wap, html5, android, ios, windows phone, blackberry).
Итого: 5 разных метрик * 250 стран * 7 приложений = 8750 графиков. И это только маленькая часть :)
Меня, например, просто бесит, когда за меня начинают решать и давать дебильные советы. «Вы точно уверены, что хотите познакомиться со всеми?» Был бы я помоложе, так непременно б написал: «Что бы вас ночью жена спрашивала на пике страсти — вы точно хотите именно сюда?!»
«Будьте осторожны, чтобы не сказать да тому, кому не хотели этого говорить!»
Друзья! Товарищи! Сукины дети! Да ежику понятно, что на вашем сайте народу дохрена. Отсюда наиболее правильная стратегия — не выбирать среди одной-другой, а скопом куче женщин поставить «ты мне нравишься» — и уже среди откликнувшихся начать выбирать, такое вот примитивное сито. И ваши попытки заработать денег за 400 дополнительных откликов если еще понятны, то вот это крайне анноящие запросы, уверен ли я, быть ли мне осторожным… Словом, щастья вам и удачи в творчестве.
«Будьте осторожны, чтобы не сказать да тому, кому не хотели этого говорить!»
Друзья! Товарищи! Сукины дети! Да ежику понятно, что на вашем сайте народу дохрена. Отсюда наиболее правильная стратегия — не выбирать среди одной-другой, а скопом куче женщин поставить «ты мне нравишься» — и уже среди откликнувшихся начать выбирать, такое вот примитивное сито. И ваши попытки заработать денег за 400 дополнительных откликов если еще понятны, то вот это крайне анноящие запросы, уверен ли я, быть ли мне осторожным… Словом, щастья вам и удачи в творчестве.
да хоть обминусуйтесь, ребята, а я свое мнение выскажу. :) Назойливость и навязчивость — никогда не были признаком хорошей разработки, если же вам это нравится — поставьте мне еще 100500 минусов.
Вы немного ошиблись, тут обсуждаются технические вопросы в основном, а что до пользователей, я думаю разработчики на этот счет не сильно напрягаются, есть руководство продукт менеджеры и прочие товарищи, которым «виднее». К ним и нужно адресовать эти вопросы и критику.
Да путь байды не прост и эта вся история мне многое объясняет.
Однако, интересно было бы узнать что означает 210-0009 и когда вы уже выпилите ботов (и мне закажут новых, шута :-) ну и на мелкие территории вы походу вообще забили, там чёрти что твориться. И это даже не глюки байды, нет это косячная логика…
Однако, интересно было бы узнать что означает 210-0009 и когда вы уже выпилите ботов (и мне закажут новых, шута :-) ну и на мелкие территории вы походу вообще забили, там чёрти что твориться. И это даже не глюки байды, нет это косячная логика…
Спасибо, довольно интересно.
1. В чем заключалась ошибка, что Алексей занимался наймом людей? Брал не тех людей, или просто время тратилось не на приоритетные задачи?
2. Selenium тесты учитываются в code coverage?
3. Selenium тесты вы пишете на основе сценариев действий пользователя? Или это просто страничка и ее начинаем гонять и так и сяк?
1. В чем заключалась ошибка, что Алексей занимался наймом людей? Брал не тех людей, или просто время тратилось не на приоритетные задачи?
2. Selenium тесты учитываются в code coverage?
3. Selenium тесты вы пишете на основе сценариев действий пользователя? Или это просто страничка и ее начинаем гонять и так и сяк?
1. До 50% на кадровые вещи, включая отсмотр соц-сетей, пингование людей, телефонное интервью — короче, рекрутинг, самая затратная часть всего времени компании на найм — это очень много времени, его можно было потратить с большей пользой для проекта. Тут было два решения: активный пиар (чтобы был поток извне, сами люди приходили) + отстраивание HR и перекладывание рекрутинговой части на него. Был заход в кадровые агенства, девочки хорошие, но в целом выхлоп слабый, мы — неудобный клиент с очень высокими запросами, зарабатывать на нас сложно. 2. Нет, нам важно чтобы юниты покрывали. 3. сценариев. Возможно по 2-3 ещё кто-то из тестирования добавит.
Спасибо за вопросы про тестирование!
2. Покрытие кода селениум-тестами нами оценивается, но это немного не то, что принято понимать под остальным покрытием. Именно поэтому Алексей ответил «Нет». Попробую объяснить позицию подробнее.
Если брать юнит-тесты для примера, то там покрытие совершенно четко можно считать по строкам, выполненным во время прогона теста. Немного про то, как мы это считаем, я уже писал. Для селениум-тестов, как впрочем и для любых тестов более высокого уровня, это будет неправдой. Потому что даже после простого открытия страницы в браузе уже выполнится немало строк кода, которые посчитаются покрытыми тестом, хотя это не так. Поэтому для селениум-тестов мы делаем оценку покрытия «по фичам». Т.е. по участкам функционала сайта. Понятно что такое покрытие сложно считать автоматически, поэтому мы этого и не делаем, хотя объединение покрытия юнит-тестов и интеграционных тестов кажется логичным на первый взгляд.
3. Да, на основе сценариев. Это тесно связано с предыдущим пунктом: берется раздел сайта или «фича» и покрывается тестом. Практикуем как позитивные сценарии (в большем приоритете), так и негативные (в меньшем приоритете). Например пытаемся зарегистрироваться на сайте, в том числе мурными и невалидными данными с проверкой на спецсимволы, обход авторизации, получение писем подтверждения, переход и инвалидация ссылок из письма и проч. Таким образом у нас покрывается «фича» Регистрация Пользователя.
2. Покрытие кода селениум-тестами нами оценивается, но это немного не то, что принято понимать под остальным покрытием. Именно поэтому Алексей ответил «Нет». Попробую объяснить позицию подробнее.
Если брать юнит-тесты для примера, то там покрытие совершенно четко можно считать по строкам, выполненным во время прогона теста. Немного про то, как мы это считаем, я уже писал. Для селениум-тестов, как впрочем и для любых тестов более высокого уровня, это будет неправдой. Потому что даже после простого открытия страницы в браузе уже выполнится немало строк кода, которые посчитаются покрытыми тестом, хотя это не так. Поэтому для селениум-тестов мы делаем оценку покрытия «по фичам». Т.е. по участкам функционала сайта. Понятно что такое покрытие сложно считать автоматически, поэтому мы этого и не делаем, хотя объединение покрытия юнит-тестов и интеграционных тестов кажется логичным на первый взгляд.
3. Да, на основе сценариев. Это тесно связано с предыдущим пунктом: берется раздел сайта или «фича» и покрывается тестом. Практикуем как позитивные сценарии (в большем приоритете), так и негативные (в меньшем приоритете). Например пытаемся зарегистрироваться на сайте, в том числе мурными и невалидными данными с проверкой на спецсимволы, обход авторизации, получение писем подтверждения, переход и инвалидация ссылок из письма и проч. Таким образом у нас покрывается «фича» Регистрация Пользователя.
Спасибо за развернутый ответ.
А что думаете по поводу функциональных тестов в Symfony? Там что-то наподобии Selenium, но хорошо интегрировано в сам framework. Можно моки делать и т.п. Смотрели в эту сторону?
Насчет «которые посчитаются покрытыми тестом, хотя это не так» — на мой взгляд лучше покрыть что-то хоть как-то, чем вообще никак. Там человек в секции вопросов говорил про это, что их unit тесты ловят меньше чем тесты Selenium. Там в докладе звучали цифры по покрытию, если учитывать и Selenium тесты, то какое покрытие получается? Или тяжело это подсчитать?
Unit тесты нужны скорее для участков кода, которые реализуют какие-то алгоритмы, критичные участки кода, то же ядро. Я сейчас работаю с symfony, и покрываю тестами код, в итоге не вижу смысла покрывать unit тестами код например извлечения данных из базы, проще загрузить страничку со списком, который извлекается из базы и там посмотреть что все ок, заодно проверить другое множество параметров. В итоге тесты пишутся легче, быстрее и имеют хорошее покрытие. Порочная практика, или для небольших проектов без особого rocket science проблем потом не поимею?
А что думаете по поводу функциональных тестов в Symfony? Там что-то наподобии Selenium, но хорошо интегрировано в сам framework. Можно моки делать и т.п. Смотрели в эту сторону?
Насчет «которые посчитаются покрытыми тестом, хотя это не так» — на мой взгляд лучше покрыть что-то хоть как-то, чем вообще никак. Там человек в секции вопросов говорил про это, что их unit тесты ловят меньше чем тесты Selenium. Там в докладе звучали цифры по покрытию, если учитывать и Selenium тесты, то какое покрытие получается? Или тяжело это подсчитать?
Unit тесты нужны скорее для участков кода, которые реализуют какие-то алгоритмы, критичные участки кода, то же ядро. Я сейчас работаю с symfony, и покрываю тестами код, в итоге не вижу смысла покрывать unit тестами код например извлечения данных из базы, проще загрузить страничку со списком, который извлекается из базы и там посмотреть что все ок, заодно проверить другое множество параметров. В итоге тесты пишутся легче, быстрее и имеют хорошее покрытие. Порочная практика, или для небольших проектов без особого rocket science проблем потом не поимею?
По поводу симфони: мы бы вероятно смотрели в эту сторону, если бы использовали этот фреймворк в работе. Равно как и любой другой фреймворк. Но поскольку для написания кода сайта наши программисты ничего кроме самописного фреймворка не используют, то мы не стали рассматривать «фреймворки для разработки с возможностью написания тестов» и выбрали фреймворк для тестов — phpUnit. На нем мы пишем сейчас все виды тестов, кроме тестов для клиентов мобильных приложений из-за понятных ограничений. Для моков (в том числе БД) используем самописные классы, стандартные phpUnit'овские моки почти не используем. Причина в том, что код наш изначально не писался так, чтобы быть тестируемым, благодаря чему не везде есть возможность использовать классические подходы к мокам/стабам. Я планирую написать статью про это.
«Там в докладе звучали цифры по покрытию, если учитывать и Selenium тесты, то какое покрытие получается? Или тяжело это подсчитать?» — это действительно тяжело посчитать, т.к. при таком подсчете получится сравнивание несравнимых категорий. Выше я описал почему. Если же использовать оценку «по фичам», то процентов 70 «фич» на сайте у нас покрыто селениум-тестами и мы ежедневно стремимся к увеличению.
В идеальном мире, в котором пишут книжки про юнит-тестирование, говорят о том, что тестировать надо в том числе и метод извлечения данных из базы из приведенного вами примера. Любой юнит должен быть покрыт тестом. Мы же живем в реальном мире, где нет идеала к сожалению. Где код изначально редко проектируется с оглядкой на тестирование (стартап же, ё-маё, взлетит — напишем тесты!!11), где редко можно наблюдать тот же пресловутый MVC (например), а скорее некий эрзац и проч., и проч.
Поэтому даже если очень сильно захотеть, редко получается следовать рекомендациям умов великих, и приходится изобретать очередной велосипед с квадратными колесами. И часто приходится идти на компромиссы в том или ином случае, что оправдано. Ведь вы для чего пишете тесты? Чтобы было красиво? Потому что где-то прочитали что так правильно? Я уверен что нет. Вы их пишете чтобы тестировать свой код. И до тех пор, пока ваши тесты справляются с поставленной задачей, вы имеете полное право считать имеющиеся тесты хорошими.
«Там в докладе звучали цифры по покрытию, если учитывать и Selenium тесты, то какое покрытие получается? Или тяжело это подсчитать?» — это действительно тяжело посчитать, т.к. при таком подсчете получится сравнивание несравнимых категорий. Выше я описал почему. Если же использовать оценку «по фичам», то процентов 70 «фич» на сайте у нас покрыто селениум-тестами и мы ежедневно стремимся к увеличению.
В идеальном мире, в котором пишут книжки про юнит-тестирование, говорят о том, что тестировать надо в том числе и метод извлечения данных из базы из приведенного вами примера. Любой юнит должен быть покрыт тестом. Мы же живем в реальном мире, где нет идеала к сожалению. Где код изначально редко проектируется с оглядкой на тестирование (стартап же, ё-маё, взлетит — напишем тесты!!11), где редко можно наблюдать тот же пресловутый MVC (например), а скорее некий эрзац и проч., и проч.
Поэтому даже если очень сильно захотеть, редко получается следовать рекомендациям умов великих, и приходится изобретать очередной велосипед с квадратными колесами. И часто приходится идти на компромиссы в том или ином случае, что оправдано. Ведь вы для чего пишете тесты? Чтобы было красиво? Потому что где-то прочитали что так правильно? Я уверен что нет. Вы их пишете чтобы тестировать свой код. И до тех пор, пока ваши тесты справляются с поставленной задачей, вы имеете полное право считать имеющиеся тесты хорошими.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Эволюция разработки в Badoo