В разных компаниях и на разных проектах роли тестировщика могут различаться. Где-то тестировщик может быть в первую очередь сосредоточен на поиске ошибок, а где-то — активно участвовать в процессе разработки и предлагать улучшения.
Разумеется, важно понимать, что цель тестировщика — не «перерасти» разработчика или аналитика, а обеспечить высокое качество продукта. И для этого тестировщик может использовать различные подходы и методы, в том числе предлагать улучшения на основе своего опыта и знаний.
Я считаю, что успешная разработка продукта возможна только при тесном сотрудничестве всех участников процесса — разработчиков, тестировщиков, аналитиков и других специалистов.
Во время интервью, когда обсуждали каталог услуг, мы рассказывали о форматах документации, которую предоставляем (HTML5, PDF/DOCX), и уточняли, достаточно ли этих форматов или есть потребность в других.
В нашем случае оказалось, что онлайн-документация в HTML5 — самый предпочтительный вид, потребность в PDF/DOCX была куда меньше, также коллеги говорили о видеороликах в документации как о возможном запросе на будущее.
Решить эту задачу через свой скрипт можно, действительно буквально в пару строк. Но мы сознательно от этого ушли по нескольким причинам.
Во-первых, чтобы не поддерживать собственный скрипт + в самом инструменте есть дополнительные возможности, например, кеширование, да и зачем делать то, что уже реализовано.
Во-вторых, такой скрипт пришлось бы дублировать во все репозитории, где нам это нужно. И тут снова появляется проблема актуализации, если будет необходимо расширить функционал скрипта.
Можно, конечно, добавлять скрипт, используя git submodules, но возникает другая проблема: мало кто пользуется и знаний как с ним работать у большинства нет. В итоге пришлось бы отдельно прописывать пункт в README, чтобы разработчики смогли правильно склонировать и пользоваться репозиторием.
Контекст у виртуального потока есть, но он не системный. JVM сама хранит его как continuation — то есть просто состояние выполнения и стек в heap. Под него не создается отдельный поток или стек в ядре.
Спасибо за вдумчивый комментарий — вопрос действительно важный.
Вы правы: когда поток ОС блокируется на I/O, он действительно спит и не тратит CPU. Проблема не в расходе вычислительных ресурсов, а в количестве таких потоков.
ОС-поток — это дорогая вещь: для каждого нужно создать стек (обычно мегабайт), сохранить контекст, управлять переключениями, синхронизацией и т.д. Если у нас тысячи одновременных запросов, ожидающих ответ от БД или сети, то тысячи потоков ОС будут находиться в спящем состоянии, занимая память и ресурсы ядра. JVM, в свою очередь, вынуждена держать эти структуры и выполнять переключения при каждом пробуждении. Это и создает накладные расходы.
Виртуальные потоки решают не задачу "ожидания байтиков", а проблему масштабирования, то есть они позволяют иметь миллионы задач, ожидающих I/O, при этом переиспользуя ограниченное количество настоящих (carrier) потоков ОС. Планирование действительно реализовано в JVM, но оно легковесное: это просто привязка контекста задачи к системному потоку, без выделения отдельного стека в ядре.
То есть это не "костыль поверх ОС", а второй уровень планирования, можно сказать надстройка, оптимизированная под модель массовой конкурентности без активных вычислений, когда тысячи задач делают что-то простое и ждут I/O.
По сути, виртуальные потоки это не попытка обойти ОС, а инструмент, чтобы JVM могла эффективно использовать ОС-потоки там, где обычная модель 1:1 перестает масштабироваться.
Спасибо за такой развернутый комментарий! Статья ориентирована на начинающих разработчиков, поэтому мы сознательно сильно не углублялись в технические детали и нюансы.
Отдельное спасибо за ссылки и дополнения — все по делу. Моменты, которые ты выделил жирным, абсолютно точные и, по сути, хорошо резюмируют главный посыл материала.
Пока — нет. И Log4j 2, и Logback остаются ThreadLocal-based для MDC/ThreadContext. «Новое» сегодня — контекст-пропагация (напр., Reactor 3.5 + Micrometer), которая переносит и поднимает MDC на время логирования. Это уменьшает боль, но не отменяет ограничения ThreadLocal. Параллельно в сообществах Log4j/SLF4J уже идут обсуждения перехода к ScopedValue/ScopedContext, но стабильных релизов «без ThreadLocal» пока нет.
Спасибо большое за отклик — особенно ценно услышать мнение от коллеги с похожим опытом из другой области.
С джунами действительно важно удерживать баланс: мягкость помогает выстроить доверие, но если ошибки повторяются или нарушаются договоренности — я стараюсь говорить строже, но при этом сохранять открытый диалог.
Спасибо, что подсветили тему развития — очень важная и точно достойна отдельного разговора.
Спасибо за интерес к статье и нашей команде :) Можешь отправить резюме на job@naumen.ru — мы сохраним твои контакты и свяжемся, как только появится подходящая вакансия.
Спасибо за вопрос! Это была задача от заказчика по ручному анализу и очистке входящих данных в Excel. Тогда автоматизировать подобные процессы не получалось, поэтому задача относилась к зоне ответственности бизнеса — нужно было хорошо разбираться в специфике данных в их сфере. Мне же нужно было работать уже с актуальными данными.
Оба подхода обладают своими плюсами и минусами, серебряной пули, к сожалению, не существует. EAV использовался в проектном решении этой задачи, но таблица разрастается довольно быстро, и это может начать создавать проблемы производительности.
Что касается JSONB, то под капотом в случае с Postgres используется именно он — как более эффективный.
Привет! Спасибо, что высказал интересную мысль :) Мы всегда открыты к новым идеям, так что ты можешь написать нам в Telegram @naumen_connect, сможем подробнее обсудить формат, который тебе кажется перспективным.
Добрый день! Конечно, посчитать точно возможности нет, всегда есть приближенные расчеты.
Мы считаем, что повлияли именно изменения в продукте, так как «соседний» продукт для внутренней поддержки не вырос настолько же в тех же условиях рынка, когда началось импортозамещение. При этом исторически видели, что оба продукта примерно одинаково реагировали на волнения на рынке.
Я не встречал методик по определению уровня неопределенности. Существуют методы оценки риска, да. Но это другое. Суть mindmap, о котором идет речь в статье (можно посмотреть здесь: https://miro.com/app/board/uXjVNEOGewU=/), чтобы иметь инструмент для определения составляющих (аспектов), по которым мы, возможно, не учли какие-то требования. И далее, что делать, чтобы выявить и формализовать эти требования.
Проблема в статье рассматривается не с точки зрения менеджмента, а с точки зрения результативности команды. Конечно, это более актуально, когда формат договора предполагает обоюдную ответственность для заказчика и исполнителя, как, например, в fixed price & fixed scope. А еще более значимо во внутренней разработке.
Оценить рамки неопределенности как раз и помогает mindmap. Чтобы было понятнее, вот ссылка: https://miro.com/app/board/uXjVNEOGewU=/. Чем раньше с его помощью получится понять, что есть «слепые зоны», тем лучше для всех.
Если кратко, то: первое — наши хорошо отлаженные процессы позволяют проводить подобные обновления, второе — как отметил в статье, каждое обновление приносит с собой и улучшение языка, и повышение безопасности и перформанса продукта из коробки.
Спасибо за ваш комментарий.
В разных компаниях и на разных проектах роли тестировщика могут различаться. Где-то тестировщик может быть в первую очередь сосредоточен на поиске ошибок, а где-то — активно участвовать в процессе разработки и предлагать улучшения.
Разумеется, важно понимать, что цель тестировщика — не «перерасти» разработчика или аналитика, а обеспечить высокое качество продукта. И для этого тестировщик может использовать различные подходы и методы, в том числе предлагать улучшения на основе своего опыта и знаний.
Я считаю, что успешная разработка продукта возможна только при тесном сотрудничестве всех участников процесса — разработчиков, тестировщиков, аналитиков и других специалистов.
Во время интервью, когда обсуждали каталог услуг, мы рассказывали о форматах документации, которую предоставляем (HTML5, PDF/DOCX), и уточняли, достаточно ли этих форматов или есть потребность в других.
В нашем случае оказалось, что онлайн-документация в HTML5 — самый предпочтительный вид, потребность в PDF/DOCX была куда меньше, также коллеги говорили о видеороликах в документации как о возможном запросе на будущее.
Решить эту задачу через свой скрипт можно, действительно буквально в пару строк. Но мы сознательно от этого ушли по нескольким причинам.
Во-первых, чтобы не поддерживать собственный скрипт + в самом инструменте есть дополнительные возможности, например, кеширование, да и зачем делать то, что уже реализовано.
Во-вторых, такой скрипт пришлось бы дублировать во все репозитории, где нам это нужно. И тут снова появляется проблема актуализации, если будет необходимо расширить функционал скрипта.
Можно, конечно, добавлять скрипт, используя git submodules, но возникает другая проблема: мало кто пользуется и знаний как с ним работать у большинства нет. В итоге пришлось бы отдельно прописывать пункт в README, чтобы разработчики смогли правильно склонировать и пользоваться репозиторием.
Подборку инструментов подготовили Катя и Арина — тестировщики из команды релизного тестирования SMRM.
Спасибо, что подметил! Все так, но в данном случае пример для демонстрации вложенности.
Контекст у виртуального потока есть, но он не системный. JVM сама хранит его как continuation — то есть просто состояние выполнения и стек в heap. Под него не создается отдельный поток или стек в ядре.
Спасибо за вдумчивый комментарий — вопрос действительно важный.
Вы правы: когда поток ОС блокируется на I/O, он действительно спит и не тратит CPU. Проблема не в расходе вычислительных ресурсов, а в количестве таких потоков.
ОС-поток — это дорогая вещь: для каждого нужно создать стек (обычно мегабайт), сохранить контекст, управлять переключениями, синхронизацией и т.д. Если у нас тысячи одновременных запросов, ожидающих ответ от БД или сети, то тысячи потоков ОС будут находиться в спящем состоянии, занимая память и ресурсы ядра. JVM, в свою очередь, вынуждена держать эти структуры и выполнять переключения при каждом пробуждении. Это и создает накладные расходы.
Виртуальные потоки решают не задачу "ожидания байтиков", а проблему масштабирования, то есть они позволяют иметь миллионы задач, ожидающих I/O, при этом переиспользуя ограниченное количество настоящих (carrier) потоков ОС. Планирование действительно реализовано в JVM, но оно легковесное: это просто привязка контекста задачи к системному потоку, без выделения отдельного стека в ядре.
То есть это не "костыль поверх ОС", а второй уровень планирования, можно сказать надстройка, оптимизированная под модель массовой конкурентности без активных вычислений, когда тысячи задач делают что-то простое и ждут I/O.
По сути, виртуальные потоки это не попытка обойти ОС, а инструмент, чтобы JVM могла эффективно использовать ОС-потоки там, где обычная модель 1:1 перестает масштабироваться.
Под "полноценный поток операционной системы" подразумевается "объект Thread отображается один к одному на поток операционной системы"
Спасибо за такой развернутый комментарий! Статья ориентирована на начинающих разработчиков, поэтому мы сознательно сильно не углублялись в технические детали и нюансы.
Отдельное спасибо за ссылки и дополнения — все по делу. Моменты, которые ты выделил жирным, абсолютно точные и, по сути, хорошо резюмируют главный посыл материала.
Пока — нет. И Log4j 2, и Logback остаются ThreadLocal-based для MDC/ThreadContext. «Новое» сегодня — контекст-пропагация (напр., Reactor 3.5 + Micrometer), которая переносит и поднимает MDC на время логирования. Это уменьшает боль, но не отменяет ограничения ThreadLocal. Параллельно в сообществах Log4j/SLF4J уже идут обсуждения перехода к ScopedValue/ScopedContext, но стабильных релизов «без ThreadLocal» пока нет.
Спасибо большое за отклик — особенно ценно услышать мнение от коллеги с похожим опытом из другой области.
С джунами действительно важно удерживать баланс: мягкость помогает выстроить доверие, но если ошибки повторяются или нарушаются договоренности — я стараюсь говорить строже, но при этом сохранять открытый диалог.
Спасибо, что подсветили тему развития — очень важная и точно достойна отдельного разговора.
Спасибо за интерес к статье и нашей команде :) Можешь отправить резюме на job@naumen.ru — мы сохраним твои контакты и свяжемся, как только появится подходящая вакансия.
Спасибо за вопрос! Это была задача от заказчика по ручному анализу и очистке входящих данных в Excel. Тогда автоматизировать подобные процессы не получалось, поэтому задача относилась к зоне ответственности бизнеса — нужно было хорошо разбираться в специфике данных в их сфере. Мне же нужно было работать уже с актуальными данными.
Оба подхода обладают своими плюсами и минусами, серебряной пули, к сожалению, не существует. EAV использовался в проектном решении этой задачи, но таблица разрастается довольно быстро, и это может начать создавать проблемы производительности.
Что касается JSONB, то под капотом в случае с Postgres используется именно он — как более эффективный.
Привет! Спасибо, что высказал интересную мысль :) Мы всегда открыты к новым идеям, так что ты можешь написать нам в Telegram @naumen_connect, сможем подробнее обсудить формат, который тебе кажется перспективным.
Добрый день! Конечно, посчитать точно возможности нет, всегда есть приближенные расчеты.
Мы считаем, что повлияли именно изменения в продукте, так как «соседний» продукт для внутренней поддержки не вырос настолько же в тех же условиях рынка, когда началось импортозамещение. При этом исторически видели, что оба продукта примерно одинаково реагировали на волнения на рынке.
Я не встречал методик по определению уровня неопределенности. Существуют методы оценки риска, да. Но это другое. Суть mindmap, о котором идет речь в статье (можно посмотреть здесь: https://miro.com/app/board/uXjVNEOGewU=/), чтобы иметь инструмент для определения составляющих (аспектов), по которым мы, возможно, не учли какие-то требования. И далее, что делать, чтобы выявить и формализовать эти требования.
Проблема в статье рассматривается не с точки зрения менеджмента, а с точки зрения результативности команды. Конечно, это более актуально, когда формат договора предполагает обоюдную ответственность для заказчика и исполнителя, как, например, в fixed price & fixed scope. А еще более значимо во внутренней разработке.
Оценить рамки неопределенности как раз и помогает mindmap. Чтобы было понятнее, вот ссылка: https://miro.com/app/board/uXjVNEOGewU=/. Чем раньше с его помощью получится понять, что есть «слепые зоны», тем лучше для всех.
Да, верно, изначально в коде этой строки не было, видимо, при публикации что-то слетело. Спасибо за внимательность, поправили!
Если кратко, то: первое — наши хорошо отлаженные процессы позволяют проводить подобные обновления, второе — как отметил в статье, каждое обновление приносит с собой и улучшение языка, и повышение безопасности и перформанса продукта из коробки.
В финальной части доклада на ютубе более подробно рассказал, почему полезно обновление.