Мое мнение, Вы пытаетесь изобрести ООП, и хотите сделать статический полиформиз для поддержки разных архитектур, дак уже всё придумано С++ и шаблоны. вот, например, конфигурация Pin хоть в что, на любой платформе.
Pin<Config>::Set();
хотите сделать конфигурацию пина в во вход на любой платформе:
using PinToInput = Pin<ConfigToInput>:
PinToInput::Set();
останется только определить Configи для разных платформ и реализации Set(), ну или Set() тоже может быть одинаковыми, но тогда реализация должна быть в Configах
Возможно, но я только по своему опыту. А мы делаем устройства с функциональной безопасностью SIL3, и там QA в менеджмент не лезет.
Качество обеспечивается процессом и его выполнением. QA может этот процесс собственно разработать и утвердить ( с менеджментов), но лезть потом к нему не должен (за исключением случаев, если в самом процессе прописано, что надо лезть к менеджементу и звонить директору в любое время суток в случае бага), так же как и менять процесс или вмешиваться на ходу в процесс.
Ну вообще то, под "тестером" я понимал как раз QA инженера, а не обезьянку тыкающую на кнопки:
С моей точки зрения QA инженер должен выполнить следующие шаги(минимально необходимые шаги):
Проанализировать требования
Написать цели тестирования
Разработать тестовые спецификции
Разработать тест скрипты
Запустить тесты
Оформить результаты
Собственно, он точно также не должен за вопросы бизнеса или там приостановку релиза отвечать, и вообще озадачиваться ими (ну только если он не является лидом по тестированию).
Он занес баг - и ждет пока его назначать на верификацию, когда баг исправили. Может и не дождаться, если ССТ команда решит не править баг.
Самое важное тут анализ, который делает один человек (обычно разработчик) при котором может произойти 3 вещи:
Это баг, надо править код
Это баг в тесте, надо править тест
Это баг в требованиях, возможно надо править все.
ССТ на основе этого анализа решает, что делать дальше. Для принятия решения она может привлекать как QA, так и разработчика, а может никого не привлекать, сама решит, если анализ хороший.
В идеальном случае QA вообще не должен взаимодействовать с разработчиком, потому что для него все должно быть черным ящиком, а разработчик уже может иметь знания о внутреннем устройстве ПО и вообще он ненужное звено тут. Для QA есть требования, что подать на вход ПО, и что должно быть на выходе. Остальное только мешает работе.
Баг в системе есть - извольте его как минимум проанализировать - и никаких полномочий об остановке релиза у QA нет, они есть у ССТ команды. Если она решит, что незначительный баг - можно выпускать - ОК, решит не выпускать тоже ОК. QA свою функцию выполнил, предупредил, что ПО требованиям не соотвествует.
P.S. ну это если процесс настроен, если процесса нет, то согласен с оратором ниже, тут только эскалация куда-то вверх. Там пусть решают.
Мне кажется не вопрос тестера решать, исправлять баг или нет, а тем более принимать решения по вопросам типа ("А если очень надо выпустить, потому что иначе компания потеряет много прибыли"). Иначе это уже не тестер, а ген диреткор. Так можно на него навешать и вопросы продвижения товара, и маркетинг.
Все такие вопросы решаются либо в скопе проекта (когда сразу обозначается, что надо качественно, дешево, но долго, или быстро, дешево, но не качественно), и владельцем продукта, а владелец продукта (так как он не разарботчик и не тестер), должен как минимум знать мнение лидеров по разработке и тестированию (насколько быстро можно поправить баг, насколько это баг вообще критичный и так далее) и на основании этого принмать решение.
Тестер же отлично сделал свою работу - нашел(как ему кажется) несоотвествие между требованиями и тем, что программа делает. Дальше уже не его забота, что с этим багом делать.
А то ведь так можно все эскалировать до ген. директора, звонить там ему ночью. Каждый должен делать свое дело по процессу действовать.
Если эскалировать выше, то, гай мой взгляд, это означает, что процесс настроен плохо.
По хорошему, должно быть так,
Тестер заносит баг, ну или считает, что баг,
ССТ менеджер или лид назначает инженера на анализ
Инженер анализирует, решает, что это не баг
ССТ команда рассматривает анализ и выдаёт вердикт, либо это не баг, либо анализ неверный и назначает инженера на переанализ.
Далее круг повторяется, если ССТ решает, что это баг, назначается инженер на исправление.
После исправления Тестер верифицирует и закрывает.
В таком случае, тестер никого не должен убеждать. Его задача занести и проверифицировать. В ССТ команду могут входить лид по разработке и тестериванию и, например менеджер проекта, зависит от уровня бага.
Я так и не понял, почему это называется дилемой. Тут просто надо тормозить. Дилема будет у автопилота, когда у его грузовика на горке откажут тормоза, и по ПДД будет 2 варианта либо въехать взад впереди идущей машине, где сидит старичок, либо в кювет, где стоит малыш.
Если уведомили и ты написал по собственному, то получишь в день увольнения расчёт в 3 средних. А вот если не уведомили, а попросили написать, то ничего не получишь.
Уведомили за 2 месяца, в этот же день, ты можешь уволится и получить з. п. за 2 месяца + ещё 1. Затем, если в течении 3 месяцев не находишь работу, конечно регистрируясь в службе занятонности, то по заявлению ещё одну от работодателя и вот потм, ещё опять работу не нашёл через службу занятости то ещё одна уже от службы. Т. е по совокупности 5 средних, если не найдешь работу.
Платишь 30% за год. Нерезидент ты или резидент определяется один раз в год 31 декабря. Если определили, что нерезидент, заплатишь 30% за весь год, просто доплачивать будешь.
И да не советую идти в HR и что то там толковать про удаленную работу за границей, эта информация уйдёт сразу в налоговую, а она вас будет считать нерезидентом, и судиться с ней только приезжать обратно.
Не ну 40 000 то сэкономил всё равно. Даже больше, если пару месяцев, то 130 000.
Ага, ?
Вы и на C++ можете ими(адресами, регистр это тоже ячейка памяти) оперировать.
Мое мнение, Вы пытаетесь изобрести ООП, и хотите сделать статический полиформиз для поддержки разных архитектур, дак уже всё придумано С++ и шаблоны. вот, например, конфигурация Pin хоть в что, на любой платформе.
хотите сделать конфигурацию пина в во вход на любой платформе:
останется только определить Configи для разных платформ и реализации Set(), ну или Set() тоже может быть одинаковыми, но тогда реализация должна быть в Configах
Как то баловался таким.
https://habr.com/ru/post/473612/
https://disk.yandex.ru/i/ajCQtg1GEPPdRQ
Как сложность алгоритма может зависеть от языка?
Скорость работы зависит, но сложность точно нет. Сложность, она же у алгоритма.
Мы к конце 90х так работали, было один компьютер на двоих, и делили место по пол дня. А пол дня занимались теорией и всякими другими делами
В Си нет ссылок.
Возможно, но я только по своему опыту. А мы делаем устройства с функциональной безопасностью SIL3, и там QA в менеджмент не лезет.
Качество обеспечивается процессом и его выполнением. QA может этот процесс собственно разработать и утвердить ( с менеджментов), но лезть потом к нему не должен (за исключением случаев, если в самом процессе прописано, что надо лезть к менеджементу и звонить директору в любое время суток в случае бага), так же как и менять процесс или вмешиваться на ходу в процесс.
Ну вообще то, под "тестером" я понимал как раз QA инженера, а не обезьянку тыкающую на кнопки:
С моей точки зрения QA инженер должен выполнить следующие шаги(минимально необходимые шаги):
Проанализировать требования
Написать цели тестирования
Разработать тестовые спецификции
Разработать тест скрипты
Запустить тесты
Оформить результаты
Собственно, он точно также не должен за вопросы бизнеса или там приостановку релиза отвечать, и вообще озадачиваться ими (ну только если он не является лидом по тестированию).
Он занес баг - и ждет пока его назначать на верификацию, когда баг исправили. Может и не дождаться, если ССТ команда решит не править баг.
Самое важное тут анализ, который делает один человек (обычно разработчик) при котором может произойти 3 вещи:
Это баг, надо править код
Это баг в тесте, надо править тест
Это баг в требованиях, возможно надо править все.
ССТ на основе этого анализа решает, что делать дальше. Для принятия решения она может привлекать как QA, так и разработчика, а может никого не привлекать, сама решит, если анализ хороший.
В идеальном случае QA вообще не должен взаимодействовать с разработчиком, потому что для него все должно быть черным ящиком, а разработчик уже может иметь знания о внутреннем устройстве ПО и вообще он ненужное звено тут. Для QA есть требования, что подать на вход ПО, и что должно быть на выходе. Остальное только мешает работе.
Баг в системе есть - извольте его как минимум проанализировать - и никаких полномочий об остановке релиза у QA нет, они есть у ССТ команды. Если она решит, что незначительный баг - можно выпускать - ОК, решит не выпускать тоже ОК. QA свою функцию выполнил, предупредил, что ПО требованиям не соотвествует.
P.S. ну это если процесс настроен, если процесса нет, то согласен с оратором ниже, тут только эскалация куда-то вверх. Там пусть решают.
Мне кажется не вопрос тестера решать, исправлять баг или нет, а тем более принимать решения по вопросам типа ("А если очень надо выпустить, потому что иначе компания потеряет много прибыли"). Иначе это уже не тестер, а ген диреткор. Так можно на него навешать и вопросы продвижения товара, и маркетинг.
Все такие вопросы решаются либо в скопе проекта (когда сразу обозначается, что надо качественно, дешево, но долго, или быстро, дешево, но не качественно), и владельцем продукта, а владелец продукта (так как он не разарботчик и не тестер), должен как минимум знать мнение лидеров по разработке и тестированию (насколько быстро можно поправить баг, насколько это баг вообще критичный и так далее) и на основании этого принмать решение.
Тестер же отлично сделал свою работу - нашел(как ему кажется) несоотвествие между требованиями и тем, что программа делает. Дальше уже не его забота, что с этим багом делать.
А то ведь так можно все эскалировать до ген. директора, звонить там ему ночью. Каждый должен делать свое дело по процессу действовать.
Если эскалировать выше, то, гай мой взгляд, это означает, что процесс настроен плохо.
По хорошему, должно быть так,
Тестер заносит баг, ну или считает, что баг,
ССТ менеджер или лид назначает инженера на анализ
Инженер анализирует, решает, что это не баг
ССТ команда рассматривает анализ и выдаёт вердикт, либо это не баг, либо анализ неверный и назначает инженера на переанализ.
Далее круг повторяется, если ССТ решает, что это баг, назначается инженер на исправление.
После исправления Тестер верифицирует и закрывает.
В таком случае, тестер никого не должен убеждать. Его задача занести и проверифицировать. В ССТ команду могут входить лид по разработке и тестериванию и, например менеджер проекта, зависит от уровня бага.
Я так и не понял, почему это называется дилемой. Тут просто надо тормозить. Дилема будет у автопилота, когда у его грузовика на горке откажут тормоза, и по ПДД будет 2 варианта либо въехать взад впереди идущей машине, где сидит старичок, либо в кювет, где стоит малыш.
Да, я это и имел ввиду, обычно работодателю нет смысла 2 месяца держать работника, поэтому де-факто это так и работает всегда.
Если уведомили и ты написал по собственному, то получишь в день увольнения расчёт в 3 средних. А вот если не уведомили, а попросили написать, то ничего не получишь.
Уведомили за 2 месяца, в этот же день, ты можешь уволится и получить з. п. за 2 месяца + ещё 1. Затем, если в течении 3 месяцев не находишь работу, конечно регистрируясь в службе занятонности, то по заявлению ещё одну от работодателя и вот потм, ещё опять работу не нашёл через службу занятости то ещё одна уже от службы. Т. е по совокупности 5 средних, если не найдешь работу.
Вообще, кто хочет проблемы решает, нам до сих пор американцы платят за услуги и нашли способ.
У меня вопрос один, а кому тогда принадлежат права?
Платишь 30% за год. Нерезидент ты или резидент определяется один раз в год 31 декабря. Если определили, что нерезидент, заплатишь 30% за весь год, просто доплачивать будешь.
И да не советую идти в HR и что то там толковать про удаленную работу за границей, эта информация уйдёт сразу в налоговую, а она вас будет считать нерезидентом, и судиться с ней только приезжать обратно.
Сомнителтный совет в статье.
Главное, что про С++, ведь инверсия зависимостей она только там.
Ну Эльбрус точно то российский.