Ознакомились бы сначала с практикой non-compete, которая существует практически во всех передовых странах, а потом бы уж приходили сюда глупости писать. Или эта история про повара реально имела место где-то вне вашего воображения? Тогда жду пруф.
Речь еще может идти о том, что нельзя переманивать к себе инвесторов, клиентов и коллег из своей бывшей компании. Всех этих людей привлекала именно компания, а вы получили их контакты по служебной необходимости.
Цивилизованность в том, что вы договариваетесь на берегу, перед тем, как устроиться на работу. Если вам не нравятся условия — просто идете в другое место.
Увольняюсь… И иду дворником работать? Ведь за эти пару лет я делал в компании всё что умею и сейчас любые попытки мои знания использовать пересекаются с этой компанией…
Ну да, очень жизненная ситуация, конечно. Устроился в контору тестить игру с танками, поработал 2 года, а потом либо тестить другую игру с танками, либо дворником — прямо безвыходная ситуация! Потестить игру с гномиками вместо танков, или вообще не игру скила очевидно не хватит.
Простите, а что факт того, что люди ушли к конкуренту делать конкурирующий продукт нарушает законодательство? Или, по вашему, если кто-то устроился работать в WG, он теперь до конца жизни им обязан и ни в коем случае не должен больше до конца жизни работать на конкурентов?
Понимаю ваш священный гнев, но ничего такого я в своем комментрии и не утверждал.
Это, по сути, и есть тот самый факт, который вы не заметили.
Т.е. вы опровергли мое "небогато на факты" целым одним фактом, это круто. Не знаю как вас, а вот меня очень порадовал скриншот 82-го пункта 41-ой страницы какого-то документа, типа "злиться и негодовать сюда". Что там за остальные 40 страниц и 80 пунктов — мы вам не покажем.
У нас не принято сотрудникам что-то платить, и к счастью ТК препятствует тому, что их хотят что-то обязать делать
В этом наверное и проблема. Плати — не плати, обязать не сможешь. Поэтому все сводится к "джентельменским соглашениям", которые можно и не соблюдать, особенно если расстались по-плохому.
Да, насколько я понимаю, в наших юрисдикциях соглашения о том, что работник не будет в течении какого-то времени после увольнения конкурировать с работодателем — ничтожны. Хотя это был бы вполне цивилизованный способ предотвращения ровно таких ситуаций.
Кстати, какая разница какого размера компания, из которой увели команду разработчиков?
От крупной конторы, очевидно, надо ожидать больших проблем. Странно видеть такие эмоциональные жалобы в статье. Неужели они не понимали этого с самого начала?
То что случилось с нами, может случиться с любой командой, которая не поладила с начальством в WG и решила уйти делать свой продукт.
Хмм… увести команду из крупной компании и начать делать конкурирующий продукт, а потом удивляться, что крупной компании это не понравилось? Это надо быть либо невероятно наивными, либо рассчитывать на наивность читателей этого крайне эмоционального, но почему-то небогатого на факты опуса.
Имхо, здесь конфликт жабы с гадюкой, поданный как борьба добра со злом.
Имея связку паспорт + образец голоса, вас можно идентифицировать не просто на любой симке, но и вообще на любой аудиозаписи, включая голосовые звонки в мессенджерах. Вопрос в том, как заставить людей добровольно регистрировать образцы голоса. Вот, придумали, чтобы нельзя было купить симку без этого.
Разработка должна ориентироваться на продакшен, всё остальное — чушь
Меры QA снижают качество
Ну вот да, в этом и дело!
Оригинальная статья называется "Production Oriented Development", про "чушь" — это изобретение переводчика
Глава 5 называется "QA Gates Make Quality Worse", никаких "мер", автор всю главу говорит, что QA не должны стоять как ворота между девелопером и продом, а должны стоять где-то сбоку
А вы посмотрите на количество комментариев под этой статьёй...
Ну да, люди клюнули на чуть провокационный заголовок, а потом тригернулись на какие-то рандомные словосочетания из статьи — вот откуда такие комментарии. Большая часть возмущающихся (как и вы в первом комментарии) решила, что он призывает нифига не тестить и сразу в прод. А статья вообще-то про максимальную автоматизацию и сокращение релизного цикла, про то, что мониторинг так же важен или даже важнее qa, что стейдж в принципе никогда не может быть равен проду и т.п.
Мне кажется, вы здесь больше спорите с мыслями в своей голове, чем с обсуждаемой статьей.
В главе 5 автор ставит знак равенства между ручным тестированием и отделом QA
Ну если почитать только первое предложение этой главы, то да. Но если осилить хотя бы второе — там уже про ручной запуск автотестов, например.
Если отказаться от ручного тестирования специально обученными людьми, а автотесты запускать на CI, чем конкретно должен заниматься отдел QA? Писать тесты вместо девелоперов?
Хороший QA инженер умеет всё то же самое, что и девелопер
Не видел в жизни ни одного QA, который мог бы например, написать Spark-джобу или хотя бы бекенд на Akka Http. Наверное, эти легендарные "Хорошие QA" так же редки, как единороги.
Если говорить серьезно, очень странно требовать от QA тех же умений, что и от девелопера. Это разные специальности для решения разных задач.
а потом приходят вялые QA инженеры и всё портят своей тупизной
В статье такого нет.
В идеальной вселенной разработчики умеют во все эти этапы
Опять-таки, такого нигде не утверждается.
он целенаправленно ставит себя напротив сообщества с целью показать "вы все дураки, один я Д'Артаньян"
Почему вы так решили?
Наличие staging, dev-окружения, релизов, QA инженеров и т.п. никак не говорит о том, что у сервиса длительный цикл доставки
Ну да, довольно часто встречаются такие проекты, где стейдж вроде как есть для галки, но по факту туда никто не смотрит, и все изменения транзитом попадают в прод. Можно либо навязать больше бюрократии и процедур, что приведет к удлинению цикла поставки, либо просто дропнуть стейдж и радоваться жизни. Бизнес решает, что ему важнее.
Ну вот например сейчас сбер переходит на новый интерфейс, и там есть опция переключиться на старый. До этого, видимо, была опция "заценить новый интерфейс". Это довольно типовая практика для крупных веб-сервисов.
Мелкие веб-сервисы тоже наверно бы так делали, но поддерживать несколько версий в рабочем состоянии — это сильно дороже, чем только одну актуальную. Готов ли будет пользователь заплатить за возможность такого выбора? Возможно, те, кто пытался так делать, просто отсеялись естественным отбором.
Ведь для реализации подхода, описанного автором нужно убрать QA и заменить их разработчиками, которые умеют хорошо тестировать на проде.
Идея не в том, что разработчики становятся на полставки QA и начинают тестировать код на проде :) Идея в том, что разработчики пишут тесты, которые прогоняются на CI перед каждым деплоем.
разделение на QA и разработку оно не просто так произошло
Ручное тестирование само по себе может закрыть далеко не все классы потенциальных багов, тем более если оно проводится в фейковом окружении. Частично эти же классы багов можно закрыть юнит-тестами, интеграционными тестами и автоматизированными тестами интерфейса.
А дальше бизнес просто считает, насколько важны эти классы ошибок для него, и что выгоднее в перспективе: ручной тестер или напрягать девелоперов на автоматизацию.
Ничего удивительного. Таким подходом сейчас пользуются примерно все от операционных систем до игр, в том числе и языки программирования, фреймворки и IDE — для всего этого публикуются альфа-, бета-версии, релиз-кандидаты, превью, найтли, снепшоты. Зачем по-вашему? Если что-то делается для людей, желание услышать фидбек от этих людей как можно раньше — это нормально.
концепция разработки так себе, она годится разве что для проекта на старте, когда цена ошибки мизерная, или же когда проект еще вообще не стартовал, а только готовится
Вообще, ровно наоборот. На ранней стадии проекта фичи резко появляются и исчезают, API очень быстро меняется и так далее. Писать на это тесты — слишком большой оверхед и потеря гибкости. Тут как раз ручное тестирование решает.
Когда проект уже устаканился, проще автоматизировать тесты — это и надежнее, чем гонять вручную по одним и тем же кейсам изо дня в день, и заодно позволяет сократить время поставки.
Мне не хотелось бы с каждым серверным или клиентским релизом быть подопытной мышкой и ждать подлянки в виде плохо протестированных багов.
Во-первых, противопоставление короткого цикла поставки и хорошо протестированных багов — это как раз и есть пример "ложной дихотомии". Деплой изменений непосредственно в прод не означает, что они перед этим не должны тестироваться. Ровно как и наличие дева, стейджа и пре-прода с армией тестеров не означает, что тестирование будет сделано хорошо. Об этом сказано в статье в разделе "5. Меры QA снижают качество".
Во-вторых, чего бы вам не хотелось больше: один раз наступить на баг, описать его в саппорт и больше никогда с ним не столкнуться, или наступать на один и тот же известный (и уже давно пофикшеный в коде) баг регулярно, потому что у сервиса длительный цикл поставки?
Хорошая статья, хоть перевод и подпортил слегка впечатление.
Мне довелось как-то работать над одним довольно крупным сервисом по описанным принципам. Не было стейджа и тестеров. Каждый девелопер сам тестировал свои изменения, деплоил сразу на прод и, если что, сам откатывал. Такой подход побуждает более ответственно относиться к тому, что ты написал, тщательно продумавать все корнер кейсы, подкладывать соломинки во все возможные места. И это неплохо работало: частота деплоев на прод — десятки в день, частота откатов — единицы в месяц. Причем последствия ошибок в коде как правило довольно локальны, в отличие от ошибок в настройках инфраструктуры, из-за которых может развалиться вообще все.
Понятно, что этот подход никогда не будет применяться, например, для банковских сервисов. Там цена ошибки велика, и доступ всех девелоперов и тестеров к проду сам по себе является риском.
Очень крутая статья, спасибо! Приятно знать, что Akka способна на такое. Не могу удержаться от того, чтобы не задать несколько технических вопросов:
Используете ли вы in-memory кеши типа Caffeine?
Используете ли вы off-heap memory, чтобы съэкономить на GC?
Используете ли вы пуллы объектов, чтобы экономить на аллокациях?
Достаточно часто Akka тянет за собой переход на Scala. Использование Java — это было какое-то технически обоснованное решение, или просто особенность скиллсета разработчиков?
Ознакомились бы сначала с практикой non-compete, которая существует практически во всех передовых странах, а потом бы уж приходили сюда глупости писать. Или эта история про повара реально имела место где-то вне вашего воображения? Тогда жду пруф.
Речь еще может идти о том, что нельзя переманивать к себе инвесторов, клиентов и коллег из своей бывшей компании. Всех этих людей привлекала именно компания, а вы получили их контакты по служебной необходимости.
Цивилизованность в том, что вы договариваетесь на берегу, перед тем, как устроиться на работу. Если вам не нравятся условия — просто идете в другое место.
Ну да, очень жизненная ситуация, конечно. Устроился в контору тестить игру с танками, поработал 2 года, а потом либо тестить другую игру с танками, либо дворником — прямо безвыходная ситуация! Потестить игру с гномиками вместо танков, или вообще не игру скила очевидно не хватит.
Понимаю ваш священный гнев, но ничего такого я в своем комментрии и не утверждал.
Т.е. вы опровергли мое "небогато на факты" целым одним фактом, это круто. Не знаю как вас, а вот меня очень порадовал скриншот 82-го пункта 41-ой страницы какого-то документа, типа "злиться и негодовать сюда". Что там за остальные 40 страниц и 80 пунктов — мы вам не покажем.
В этом наверное и проблема. Плати — не плати, обязать не сможешь. Поэтому все сводится к "джентельменским соглашениям", которые можно и не соблюдать, особенно если расстались по-плохому.
Да, насколько я понимаю, в наших юрисдикциях соглашения о том, что работник не будет в течении какого-то времени после увольнения конкурировать с работодателем — ничтожны. Хотя это был бы вполне цивилизованный способ предотвращения ровно таких ситуаций.
От крупной конторы, очевидно, надо ожидать больших проблем. Странно видеть такие эмоциональные жалобы в статье. Неужели они не понимали этого с самого начала?
Хмм… увести команду из крупной компании и начать делать конкурирующий продукт, а потом удивляться, что крупной компании это не понравилось? Это надо быть либо невероятно наивными, либо рассчитывать на наивность читателей этого крайне эмоционального, но почему-то небогатого на факты опуса.
Имхо, здесь конфликт жабы с гадюкой, поданный как борьба добра со злом.
Имея связку паспорт + образец голоса, вас можно идентифицировать не просто на любой симке, но и вообще на любой аудиозаписи, включая голосовые звонки в мессенджерах. Вопрос в том, как заставить людей добровольно регистрировать образцы голоса. Вот, придумали, чтобы нельзя было купить симку без этого.
Ну вот да, в этом и дело!
Ну да, люди клюнули на чуть провокационный заголовок, а потом тригернулись на какие-то рандомные словосочетания из статьи — вот откуда такие комментарии. Большая часть возмущающихся (как и вы в первом комментарии) решила, что он призывает нифига не тестить и сразу в прод. А статья вообще-то про максимальную автоматизацию и сокращение релизного цикла, про то, что мониторинг так же важен или даже важнее qa, что стейдж в принципе никогда не может быть равен проду и т.п.
Мне кажется, вы здесь больше спорите с мыслями в своей голове, чем с обсуждаемой статьей.
Ну если почитать только первое предложение этой главы, то да. Но если осилить хотя бы второе — там уже про ручной запуск автотестов, например.
Если отказаться от ручного тестирования специально обученными людьми, а автотесты запускать на CI, чем конкретно должен заниматься отдел QA? Писать тесты вместо девелоперов?
Не видел в жизни ни одного QA, который мог бы например, написать Spark-джобу или хотя бы бекенд на Akka Http. Наверное, эти легендарные "Хорошие QA" так же редки, как единороги.
Если говорить серьезно, очень странно требовать от QA тех же умений, что и от девелопера. Это разные специальности для решения разных задач.
В статье такого нет.
Опять-таки, такого нигде не утверждается.
Почему вы так решили?
Ну да, довольно часто встречаются такие проекты, где стейдж вроде как есть для галки, но по факту туда никто не смотрит, и все изменения транзитом попадают в прод. Можно либо навязать больше бюрократии и процедур, что приведет к удлинению цикла поставки, либо просто дропнуть стейдж и радоваться жизни. Бизнес решает, что ему важнее.
Ну вот например сейчас сбер переходит на новый интерфейс, и там есть опция переключиться на старый. До этого, видимо, была опция "заценить новый интерфейс". Это довольно типовая практика для крупных веб-сервисов.
Мелкие веб-сервисы тоже наверно бы так делали, но поддерживать несколько версий в рабочем состоянии — это сильно дороже, чем только одну актуальную. Готов ли будет пользователь заплатить за возможность такого выбора? Возможно, те, кто пытался так делать, просто отсеялись естественным отбором.
Идея не в том, что разработчики становятся на полставки QA и начинают тестировать код на проде :) Идея в том, что разработчики пишут тесты, которые прогоняются на CI перед каждым деплоем.
Ручное тестирование само по себе может закрыть далеко не все классы потенциальных багов, тем более если оно проводится в фейковом окружении. Частично эти же классы багов можно закрыть юнит-тестами, интеграционными тестами и автоматизированными тестами интерфейса.
А дальше бизнес просто считает, насколько важны эти классы ошибок для него, и что выгоднее в перспективе: ручной тестер или напрягать девелоперов на автоматизацию.
Ничего удивительного. Таким подходом сейчас пользуются примерно все от операционных систем до игр, в том числе и языки программирования, фреймворки и IDE — для всего этого публикуются альфа-, бета-версии, релиз-кандидаты, превью, найтли, снепшоты. Зачем по-вашему? Если что-то делается для людей, желание услышать фидбек от этих людей как можно раньше — это нормально.
Вообще, ровно наоборот. На ранней стадии проекта фичи резко появляются и исчезают, API очень быстро меняется и так далее. Писать на это тесты — слишком большой оверхед и потеря гибкости. Тут как раз ручное тестирование решает.
Когда проект уже устаканился, проще автоматизировать тесты — это и надежнее, чем гонять вручную по одним и тем же кейсам изо дня в день, и заодно позволяет сократить время поставки.
Во-первых, противопоставление короткого цикла поставки и хорошо протестированных багов — это как раз и есть пример "ложной дихотомии". Деплой изменений непосредственно в прод не означает, что они перед этим не должны тестироваться. Ровно как и наличие дева, стейджа и пре-прода с армией тестеров не означает, что тестирование будет сделано хорошо. Об этом сказано в статье в разделе "5. Меры QA снижают качество".
Во-вторых, чего бы вам не хотелось больше: один раз наступить на баг, описать его в саппорт и больше никогда с ним не столкнуться, или наступать на один и тот же известный (и уже давно пофикшеный в коде) баг регулярно, потому что у сервиса длительный цикл поставки?
А как решаются вопросы с ценой ошибки и доступом девелоперов к проду?
Хорошая статья, хоть перевод и подпортил слегка впечатление.
Мне довелось как-то работать над одним довольно крупным сервисом по описанным принципам. Не было стейджа и тестеров. Каждый девелопер сам тестировал свои изменения, деплоил сразу на прод и, если что, сам откатывал. Такой подход побуждает более ответственно относиться к тому, что ты написал, тщательно продумавать все корнер кейсы, подкладывать соломинки во все возможные места. И это неплохо работало: частота деплоев на прод — десятки в день, частота откатов — единицы в месяц. Причем последствия ошибок в коде как правило довольно локальны, в отличие от ошибок в настройках инфраструктуры, из-за которых может развалиться вообще все.
Понятно, что этот подход никогда не будет применяться, например, для банковских сервисов. Там цена ошибки велика, и доступ всех девелоперов и тестеров к проду сам по себе является риском.
Да, интересуюсь этой темой. Спасибо за видео!
Спасибо за подробные ответы! Пока читал, всплыла еще пара вопросов:
Очень крутая статья, спасибо! Приятно знать, что Akka способна на такое. Не могу удержаться от того, чтобы не задать несколько технических вопросов: