Интересно, но ради 2х диском, я бы так не заморачивался. Первый мой NAS был DLink 325. Сначала в нём умерло 2 Сигейт Барракуды, причём практически одновременно, за что я теперь их очень не люблю. Потом, пока занимался вопросами здоровья жены, и не отключил ΝΑS, прилетел CR1PT0R. А DLink просто положио на пользователей, ведь дыра была оставлена DLink в виде статичных кредов, которые они оставили для тестирования в продакшен версии прошивки. За что теперь я не люблю DLink. Но даже так идея уменьшать ёмкость в 2 раза рейдом мне не сильно нравилась и тогда я просто настроил автоматическое копирование критических данных как фотографии, фильмотеку и видео я не копировал, чтобы не забивать этим пространство. На следующий раз после шифровальщика - я купил AsusTOR 6404 потому что уже хотел миниму 4 диска. Тогда уже можно и пожертвовать 1м в пользу рейда. Тоже прилетал какой-то шифровальщик, но мне в этот раз повезло, NAS был выключен и я закончил игры с выбрасынием доступа к нему. Теперь только доступ в локальную сеть через VPN. Ну и поддержка BTRFS тоже радует. Единственное, что не радует политика всех вендоров против KODI(XBMC). Это был один из аргументов покупки данного вендора, но потом поддержку KODI выпилили с кривой аргументацией по настоянию правообладателей контента, якобы KODI активно используется в пиратстве. Я же подозреваю, что по настоянию Plex, чтобы ничего бесплатного людям не давать и подсаживать на подписки. В общем ΤrueNAS - определённо плюс к безопасности и управлению. Но зачем мастерить стоечный NAS аж на 2 диска - я не очень понял.
Проблем много, но как идея мне в голову приходило какое-то время назад, когда стали убирать зарядки из комплектации телефонов. Я так призадумался сколько же стоит выпрямителей напряжения в нашей любимой электроники. И сколько же их можно было бы выкинуть, если бы в доме была сеть 12 вольт. Только опять незадача. Куча электроники хочет кучу разных напряжений, 3.3, 5, 12, 24, И это только в одном компьютере. А так еще бывают всякие 15 и 20 Вольт. Это все здорово, но какую же работу по стандартизации придётся сперва проделать, чтобы сократить этот зоопарк. И тут возникает вопрос курицы и яйца - а стоит ли игра свеч.
Ну не знаю, меня в школе приучили, что надо выбирать не просто справочник автора какого-то, а от конкретного издателя и конкретное издание с исправлениями, чтобы не парится по ошибкам. Учебники физики и математики новые массово стали печатать в 90х. Мы получали прям список какие нельзя использовать, хотя и новая программа школьная их рекомендовала. Учителя сказали, что это фуфло редкое, поэтому берите старые советские автор такой-то, издательство, год, и т.д. В университете было то же самое. Справочник по частным характеристикам транзисторов. Даже говорили в какой из университетских библиотек он лежит и сколько там экземпляров. Так что, я пожалуй не вижу ничего странного в том что нужно понимать что за книга и какой можно доверять.
Лет 12 пользовался Sony SVS 15". Сестре двоюродной посоветовал и купили SVS 13". На то время 2012 год, это была прям революция. 15 дюймов в 2 кг, и 13 - около 1,5. Ремонтопригодность - прямо скажу была весьма плохой. Для чистки требовалось разобрать полностью, а не просто снять нижнюю крышку, потому как система охлаждения была на другой стороне платы. В остальном - одни плюсы. Док станция со встроенным дополнительным диском - тоже просто супер. Зарядка всегда в рюкзаке или в другом месте, дома можно от док-станции заряжаться. Для тех кому больше автономности и не критичен вес, допустим аккумулятор нашлёпывался на днище, где есть специальный разъём для него. Тогда 15" превращались в порядка 2,8 кг как и остальные на рынке, но с автономной часов 7. Клавиатура - прелесть. стрелки хоть немного уменьшенные, но не слеплены в 1 ряд. Огромный по тому времени тач-пэд с поддержкой круговой прокрутки, которую нехорошие люди, сломали после Windows 7. До сих пор лежит. Чистил его и апгрейдил по мелочи, SSD, и память. Поскольку один слот распаян на плате в виде 4ГБ, максимально было 12 ГБ. Проц не менял, там и так стоял i7. Сейчас перешёл на Asus Pro Art 16. Те же 2 кг, и металлический корпус, намного больше мощи. Ryzen 7 и 32 ГБ памяти с апгрейдом до 64. Круговой прокрутки нет на тачпаде. Но зато есть прокрутка на физической крутилке. Жене взял ZenBook - 1,3 кг на 14 дюймов. Считаю Asus сейчас топ. Да, я как раз за OLED экраны. Кому не нравиться есть варианты без них.
Зачем Вы читаете, если Вам это тяжело? Откуда вы выдумали 95% случаев? Это исключительно ваш, очень узкий опыт. Зачем его экстраполировать? И да программистов, которые задают вопросы зачем нужны архитекторы и саботируют работу - стоит увольнять. Потому что, компетентный инженер, сам напишет необходимую архитектуру(блок-схему алгоритма, машину состояний- диаграмму классов и т.д.), а не будет задавать вопросы, кто такой архитектор и зачем он нужен. Можно еще так же поспрашивать, кто такой менеджер и зачем он нужен? Что такое бизнес и зачем он нужен? Только долго ли на такое будут закрывать глаза?
Мир изменился. Я чувствую это по воде. (с) Просто всё больше и больше мир зависит от программных продуктов. А как следствие - продукты усложняется. Из этого же вытекает, что команда разработки - это уже не просто разработчик и тестировщик. Есть Software Development Engineer, Software Development Engineer in Testing, QA Engineer, Business Analytic, Product Owner, Project Manager, Test Manager, Software Architector, Test Architector, Solution Architector, Electronic Engineers, Mechanic Engineer, HW Test Engineer, System Test Engineer, DevOps Engineer, DevSecOps Engineer etc. Тут уже не так просто провести линию и сказать кто из этих ролей тестировщик, а кто разработчик. Но концептуально, эти роли нельзя смешивать, потому как мышление противоположное. Из своего опыта я видел только такие случаи. Мышление разработчика: один раз сработало - значит работает. Мышление тестировщика: один раз не сработало - значит не работает. И так и должно быть, а потом уже возникает коммуникация и в этом споре рождается истинна. Вероятно существуют разработчики, знакомые с всевозможными пирамидами тестирования, всеми видами и типами тестирования, а также владеющими всеми методиками. Но, лично мне такие не попадались. Максимум, что я видел, они создали очень много различных тестов. Но когда, подходит вопрос, а какие тесты собственно нужно запускать и в каких случаях. Самый частый ответ - все и всегда. И вот тут как раз и приходят на помощь pair wise таблицы, граничные значения, классы эквивалентности, распределение quality gates, построение пирамиды под продукт, а не просто взять из книги/интернета, определение какие виды тестирования закрыть самим, а где подключить подрядчиков ну и Test Plans соответственно. И чтобы всё это подгадать к нужному релизу. Ну и время тест рана не стремилось к бесконечности. Плюс до сих пор не осел туман войны Agile universal team VS Universal Engineer. Уж очень последнего хочется бизнесу, чтобы не разбираться во всех ролях перечисленных вначале, ну и чтобы не нужно было каждого из них хотя бы по 2, чтобы и в отпуск можно было сходить, а работа не встала, ну и ревьювить результат кто-то должен.
Ну вот поэтому, продукты берут и выкидывают, а потом переписывают с нуля, потому что разобраться в таком легаси - дороже выйдет. Хотя в принципе это тоже вполне рабочий вариант. Если бизнес на таком продукте отбил вложения и даже заработал, то почему нет?
Процессы - спасают от много, но от людей которые их сознательно не выполняют спасти увы не могут. Это как техника безопасности на любом предприятии, все обязаны знать, но все на неё плюют. А потом несчастные случаи на производстве. Идеальной документации, может быть и не бывает, но нормальная просто обязана быть. Или, как я уже сказал, можно выкидывать тестирование, так как в нем не будет никакого смысла. Просто делаем продукт силами нескольких программистов. Если речь касается Энтерпрайза - всё просто. Открываем нужный 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. Обычно виды тестов делят принципиально на функциональные и нефункциональные. А дальше внутри идёт ветвление которое спрашивать наизусть полностью не имеет смысла. Я обычно просто спрашиваю примеры.
Интересно, но ради 2х диском, я бы так не заморачивался. Первый мой NAS был DLink 325. Сначала в нём умерло 2 Сигейт Барракуды, причём практически одновременно, за что я теперь их очень не люблю. Потом, пока занимался вопросами здоровья жены, и не отключил ΝΑS, прилетел CR1PT0R. А DLink просто положио на пользователей, ведь дыра была оставлена DLink в виде статичных кредов, которые они оставили для тестирования в продакшен версии прошивки. За что теперь я не люблю DLink. Но даже так идея уменьшать ёмкость в 2 раза рейдом мне не сильно нравилась и тогда я просто настроил автоматическое копирование критических данных как фотографии, фильмотеку и видео я не копировал, чтобы не забивать этим пространство. На следующий раз после шифровальщика - я купил AsusTOR 6404 потому что уже хотел миниму 4 диска. Тогда уже можно и пожертвовать 1м в пользу рейда. Тоже прилетал какой-то шифровальщик, но мне в этот раз повезло, NAS был выключен и я закончил игры с выбрасынием доступа к нему. Теперь только доступ в локальную сеть через VPN. Ну и поддержка BTRFS тоже радует. Единственное, что не радует политика всех вендоров против KODI(XBMC). Это был один из аргументов покупки данного вендора, но потом поддержку KODI выпилили с кривой аргументацией по настоянию правообладателей контента, якобы KODI активно используется в пиратстве. Я же подозреваю, что по настоянию Plex, чтобы ничего бесплатного людям не давать и подсаживать на подписки.
В общем ΤrueNAS - определённо плюс к безопасности и управлению. Но зачем мастерить стоечный NAS аж на 2 диска - я не очень понял.
Проблем много, но как идея мне в голову приходило какое-то время назад, когда стали убирать зарядки из комплектации телефонов. Я так призадумался сколько же стоит выпрямителей напряжения в нашей любимой электроники. И сколько же их можно было бы выкинуть, если бы в доме была сеть 12 вольт. Только опять незадача. Куча электроники хочет кучу разных напряжений, 3.3, 5, 12, 24, И это только в одном компьютере. А так еще бывают всякие 15 и 20 Вольт.
Это все здорово, но какую же работу по стандартизации придётся сперва проделать, чтобы сократить этот зоопарк. И тут возникает вопрос курицы и яйца - а стоит ли игра свеч.
Ну не знаю, меня в школе приучили, что надо выбирать не просто справочник автора какого-то, а от конкретного издателя и конкретное издание с исправлениями, чтобы не парится по ошибкам. Учебники физики и математики новые массово стали печатать в 90х. Мы получали прям список какие нельзя использовать, хотя и новая программа школьная их рекомендовала. Учителя сказали, что это фуфло редкое, поэтому берите старые советские автор такой-то, издательство, год, и т.д.
В университете было то же самое. Справочник по частным характеристикам транзисторов. Даже говорили в какой из университетских библиотек он лежит и сколько там экземпляров.
Так что, я пожалуй не вижу ничего странного в том что нужно понимать что за книга и какой можно доверять.
Лет 12 пользовался Sony SVS 15".
Сестре двоюродной посоветовал и купили SVS 13". На то время 2012 год, это была прям революция. 15 дюймов в 2 кг, и 13 - около 1,5.
Ремонтопригодность - прямо скажу была весьма плохой. Для чистки требовалось разобрать полностью, а не просто снять нижнюю крышку, потому как система охлаждения была на другой стороне платы.
В остальном - одни плюсы. Док станция со встроенным дополнительным диском - тоже просто супер. Зарядка всегда в рюкзаке или в другом месте, дома можно от док-станции заряжаться. Для тех кому больше автономности и не критичен вес, допустим аккумулятор нашлёпывался на днище, где есть специальный разъём для него. Тогда 15" превращались в порядка 2,8 кг как и остальные на рынке, но с автономной часов 7.
Клавиатура - прелесть. стрелки хоть немного уменьшенные, но не слеплены в 1 ряд. Огромный по тому времени тач-пэд с поддержкой круговой прокрутки, которую нехорошие люди, сломали после Windows 7.
До сих пор лежит. Чистил его и апгрейдил по мелочи, SSD, и память. Поскольку один слот распаян на плате в виде 4ГБ, максимально было 12 ГБ. Проц не менял, там и так стоял i7.
Сейчас перешёл на Asus Pro Art 16. Те же 2 кг, и металлический корпус, намного больше мощи. Ryzen 7 и 32 ГБ памяти с апгрейдом до 64.
Круговой прокрутки нет на тачпаде. Но зато есть прокрутка на физической крутилке.
Жене взял ZenBook - 1,3 кг на 14 дюймов. Считаю Asus сейчас топ. Да, я как раз за OLED экраны. Кому не нравиться есть варианты без них.
Зачем Вы читаете, если Вам это тяжело?
Откуда вы выдумали 95% случаев? Это исключительно ваш, очень узкий опыт. Зачем его экстраполировать?
И да программистов, которые задают вопросы зачем нужны архитекторы и саботируют работу - стоит увольнять.
Потому что, компетентный инженер, сам напишет необходимую архитектуру(блок-схему алгоритма, машину состояний- диаграмму классов и т.д.), а не будет задавать вопросы, кто такой архитектор и зачем он нужен. Можно еще так же поспрашивать, кто такой менеджер и зачем он нужен? Что такое бизнес и зачем он нужен?
Только долго ли на такое будут закрывать глаза?
Мир изменился. Я чувствую это по воде. (с)
Просто всё больше и больше мир зависит от программных продуктов. А как следствие - продукты усложняется. Из этого же вытекает, что команда разработки - это уже не просто разработчик и тестировщик. Есть Software Development Engineer, Software Development Engineer in Testing, QA Engineer, Business Analytic, Product Owner, Project Manager, Test Manager, Software Architector, Test Architector, Solution Architector, Electronic Engineers, Mechanic Engineer, HW Test Engineer, System Test Engineer, DevOps Engineer, DevSecOps Engineer etc.
Тут уже не так просто провести линию и сказать кто из этих ролей тестировщик, а кто разработчик.
Но концептуально, эти роли нельзя смешивать, потому как мышление противоположное.
Из своего опыта я видел только такие случаи. Мышление разработчика: один раз сработало - значит работает.
Мышление тестировщика: один раз не сработало - значит не работает.
И так и должно быть, а потом уже возникает коммуникация и в этом споре рождается истинна.
Вероятно существуют разработчики, знакомые с всевозможными пирамидами тестирования, всеми видами и типами тестирования, а также владеющими всеми методиками. Но, лично мне такие не попадались. Максимум, что я видел, они создали очень много различных тестов. Но когда, подходит вопрос, а какие тесты собственно нужно запускать и в каких случаях. Самый частый ответ - все и всегда. И вот тут как раз и приходят на помощь pair wise таблицы, граничные значения, классы эквивалентности, распределение quality gates, построение пирамиды под продукт, а не просто взять из книги/интернета, определение какие виды тестирования закрыть самим, а где подключить подрядчиков ну и Test Plans соответственно. И чтобы всё это подгадать к нужному релизу. Ну и время тест рана не стремилось к бесконечности.
Плюс до сих пор не осел туман войны Agile universal team VS Universal Engineer. Уж очень последнего хочется бизнесу, чтобы не разбираться во всех ролях перечисленных вначале, ну и чтобы не нужно было каждого из них хотя бы по 2, чтобы и в отпуск можно было сходить, а работа не встала, ну и ревьювить результат кто-то должен.
Ну вот поэтому, продукты берут и выкидывают, а потом переписывают с нуля, потому что разобраться в таком легаси - дороже выйдет.
Хотя в принципе это тоже вполне рабочий вариант. Если бизнес на таком продукте отбил вложения и даже заработал, то почему нет?
А кто втирал- то?
Я как-раз обратное предлагал. В весьма доходчивой форме.
Процессы - спасают от много, но от людей которые их сознательно не выполняют спасти увы не могут. Это как техника безопасности на любом предприятии, все обязаны знать, но все на неё плюют. А потом несчастные случаи на производстве.
Идеальной документации, может быть и не бывает, но нормальная просто обязана быть. Или, как я уже сказал, можно выкидывать тестирование, так как в нем не будет никакого смысла. Просто делаем продукт силами нескольких программистов.
Если речь касается Энтерпрайза - всё просто. Открываем нужный 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. Обычно виды тестов делят принципиально на функциональные и нефункциональные. А дальше внутри идёт ветвление которое спрашивать наизусть полностью не имеет смысла. Я обычно просто спрашиваю примеры.