Процессы - спасают от много, но от людей которые их сознательно не выполняют спасти увы не могут. Это как техника безопасности на любом предприятии, все обязаны знать, но все на неё плюют. А потом несчастные случаи на производстве. Идеальной документации, может быть и не бывает, но нормальная просто обязана быть. Или, как я уже сказал, можно выкидывать тестирование, так как в нем не будет никакого смысла. Просто делаем продукт силами нескольких программистов. Если речь касается Энтерпрайза - всё просто. Открываем нужный ISO и читаем. Там всё прописано с полной инструкцией как провести приоритезацию модулей/юнитов, какой уровень документации какому модулю необходим. Но для это сначала нужна архитектура, где будет расписано, где какой модуль, сколько уровней интеграции, есть ли зависимость на hardware, third party, etc. Нет архитектуры, нет требований, нет описания интерфейсов, так и говорить не о чем. Предел возможностей на таком проекте - это юнит тестирование.
Где вы увидели, что увольнять нужно всех? Только тех, кто не владеет базовыми навыками коммуникации, саботирует работу всей команды и является не компетентным. И то после 1-2-3 предупреждений на усмотрение бизнеса.
Мне вот довелось поработать как в стартапах на 5 человек, так и в медицинском энтерпрайзе по роботизированной хирургии, где одних SDET было 120 человек. А еще сверху отдельный департамент QA, который следил за работой как разработчиков, так и тестировщиков, чтобы всё было по ISO 13485 и ISO 62304. Так что всё бывает. Просто невозможно сделать медицинскую установку, автомобиль или самолёт по тем же процессным подходам, архитектурным паттернам и уровню документации как очередной веб- магазин или онлайн-казино. Банально не пройдёте сертификацию и не сможете ничего продать. Ну в крайнем случае выйдет как у Боинга, всех обмануть пока 2 самолёта не упадёт, а теперь бизнес активно загибается. Так что не торопитесь утверждать, что так не бывает, если конкретно у вас небыло такого опыта. Если у вас нет актуальной документации - значит у вас нет тестирования, а то что есть - это полная профанация. Потому как тестирование, это сверка документации с реальным поведением продукта. Нет документации - не с чем сравнивать, продукт живёт своей жизнью и о качестве даже бесполезно поднимать разговор. Таким продуктам не нужны ни Архитекторы, ни Тестировщики. Только вот реакция пользователей потом вполне ожидаема и предсказуема.
Вот читаю я все эти ситуации и мне кажется, что тут что-то пошло не туда в мире IT. Я вообще не понимаю, что значит Инженер не понимает зачем нужен Архитектор и саботирует его задачи? Обычно за такое делают выговор, а если не понятно увольняют. Тут ровно 2 проблемы: Это не задача Архитектора - доказывать Инженерам, что он нужен. Если он есть на проекте, значит бизнес принял такое решение, а значит и мотивы есть и есть чем объяснить это команде. Если инженер не знает зачем нужен архитектор, значит он банально не компетентен. Наглядно ему это объяснить можно поставив одну из архитекторских задач по обоснованию и выбору БД, масштабируемости продукта или задач по оптимизации производительности. И потом просто показав как нужно решать такие задачи, а еще и не просто решать, но и обосновывать чем данный выбор лучше альтернатив.
Потому что это всё выглядит как непонятная возня вокруг девелоперов, чтобы они не дай Бог не обиделись. Разработка продукта - это не игрушки в первую очередь, хотя да этот аспект привносит хайп, веселье и улучшает атмосферу в коллективе. Но это не перво цель. Исходная причина - это зарабатывание денег компанией, для этого нужно всем работать в команде, уважать друг друга, и стараться решать задачи максимально приблеженно к срокам и заданию. Это не ПЭТ-проект, не обучение отдельного инженера и не развлечение. Это - Работа. Поэтому задачи - это цели компании. Не согласен с задачей - спрашивай, обсуждай, пытайся разобраться. А не сиди себе тихонько в уголку и саботируй всю работу. Это проблема не только архитекторов. Я как QA Engineer тоже с таким постоянно сталкиваюсь, что почему-то разработчики считают, что им нужно доказывать и учить, зачем нужно писать юнит-тесты, использовать статические инструменты анализа, документировать интерфейсы и думать что именно в них должно быть и как, и т.д. Самый эпик который мне приходилось слышать от Principal Software Develooment Engineer: "Почему это наш код, должен соответствовать задокументированной Архитектуре?" Я даже не нашёлся, что ответить. Но через два месяца всё было отрефакторено согласно архитектуре. Выводы: Software Develipment Engineer, работает над очень маленьким кусочком продукта, он даже представить себе не может, на сколько вся система сложна в целом и сколько усилий требуется на её согласованную, эффективную и бесперебойную работу. В силу ограниченности этого, он физически не может принимать верные архитектурные решения, просто из-за отсутствия информации для видения полноты картины. Это нормально, Архитекторы работают вширь продукта, разработчики же сосредоточены на работе вглубь отдельных частей. Они могут разбираться в моделях за которые ответственны гораздо лучше архитектора, но они никогда не будут лучше понимать поведение продукта в целом. Если это происходит, значит у человека просто не верный титул в подписи почты. Результат работы Архитектора - архитектурные документы в различных их реализациях. Результат работы Инженера - это Дизайн документы отдельных модулей, их реализация в коде и юнит тесты на данный код в соответствии с дизайн документом. Ну и естественно должно быть traceability между modules, units, software items в архитектуре с дизайн документами раскрывающими данный сущности.
Оставляя деньги в руках богатых, ты растлеваешь богатых и они у них заканчиваются. Давая деньги просто так бедным, ты растлеваешь бедных. Поэтому они там навсегда и останутся, так никогда и не став богатыми.
Не всегда у тебя будет выделенный девопс на проекте. А иногда у меня были такие девопсы, что это превращались в боль. Приходилось им писать пошаговую инструкцию, что нужно сделать. Доступов команде не давали из-за безопасности, а девопсы с доступами просто не владели нужным стеком, владели другим. Но проект стартануть нужно было быстро, а размер проекта порядка 200 человек. Проще самому было сделать, но всё упиралось в доступы.
Не всегда бывает так. Хотя и довольно часто. По-хорошему, решение выпускать в релиз или нет - принимает как раз Продукт-Менеджер. Задача тестировщика позволить ему сделать информированое решение. Т.е. предоставить максимально подробный и правдивый отчёт о текущем состоянии продукта/релиза. А там уже ответственность Менеджера выпускать это или нет. Еще ему можно помочь адекватным тестпланом, в котором должно быть прописано - допустимый уровень дефектов каждого приоритета. Если допустимый уровень zero bugs, тогда можно и блокировать. Но таких продуктов не так уж и много. Все равно какой-то уровень minor/cosmetic допустим.
Собеседование - нужно проводить под позицию. Конечно интервьюверу. проще написать список стандартных вопросов и идти по ним. Но толку от таких собеседований мало. Я стараюсь учитывать все аспекты. Что реально нужно будет делать, состав команды, какие области нужно будет закрыть, бизнес домен и т.д. Можно получить факап по любой из этих причин. Например, сильный алгортмист, но на проекте это не нужно, от слова совсем. И девопсов выделенных нет, а он ни в кубернетс не умеет, ни с облаками не работал и терраформ не знает. Да и банально не может поставить пайплайн с юнит-тестами, сборкой и развёртыванием. Ну и наоборот бывает, человек всё умеет, а ему никто прав не даст, все построено и девопсов целая команда, а от него нужно только код хороший писать с глубоким погружением в архитектуру. Или всё классно, но человек только приложения делал, а тут embedded а он даже даташит со схемой прочитать не может. Или моё любимое, медицинский домен. Можно иметь кучу знаний и всё уметь, но запороть проект недооценив важность процессов. И закомитив, что-то до подписания всех необходимых бумаг.
Я остановился на среде Mate и Linux Mint. Долго сидел на KDE, но после того как упёрся в его баг с тайлингом по хоткеям на цифровой клавиатуре. Оставил все попытки. 10 лет никто не хочет это починить. А я уже не могу без перекидывания окон на пол экрана или на другой монитор. Gnome давно не понравился. Из коробки многое не работает, нужно допиливать постоянно из консоли или фиксить. Когда покупал последний компьютер под Линукс, остановил выбор на AMD и Radeon. Помнил долгие муки с драйверами лет 15 назад под ATI. И был приятно удивлён увидеть видео теперь прямо в ядре. Для игр придётся по-прежнему многое таскать для починки звука и видео, особенно для старых игр без поддержки FullHD. Если не хочется, есть всем известный трекер. Там игры вместе с собранным и настроенным под конкретную игру wine идут.
Так-то оно так. Но если двигаться в этом направлении. То практически всё сегодня многопоточно. Потому что процессоры многоядерные и зачастую мультитредовые. Тогда можно поставить гипервизор, развернуть N операционных систем, поднять в них любую среду и написать приложение которое будет в этом всём работать. Ну или просто какой-нибудь Kubernetes развернуть. Только всё это будет сделано вовсе вовсе не средствами языка программирования. И некоторые операции станут сильно дорогими в плане времени.
Что-то наблюддается некоторая мешанина терминов. Мне вот всегда было непонятно это стремление ссылаться на всякие странные сайты. С одной стороны там есть некая агрегация данных и знаний, с другой стороны, каждый использует своё видение видов, уровней, техник и методик тестов. Есть ISTQB и RUP. Чем они не угодили? Почему нельзя использовать их терминологию. Она хотя бы общепринята. Выделение тестирования изменений в одном уровне с функциональным и нефункциональным тестирование - крайне странно. Тестирование изменений ровно также включает функциональное и нефункциональное тестирование. Является общим множеством smoke, sanity & regression. Обычно виды тестов делят принципиально на функциональные и нефункциональные. А дальше внутри идёт ветвление которое спрашивать наизусть полностью не имеет смысла. Я обычно просто спрашиваю примеры.
Это не совсем рынок так устроен. Это так устроен круг людей проводящих технические собеседования. Которые иногда просто спрашивают то что нравится им самим, или просто находят вопросы в интернете. А кандидаты также находят ответы на эти вопросы. Всё таки нужно больше стараться отталкиваться от конкретной позиции, конкретного состава команды и продукта. Но как говорил один боксёр:"Все, но не каждый" могут так делать. В реальности фреймворк на проекте поднимается 1 раз, ну может 2. Это не то знание, которое будешь применять каждый день. Для этого достаточно открыть документацию, прочитать, осознать и применить. Вот этот навык куда важнее, знания наизусть информации, которая и так всегда под рукой. Вот работу с git, ревью, составление тестовых сценариев, работа с тестовыми данными, просмотр результатов, триаж и починка CI - это действительно то что применяется каждый день. Кроме того, надо понимать домен в котором работаешь. У меня на одном собеседовании волосы дыбом вставали. Когда спрашивали по Python перечни базовых методов, магисеские мотоды классов, декораторы и т.д. Когда я спросил зачем, то получил ответ который меня ввёл в ступор. Потому что обычно идут путём привлечения девеелоперов для написания моков и стабов и возможно базовых методов взаимодействия тест фреймворка с продуктом. Но тут решили что тестировщики должны помочь девелоперам переписать продукт под новую версию Python. Но интервьювер вообще не принял в рассчёт одну такую маленькую деталь. Что продукт был медицинским. А тут по стандарту не могут быть никаких смешений взаимодействия разработчиков и тестировщиков. В идеале - это вообще должны быть люди из разных организаций с максимальным уровнем независимости на принятие решений. Ну найдут они подходящего кандидата по соображениям тех интервьювера. Но при сдаче проекта внезапно осознают, что всё сделанное нужно переделать. Потому как FDA такую халтурку в жизни не пропустит, когда код писал и полностью тестировал один и тот же человек. Так что сейчас есть наглядная проблема больших контор которые подводят унификацию требований для кандидатов сами не осознают область на которую эту унификацию стоит и можно расспространять. Всё таки в идеале, интервью должны проводить люди имеющие прямое отношение к конкретному проекту. А сейчас получаем в большинстве случаев - когда интервьювер, в лучшем случае, получил строк 20 описания проекта. Пришёл проводить интервью, потому что за эту активность можно получить некий бонус. И задаёт вопросы, которые весьма интересны с точки зрения погружения в глубины языка. Но ответы на которые можно будет благополучно забыть ровно до следующего интервью.
Спрашивать-то, спрашивают. Только толку от этого. Вот сколько раз потом на практике понадобилось писать код маркером на доске? Сколько проектов по тестированию требуют глубоких знаний базовых методов языка? Куча проектов по поддержке, где вся работа сводится исключительно к написанию новых тестов и выпишиваеию старых. Кстати, я бы сказал они именно идеальная среда для начала карьеры. Есть куча примеров и можно по разбираться на текущей базе кода как всё работает. Никаких гарантий, что это будет наилучший вариант. Но для базы, понимания архитектуры фреймворка и базовых слоёв подойдёт. В тестировании нэгораздо больше пользы от понимания тест фреймворков, их возможностей и ограничений. Некоторые фреймворки вообще ломают логику базового языка. Например, работа с Selenium в Python, всё равно превращает код в JAVA образный. Поэтому лучше знать тестовые фреймворки и как их интегрировать. Почему Cypress подойдёт для тестирования онлайн магазинов, но не сложных бизнес приложений. Чем Playwright лучше Selenium. Чем так хорош pyTest и как его осилить после jUnit и TestNG. Как тесты параллелизировать и с какой CI. Почему Azure в минимальной подписки не имеет смысла. И т.д.
Человек всегда выбирает на что тратить своё время. В маленьком городе - больше времени на себя, семью, но вероятно меньше зароботок. В большом городе - больше зароботок. Но нет времени самому приготовить себе обед, погулять с ребенком и в целом провести время с семьёй. И эти пробемы создают не технологии, а всё та же проблема плотности начеления и пробок. Либо ты будешь тратить 15-20 минут похода на работу пешком. Либо 2-3 часа сидеть в пробках в автомобиле, а потом пытаться выкроить время для спорзала. А все эти технологии - это лишь средства удовлетворить запрос конретного общества в конкретных условиях.
Каршеринг, всё таки несколько снижает транспортную нагрузку хоть и косвенно. Такие авто - меньше простаивают, а значит в случае приехал на работу и нет частной парковки, такое авто будет меньше занимать крайнюю полосу там где парковка допустима. Хотя, конечно общественный транспорт справляется с этой задачей намного лучше. Так же хорошо справляются электроскутеры, которые мопеды. Но это вещь тоже сезонная.
Что-то много недосказанности. А как же сторона DevOps и тулов? ИМХО - мидл, должен хорошо знать техническую предментную область - язык программирования, паттерны, архитектуры - это всё легко учится из теории. А старшой - должен уже обладать более широкими софт скилами, знать разницу гибких и строгих методологий. И главное уметь плясать от продукта, а не от того что он умеет. Не совать везде - я так 20 лет он-лайн магазины писал и UI на приборку авто так же буду делать. А уметь выбрать оптимальную методику, архитектуру, паттерны. Уровень документации от самодокументируемого кода, до Detailed Design, Software&System Architecture документов. Объяснять мидлам и джунам, почему их супер-навыки в Vim в данной команде будут только во вред и что он не просто так потратил время на конфиг для IDE и настроили pre-commit git hooks. И сколько дрвгоценного времени это экономит. Ну и опять же это всё если проект для команды или нескольких команд. А если проект на 2 недели на коленке в одно лицо что-то состряпать. То тут не стоит убиваться и поднимать CI/CD на 4 энвайронментах. И писать конфиги, ревью чек-листы и архитектурные документы.
Даже если исключить финансовое неравество. У жителей мегаполисов и меньших городов - разные запросы и потребности. В мегаполисе сложно без авто добраться до работы, кинотеатра, любимого ресторана и т.д. В маленьких городах - это зачастую довольно просто сделать пешком. Кроме того улицы не столь перегружены автомобилями, поэтому собственный автомобиль доставляет больше радости. Вот еду можно заказывать одинаково. Хотя в целом, чем меньше город, тем размереннее ритм жизни. Поэтому для скорейшего возврата инвестиций сервисы и откатывают в районах с большей плотностью населения, а значит упрощенной логистикой, большим колличеством потенциальных клиентов и более высокой платежеспособность. В меньших городах, даже при равной плетажеспособности, люди реже будут пользоваться такими же сервисами, просто потому что не нужно. До 1991 года города строились по принципу пешей доступности, чтобы людям не нужен был личный автомобиль, всё необходимое можно было получить пешком, школы, детские сады, магазины, рынки, поликлиники. В остальных случаях общественный транспорт всё решает. Даже время работы практически всего в городах разное. В небольших, практически всё открывается к 8 часам утра. В крупных даже детские сады и школы могут начинать занятия в 9-10 часов. Потому что иначе просто не успеют родители привезти детей через пол-города по пробкам, а сотрудники также не успеют на работу. Но и заканчивают в малых городах к 4 часам после полудня. А в мегаполисах вполне нормально работать до 7-8 часов вечера. Современный мегаполис - это страшный микс устаревающих районов с пешей доступностью всего, непонятного хаоса застройки на протяжении 20 лет. И потом опять вернулись к комплексной застройке с сервисами в пешей доступности на территории ЖК. В меньших городах за те самые 20 лет не строилось практически ничего за редким исключением. В сёлах, опять же другая картина, там без авто никто не живёт практически из за больших растояний. Но и там картина изменилась, всё меньше людей живут с подсобного хозяйства. И всё больше живут обеспеченные люди, которые могут себе позволить и дом побольше и соответственно и автомобиль или 2-3 на семью. Они опять же вряд ли будут пользоваться каршерингом, а предпочтут купить в личное пользование. Например, как выглядит доставка продуктов в Греции в городке с населением 4-5 тысяч. Просто в определённое время один и тот же фермер едет на своём грузовичке, останавливается каждые 500 метров. К нему выходят люди и покупают необходимые им продукты. Зачем им отдельный сервис доставки? Ну и размеры города - таковы, что за 10 минут его можно полностью пройти пешком.
А кто втирал- то?
Я как-раз обратное предлагал. В весьма доходчивой форме.
Процессы - спасают от много, но от людей которые их сознательно не выполняют спасти увы не могут. Это как техника безопасности на любом предприятии, все обязаны знать, но все на неё плюют. А потом несчастные случаи на производстве.
Идеальной документации, может быть и не бывает, но нормальная просто обязана быть. Или, как я уже сказал, можно выкидывать тестирование, так как в нем не будет никакого смысла. Просто делаем продукт силами нескольких программистов.
Если речь касается Энтерпрайза - всё просто. Открываем нужный ISO и читаем. Там всё прописано с полной инструкцией как провести приоритезацию модулей/юнитов, какой уровень документации какому модулю необходим. Но для это сначала нужна архитектура, где будет расписано, где какой модуль, сколько уровней интеграции, есть ли зависимость на hardware, third party, etc.
Нет архитектуры, нет требований, нет описания интерфейсов, так и говорить не о чем. Предел возможностей на таком проекте - это юнит тестирование.
Где вы увидели, что увольнять нужно всех? Только тех, кто не владеет базовыми навыками коммуникации, саботирует работу всей команды и является не компетентным. И то после 1-2-3 предупреждений на усмотрение бизнеса.
Мне вот довелось поработать как в стартапах на 5 человек, так и в медицинском энтерпрайзе по роботизированной хирургии, где одних SDET было 120 человек. А еще сверху отдельный департамент QA, который следил за работой как разработчиков, так и тестировщиков, чтобы всё было по ISO 13485 и ISO 62304. Так что всё бывает.
Просто невозможно сделать медицинскую установку, автомобиль или самолёт по тем же процессным подходам, архитектурным паттернам и уровню документации как очередной веб- магазин или онлайн-казино.
Банально не пройдёте сертификацию и не сможете ничего продать. Ну в крайнем случае выйдет как у Боинга, всех обмануть пока 2 самолёта не упадёт, а теперь бизнес активно загибается.
Так что не торопитесь утверждать, что так не бывает, если конкретно у вас небыло такого опыта.
Если у вас нет актуальной документации - значит у вас нет тестирования, а то что есть - это полная профанация. Потому как тестирование, это сверка документации с реальным поведением продукта. Нет документации - не с чем сравнивать, продукт живёт своей жизнью и о качестве даже бесполезно поднимать разговор. Таким продуктам не нужны ни Архитекторы, ни Тестировщики. Только вот реакция пользователей потом вполне ожидаема и предсказуема.
Вот читаю я все эти ситуации и мне кажется, что тут что-то пошло не туда в мире IT. Я вообще не понимаю, что значит Инженер не понимает зачем нужен Архитектор и саботирует его задачи? Обычно за такое делают выговор, а если не понятно увольняют.
Тут ровно 2 проблемы:
Это не задача Архитектора - доказывать Инженерам, что он нужен. Если он есть на проекте, значит бизнес принял такое решение, а значит и мотивы есть и есть чем объяснить это команде.
Если инженер не знает зачем нужен архитектор, значит он банально не компетентен. Наглядно ему это объяснить можно поставив одну из архитекторских задач по обоснованию и выбору БД, масштабируемости продукта или задач по оптимизации производительности. И потом просто показав как нужно решать такие задачи, а еще и не просто решать, но и обосновывать чем данный выбор лучше альтернатив.
Потому что это всё выглядит как непонятная возня вокруг девелоперов, чтобы они не дай Бог не обиделись. Разработка продукта - это не игрушки в первую очередь, хотя да этот аспект привносит хайп, веселье и улучшает атмосферу в коллективе. Но это не перво цель. Исходная причина - это зарабатывание денег компанией, для этого нужно всем работать в команде, уважать друг друга, и стараться решать задачи максимально приблеженно к срокам и заданию.
Это не ПЭТ-проект, не обучение отдельного инженера и не развлечение. Это - Работа. Поэтому задачи - это цели компании. Не согласен с задачей - спрашивай, обсуждай, пытайся разобраться. А не сиди себе тихонько в уголку и саботируй всю работу.
Это проблема не только архитекторов. Я как QA Engineer тоже с таким постоянно сталкиваюсь, что почему-то разработчики считают, что им нужно доказывать и учить, зачем нужно писать юнит-тесты, использовать статические инструменты анализа, документировать интерфейсы и думать что именно в них должно быть и как, и т.д.
Самый эпик который мне приходилось слышать от Principal Software Develooment Engineer:
"Почему это наш код, должен соответствовать задокументированной Архитектуре?"
Я даже не нашёлся, что ответить. Но через два месяца всё было отрефакторено согласно архитектуре.
Выводы:
Software Develipment Engineer, работает над очень маленьким кусочком продукта, он даже представить себе не может, на сколько вся система сложна в целом и сколько усилий требуется на её согласованную, эффективную и бесперебойную работу. В силу ограниченности этого, он физически не может принимать верные архитектурные решения, просто из-за отсутствия информации для видения полноты картины.
Это нормально, Архитекторы работают вширь продукта, разработчики же сосредоточены на работе вглубь отдельных частей. Они могут разбираться в моделях за которые ответственны гораздо лучше архитектора, но они никогда не будут лучше понимать поведение продукта в целом. Если это происходит, значит у человека просто не верный титул в подписи почты.
Результат работы Архитектора - архитектурные документы в различных их реализациях. Результат работы Инженера - это Дизайн документы отдельных модулей, их реализация в коде и юнит тесты на данный код в соответствии с дизайн документом.
Ну и естественно должно быть traceability между modules, units, software items в архитектуре с дизайн документами раскрывающими данный сущности.
Оставляя деньги в руках богатых, ты растлеваешь богатых и они у них заканчиваются. Давая деньги просто так бедным, ты растлеваешь бедных. Поэтому они там навсегда и останутся, так никогда и не став богатыми.
Не всегда у тебя будет выделенный девопс на проекте. А иногда у меня были такие девопсы, что это превращались в боль. Приходилось им писать пошаговую инструкцию, что нужно сделать. Доступов команде не давали из-за безопасности, а девопсы с доступами просто не владели нужным стеком, владели другим. Но проект стартануть нужно было быстро, а размер проекта порядка 200 человек.
Проще самому было сделать, но всё упиралось в доступы.
Не всегда бывает так. Хотя и довольно часто. По-хорошему, решение выпускать в релиз или нет - принимает как раз Продукт-Менеджер. Задача тестировщика позволить ему сделать информированое решение. Т.е. предоставить максимально подробный и правдивый отчёт о текущем состоянии продукта/релиза. А там уже ответственность Менеджера выпускать это или нет. Еще ему можно помочь адекватным тестпланом, в котором должно быть прописано - допустимый уровень дефектов каждого приоритета. Если допустимый уровень zero bugs, тогда можно и блокировать. Но таких продуктов не так уж и много. Все равно какой-то уровень minor/cosmetic допустим.
Собеседование - нужно проводить под позицию. Конечно интервьюверу. проще написать список стандартных вопросов и идти по ним.
Но толку от таких собеседований мало.
Я стараюсь учитывать все аспекты. Что реально нужно будет делать, состав команды, какие области нужно будет закрыть, бизнес домен и т.д.
Можно получить факап по любой из этих причин. Например, сильный алгортмист, но на проекте это не нужно, от слова совсем. И девопсов выделенных нет, а он ни в кубернетс не умеет, ни с облаками не работал и терраформ не знает. Да и банально не может поставить пайплайн с юнит-тестами, сборкой и развёртыванием.
Ну и наоборот бывает, человек всё умеет, а ему никто прав не даст, все построено и девопсов целая команда, а от него нужно только код хороший писать с глубоким погружением в архитектуру.
Или всё классно, но человек только приложения делал, а тут embedded а он даже даташит со схемой прочитать не может.
Или моё любимое, медицинский домен. Можно иметь кучу знаний и всё уметь, но запороть проект недооценив важность процессов. И закомитив, что-то до подписания всех необходимых бумаг.
Просто не берите принтеры Canon. С остальными проблем не помню.
Я остановился на среде Mate и Linux Mint.
Долго сидел на KDE, но после того как упёрся в его баг с тайлингом по хоткеям на цифровой клавиатуре. Оставил все попытки. 10 лет никто не хочет это починить. А я уже не могу без перекидывания окон на пол экрана или на другой монитор.
Gnome давно не понравился. Из коробки многое не работает, нужно допиливать постоянно из консоли или фиксить.
Когда покупал последний компьютер под Линукс, остановил выбор на AMD и Radeon. Помнил долгие муки с драйверами лет 15 назад под ATI. И был приятно удивлён увидеть видео теперь прямо в ядре.
Для игр придётся по-прежнему многое таскать для починки звука и видео, особенно для старых игр без поддержки FullHD. Если не хочется, есть всем известный трекер. Там игры вместе с собранным и настроенным под конкретную игру wine идут.
Так-то оно так. Но если двигаться в этом направлении. То практически всё сегодня многопоточно. Потому что процессоры многоядерные и зачастую мультитредовые. Тогда можно поставить гипервизор, развернуть N операционных систем, поднять в них любую среду и написать приложение которое будет в этом всём работать. Ну или просто какой-нибудь Kubernetes развернуть. Только всё это будет сделано вовсе вовсе не средствами языка программирования. И некоторые операции станут сильно дорогими в плане времени.
Что-то наблюддается некоторая мешанина терминов. Мне вот всегда было непонятно это стремление ссылаться на всякие странные сайты. С одной стороны там есть некая агрегация данных и знаний, с другой стороны, каждый использует своё видение видов, уровней, техник и методик тестов. Есть ISTQB и RUP. Чем они не угодили? Почему нельзя использовать их терминологию. Она хотя бы общепринята. Выделение тестирования изменений в одном уровне с функциональным и нефункциональным тестирование - крайне странно. Тестирование изменений ровно также включает функциональное и нефункциональное тестирование. Является общим множеством smoke, sanity & regression. Обычно виды тестов делят принципиально на функциональные и нефункциональные. А дальше внутри идёт ветвление которое спрашивать наизусть полностью не имеет смысла. Я обычно просто спрашиваю примеры.
Это не совсем рынок так устроен. Это так устроен круг людей проводящих технические собеседования. Которые иногда просто спрашивают то что нравится им самим, или просто находят вопросы в интернете. А кандидаты также находят ответы на эти вопросы. Всё таки нужно больше стараться отталкиваться от конкретной позиции, конкретного состава команды и продукта. Но как говорил один боксёр:"Все, но не каждый" могут так делать.
В реальности фреймворк на проекте поднимается 1 раз, ну может 2. Это не то знание, которое будешь применять каждый день. Для этого достаточно открыть документацию, прочитать, осознать и применить. Вот этот навык куда важнее, знания наизусть информации, которая и так всегда под рукой. Вот работу с git, ревью, составление тестовых сценариев, работа с тестовыми данными, просмотр результатов, триаж и починка CI - это действительно то что применяется каждый день.
Кроме того, надо понимать домен в котором работаешь. У меня на одном собеседовании волосы дыбом вставали. Когда спрашивали по Python перечни базовых методов, магисеские мотоды классов, декораторы и т.д. Когда я спросил зачем, то получил ответ который меня ввёл в ступор. Потому что обычно идут путём привлечения девеелоперов для написания моков и стабов и возможно базовых методов взаимодействия тест фреймворка с продуктом. Но тут решили что тестировщики должны помочь девелоперам переписать продукт под новую версию Python.
Но интервьювер вообще не принял в рассчёт одну такую маленькую деталь. Что продукт был медицинским. А тут по стандарту не могут быть никаких смешений взаимодействия разработчиков и тестировщиков. В идеале - это вообще должны быть люди из разных организаций с максимальным уровнем независимости на принятие решений.
Ну найдут они подходящего кандидата по соображениям тех интервьювера. Но при сдаче проекта внезапно осознают, что всё сделанное нужно переделать. Потому как FDA такую халтурку в жизни не пропустит, когда код писал и полностью тестировал один и тот же человек.
Так что сейчас есть наглядная проблема больших контор которые подводят унификацию требований для кандидатов сами не осознают область на которую эту унификацию стоит и можно расспространять.
Всё таки в идеале, интервью должны проводить люди имеющие прямое отношение к конкретному проекту. А сейчас получаем в большинстве случаев - когда интервьювер, в лучшем случае, получил строк 20 описания проекта. Пришёл проводить интервью, потому что за эту активность можно получить некий бонус. И задаёт вопросы, которые весьма интересны с точки зрения погружения в глубины языка. Но ответы на которые можно будет благополучно забыть ровно до следующего интервью.
Спрашивать-то, спрашивают. Только толку от этого. Вот сколько раз потом на практике понадобилось писать код маркером на доске?
Сколько проектов по тестированию требуют глубоких знаний базовых методов языка?
Куча проектов по поддержке, где вся работа сводится исключительно к написанию новых тестов и выпишиваеию старых. Кстати, я бы сказал они именно идеальная среда для начала карьеры. Есть куча примеров и можно по разбираться на текущей базе кода как всё работает. Никаких гарантий, что это будет наилучший вариант. Но для базы, понимания архитектуры фреймворка и базовых слоёв подойдёт.
В тестировании нэгораздо больше пользы от понимания тест фреймворков, их возможностей и ограничений.
Некоторые фреймворки вообще ломают логику базового языка.
Например, работа с Selenium в Python, всё равно превращает код в JAVA образный.
Поэтому лучше знать тестовые фреймворки и как их интегрировать. Почему Cypress подойдёт для тестирования онлайн магазинов, но не сложных бизнес приложений. Чем Playwright лучше Selenium. Чем так хорош pyTest и как его осилить после jUnit и TestNG. Как тесты параллелизировать и с какой CI.
Почему Azure в минимальной подписки не имеет смысла. И т.д.
Я вам блольше скажу. Алгоритмы, нынче, даже у тестировщиков на собеседованиях спрашивают.
Человек всегда выбирает на что тратить своё время. В маленьком городе - больше времени на себя, семью, но вероятно меньше зароботок. В большом городе - больше зароботок. Но нет времени самому приготовить себе обед, погулять с ребенком и в целом провести время с семьёй. И эти пробемы создают не технологии, а всё та же проблема плотности начеления и пробок. Либо ты будешь тратить 15-20 минут похода на работу пешком. Либо 2-3 часа сидеть в пробках в автомобиле, а потом пытаться выкроить время для спорзала. А все эти технологии - это лишь средства удовлетворить запрос конретного общества в конкретных условиях.
Каршеринг, всё таки несколько снижает транспортную нагрузку хоть и косвенно. Такие авто - меньше простаивают, а значит в случае приехал на работу и нет частной парковки, такое авто будет меньше занимать крайнюю полосу там где парковка допустима. Хотя, конечно общественный транспорт справляется с этой задачей намного лучше. Так же хорошо справляются электроскутеры, которые мопеды. Но это вещь тоже сезонная.
Что-то много недосказанности. А как же сторона DevOps и тулов?
ИМХО - мидл, должен хорошо знать техническую предментную область - язык программирования, паттерны, архитектуры - это всё легко учится из теории. А старшой - должен уже обладать более широкими софт скилами, знать разницу гибких и строгих методологий. И главное уметь плясать от продукта, а не от того что он умеет. Не совать везде - я так 20 лет он-лайн магазины писал и UI на приборку авто так же буду делать. А уметь выбрать оптимальную методику, архитектуру, паттерны. Уровень документации от самодокументируемого кода, до Detailed Design, Software&System Architecture документов. Объяснять мидлам и джунам, почему их супер-навыки в Vim в данной команде будут только во вред и что он не просто так потратил время на конфиг для IDE и настроили pre-commit git hooks. И сколько дрвгоценного времени это экономит. Ну и опять же это всё если проект для команды или нескольких команд. А если проект на 2 недели на коленке в одно лицо что-то состряпать. То тут не стоит убиваться и поднимать CI/CD на 4 энвайронментах. И писать конфиги, ревью чек-листы и архитектурные документы.
Даже если исключить финансовое неравество. У жителей мегаполисов и меньших городов - разные запросы и потребности. В мегаполисе сложно без авто добраться до работы, кинотеатра, любимого ресторана и т.д.
В маленьких городах - это зачастую довольно просто сделать пешком. Кроме того улицы не столь перегружены автомобилями, поэтому собственный автомобиль доставляет больше радости.
Вот еду можно заказывать одинаково. Хотя в целом, чем меньше город, тем размереннее ритм жизни.
Поэтому для скорейшего возврата инвестиций сервисы и откатывают в районах с большей плотностью населения, а значит упрощенной логистикой, большим колличеством потенциальных клиентов и более высокой платежеспособность. В меньших городах, даже при равной плетажеспособности, люди реже будут пользоваться такими же сервисами, просто потому что не нужно.
До 1991 года города строились по принципу пешей доступности, чтобы людям не нужен был личный автомобиль, всё необходимое можно было получить пешком, школы, детские сады, магазины, рынки, поликлиники. В остальных случаях общественный транспорт всё решает. Даже время работы практически всего в городах разное. В небольших, практически всё открывается к 8 часам утра. В крупных даже детские сады и школы могут начинать занятия в 9-10 часов. Потому что иначе просто не успеют родители привезти детей через пол-города по пробкам, а сотрудники также не успеют на работу. Но и заканчивают в малых городах к 4 часам после полудня. А в мегаполисах вполне нормально работать до 7-8 часов вечера. Современный мегаполис - это страшный микс устаревающих районов с пешей доступностью всего, непонятного хаоса застройки на протяжении 20 лет. И потом опять вернулись к комплексной застройке с сервисами в пешей доступности на территории ЖК. В меньших городах за те самые 20 лет не строилось практически ничего за редким исключением.
В сёлах, опять же другая картина, там без авто никто не живёт практически из за больших растояний.
Но и там картина изменилась, всё меньше людей живут с подсобного хозяйства. И всё больше живут обеспеченные люди, которые могут себе позволить и дом побольше и соответственно и автомобиль или 2-3 на семью. Они опять же вряд ли будут пользоваться каршерингом, а предпочтут купить в личное пользование.
Например, как выглядит доставка продуктов в Греции в городке с населением 4-5 тысяч. Просто в определённое время один и тот же фермер едет на своём грузовичке, останавливается каждые 500 метров. К нему выходят люди и покупают необходимые им продукты. Зачем им отдельный сервис доставки? Ну и размеры города - таковы, что за 10 минут его можно полностью пройти пешком.