В целом автор не пишет ничего вредного или неправильного, всё так. Но есть о чем возразить.
Идея о том, что если много и усердно работать и идти к своей мечте то обязательно достигнешь успеха возникает из за когнитивного искажения, называемого «верой в справедливый мир».
В мире, существует множество предопределённых факторов, о которых страшновато признаваться самому себе. И один из них это уровень интеллекта, залженный генетически, подобно стеклянному потолок ограничивающий способности (и возможности) человека.
Так же очень важен фактор счастливой случайности, о котором ох как не любят говорить достигнувшие успешного успеха. Т.к. это снимает с них ответственность за достижение и переносит на внешние факторы, словно наградные медали снимают с шеи.
Еще очень важно социально экономическое положение человека. Какой-то трудяга с семьёй, задолбан кучей забот и не может позволить себе рисковать. Другой же может десять лет спокойно работать, находясь под покровительством родственников или спонсора, совершить множество попыток в разных сферах жизни, зная что его подстрахуют...
Ну и советы типа «Если вы перфекционист, просто перестаньте бояться» довольно бесполезные, т.к. расстройства личности возникают в детстве и за десятилетия жизни влияют на мышление и поведение человека и чтобы это скорректировать нужно работать, переучивать нейросетку в голове к более здоровым шаблонам восприятия и поведения. А это само по себе большой объём работы и немалый срок.
Вот еще лайф-хак. Мышление человека в основном вербально. Когда мы обдумываем что-то, мы мысленно облекаем это в слова и фразы, а мозг тут же готовит под них речевой аппарат. Непроизнесенная речь приводит к слабой артикуляции, выражающейся в напряжении мышц гортани, языка, лица. Если обдумывать что-то во время приема пищи, то речевое напряжение вступает в противоречие с напряжением тех же мышц для жевания и глотания. В результате — прикусанные языки, щеки и губы. Чтобы этого избежать, не нужно думать во время еды. Кодить тоже не нужно.
Как-то все это похоже на "Выучи Х и станешь Y". Хотя все знают, что эта формула по сути вранье. Учиться нужно постоянно, и в лучшем случае она должна выглядеть как "Для работы в качестве Y может быть полезным знать X" И тогда оказывается, что полезным может быть все.
Я например в молодости читал Лебедева по дизайну, и могу аргументированно доносить нефункциональные баги в пользовательском интерфейсе до "стейкхолдеров". И это невероятно полезный навык, понимать азы правильного устройства интерфейсов. И что еще важнее как аргументировать убедительно, но не обидно.
Или например, как насчет навыка письма и общения. Я должен сказать, что комментирование на хабре и других платформах здорово прокачало мои коммуникационные навыки за пару лет. Потому что для этого сперва нужно иметь мнение, а потом постараться выразить его так чтобы никому не навредить, даже если это критика. А тестировщик он всегда критик (в хорошем смысле этого слова). Не критикан, а критик. Для этого нужно развивать критическое мышление. Задаваться вопросами. А почему так. Не принимать все на веру. Спрашивать себя "а что если".
А что касается практики - пожалуйста, бесплатная практика:
Берем любую опенсорсную софтину.
Разбираемся в ее устройстве.
Находим в ней ошибки.
Открываем багтрекер проекта.
Регистрируемся.
Пишем багрепорт с учетом гайдлайнов проекта.
Ждем когда баг категоризируют, распределят и начнут над ним работу
Отвечаем на дополнительные вопросы разработчика. Помогаем ему тестировать дополнительные сценарии, чтобы точнее выявить условия проявления нежелательного поведения.
Ждем когда баг починят и тестируем новый релиз
Profit Опыт.
Эти багрепорты публичные и на них можно легко сослаться, нет NDA. Создайте свой репозиторий на гитхабе и храните там ссылки на свои багрепорты. Понадобиться сослаться в резюме - удобно, одной ссылкой. Будет еще и подтверждение минимального опыта работы с Git. Ну и не будем забывать, что работа над опенсорсом у всех в почете.
Домашнее задание:
Найти публичные багтрекеры десяти опенсорсных проектов в интернетax.
Полезное упражнение: воспроизведите чужой баг Коли вы уже нашли публичные багтрекеры - покопайтесь в них, найдите открытый баг подходящий для воспроизведения в вашем окружении, воспроизведите его. Упражниение полезно в первую очередь для того, чтобы понять недостатки в багрепортах и самому стараться в будущем этих недочетов избегать.
Еще одноупражнение: Возьмите любое известное вам приложение, например на мобильном телефоне. Проследите за тем как именно вы пользуетесь определенной функцией. Опишите эту функцию в виде тестового сценария. Возьмите другое устройство, и проверьте работает ли этот сценарий на нем.
P.S.: Лайфхак, если не знаешь что можно тестировать в приложении. Я недавно пробовал ChatGPT и попросил его подсказать тестовые сценарии для <тип приложения>. И получил список вполне годных идей.
В случае формального языка — я очень рад выбору английского. Потому что когда я читаю код, то вместо некого подобия Рапиры (ПРОЦ СТАРТ(); ВЫВОД: "ЗДРАВСТВУЙ, МИР!"; КНЦ;), я вижу нечто марсианско-непонятное (условно говоря, が(); ら"blahblah"; ひ), и я просто выучил, что в начале любой функции стоит が, в конце ひ, а ら — это "напечатай вон то", при этом не отвлекаясь на смысл. Ну, практически как в старой хохме про называние цвета, которым написаны буквы — а не того, название которого этими буквами написано.
Цитирую абзац, из которого взята фраза на скрин-шоте:
Без единого подхода к метрикам соотнести команды между собой очень сложно. Трудно понять, какая команда драйвит, постоянно работает над улучшением качества поставок, а какой команде стоит обратить внимание на качество своей разработки. При этом внедрить единые метрики сложно, потому что они не работают без единых подходов.
Беда в том, что цитируемый менеджер не допускает даже мысли о том, что единой метрики для разных команд нет и быть не может. У кого-то продукт менее дефектоопасный, у кого-то сезон более простых проектов, а кто-то и вовсе формально работает компании в убыток, прибирая за другими командами или открыв сезон охоты на легаси... да мало ли причин! CI/CD в данном случае рекомендуется как дженерик, который с одной стороны облекает труд программистов в постижимую для непрограммистов единую форму, а во-вторых, не мешает и даже полезен самим программистам.
NB: я ни разу не автор - но я осмелюсь предположить, что автор имеет в виду что-то такое. Сам сталкивался и вроде бы что-то в этом понимаю... но мало...
Как НТшник не хотелось бы понижать коллегу. Но в чём смысл поста? Он бы хорошо подошёл для истории внутри компании, но не для Хабра. Тоесть просто перечисление инструментов которое используется. Имхо если добавить описание каких-то твиков которые могут упростить жизнь, это было бы полезно.
К примеру, в Apache Jmeter, если в View Result Tree во вкладке Response приходят нераспознаваемые ответы (кракозябры), в файл настроек Jmeter.properties в строку:
The encoding to be used if none is provided (default ISO-8859-1)
sampleresult.default.encoding=ISO-8859-1
Заменить (или закомментировать и добавить) строчку:
sampleresult.default.encoding=UTF-8
То ответы будут корректными. Либо сменить вариант с Text на JSON.
Множество спорных суждений, на сколько я вижу, выходят из непонимания блокчейнов. Например, инновация блокчейнов для сфере платежей в децентрализованном консенсусе (первый придумал bitcoin), и DAO который принёс Eth. Бесспорно, пихать блокчейны везде - плохая идея, и то что сейчас нет инструментов для работы со всем этим для обычных людей (всё для гиков), а что для обычных с красивым сайтом (binance), то совсем не пахнет как инновация. Не стоит забывать что блокчейн - инструмент, просто все ринулись создавать при помощи него новый банк, а деньги привлекают внимание.
Чтоб разобраться рекомендую только https://vas3k.ru/blog/web3/ , остальное будет про спекуляции, что уводит от идей которые приносит блокчейн.
Например тут всё время пытаются натянуть токен то на "доллар" то на предмет искусства, но ближе всего, если очень хочется аналогий из доцифрового мира, это бензин, за объяснениями к умному vas3k в статью о web3.
Все в точку. Может это и не полная матрица, но весьма и весьма полезная, с хорошо подбитыми тезисами, которые явно подкреплены личным опытом. Потому что ни в каком ISTQB этому не учат ;)
Мне кажется, что тут важно упомянуть, что один человек может считать высказывание другого ложью не потому, что оно лживое, а просто потому, что каждый из них видит только часть картины.
Притча про слепых и слона
Один раджа приехал в гости к падишаху из соседнего государства.
Он привез множество подарков, и среди них — живого слона. А так как падишах никогда в жизни не видел это животное, гость решил загадать загадку. Заведя слона в темный зал, раджа попросил правителя: «Пусть твои советники опишут слона, который здесь находится. Хочу узнать, насколько они мудры». Первый советник в кромешной тьме наткнулся на ногу животного. «Этот зверь, как громадное дерево», — сказал он. «Слон — это огромная извивающаяся змея», — возразил ему второй мудрец, который нащупал хобот животного. Третьему удалось погладить туловище слона. «О правитель, они оба лгут, — закричал он. — Слон похож на большой лист бумаги — такой же широкий и шершавый». Недоумевающий падишах обратился к радже: «Скажи, каков этот слон?» Когда гость вывел животное из зала, и мудрецы, и правитель сильно удивились. «Каждый из вас был прав по-своему. И все же все вы ошибались, — обратился раджа к советникам. — Ваши знания были неполными, ведь вы познали лишь часть целого. А потому слон оказался совсем не таким, каким вы себе его представляли».
И еще картинка в тему
А если вспомнить, насколько криво мы можем выражать свои мысли, то часто один просто неправильно услышал другого и назвал свое понимание услышанного ложью
Снижать когнитивную нагрузку (это когда задействованы мозги, скроллинг инстаграма, чтение хабра и "развивающих" статей и т.п.). Регулярно делать что-то скучное чтобы мозг имел возможность разгрузиться. Вроде мытья полов, посуды, прополки грядок и т.п. Современный человек лишен такого режима работы мозга, а он нам необходим.
Начать ходить пешком по 2-3 км в день. Лучше поменьше но пролонгированно, т.е. равномерно в течении месяца, а не так что один день 15 км прошел, а потом две недели не ходил. Важно при этом не грузить мозги прослушиванием музыки, подкастов и т.п.
Отслеживать и останавливать руминацию (зацикленные мысли в голове) делается довольно просто, нужно додумать эти "зависшие" мысли до какого-то вывода. И если руминация возникла, вспоминаете вывод и переключаете внимание на что-то другое волевым усилием.
Спать по 8 часов, выработав привычку оставлять вечером смартфон на кухне, а не залипать в светящийся экран перед сном.
Это самое простое и лишь по верхам. Ну и да, подгонять кофем удушенный хроническим стрессом и нагрузкой мозг это как давить в пол педаль газа на разваливающемся жигуле едущем по дороге с ухабами, лишь усугублять ситуацию.
Еще могу посоветовать отказаться от алкоголя, если употребляете. Но все эти советы лишь симптоматические, если у вас психологические проблемы, тревожное состояние и связанная с этим прокрастинация, то нужно разбираться целенаправленно. И со специалистом.
Да ничего не случалось, пропаганда всегда одинаково работает. Пока «мы» против «них» — «мы» белые и пушистые, все: и США, и СССР. Когда врагов победили — а какие «мы»?
Как писать простой и читаемый код
… не упоминая библиотеку из Github с наибольшим количеством звёзд, а показав мне пару своих лучших примеров кода.
Если кто-то отвечает на вопрос о том, как писать простой и читаемый код через "прост возьмите готовое" — он профнепригоден, только и всего.
Как управлять состоянием
… без упоминания популярной библиотеки управления состояниями (предпочтительно заканчивающейся буквой «X»), а объяснив мне, почему «данные должны двигаться вниз, а действия — вверх». Или почему состояние должно изменяться там, где оно было создано, а не глубже в иерархии компонентов.
Если и объяснения будут даны, они не отвечают на вопрос "как управлять состоянием". Они отвечают на вопрос "что такое вообще это ваше состояние". А вопрос "как" — как раз и затронет эту вашу популярную библиотеку на Х, потому что напрямую касается вопросов о масштабировании проекта, о легкости внесения изменений, и об этом всём.
А на уровне "данные должны двигаться вниз, а события вверх" — можно управлять хоть голым реактом, хоть самопиской, хоть еще как. Когда это всё зароется в проблемах масштаба — вот тогда и придёт понимание, что тут кое-что еще нужно.
Как тестировать свой код
<...> почему минимальные значимые тесты рендеринга требуют 10% усилий и дают 90% выгоды.
А они дают? Ни разу не видел в живой природе "минимальных тестов рендеринга", которые легчайше делаются и дают огромный профит. Наоборот, любому не набрасывающему на вентилятор, должно быть понятно, что тесты рендеринга — это всегда крайне непростая штука, ибо по своей природе это интеграционные тесты вашего кода с black box многочисленных браузеров.
А если это какие-либо "приближения", как тот же Jest, который проводит "тесты рендеринга" через генережку DOM — они дают не просто 90% выгоды, а ровно 0%. Т.к. тестируют сферическую хрень в вакууме.
Как релизить свой код
См. "как управлять состоянием". На практике этого тупо недостаточно.
Как писать код, который удобно анализировать
Никак. Можно еще долго ломать копья вокруг этого, но практика от теории не отличается только в теории. На практике — есть такие изменения в коде, которые нельзя "удобно анализировать", и которые невозможно свести к "удобным для анализа" за хоть сколько-нибудь вменяемое количество времени.
А за пределами этого замечания — это то же самое, что и "писать понятный код".
Короче, набросы какие-то, из преимущественно спорных моментов и попытке что-то придумать просто потому, что надо бы придумать. Здравые моменты есть, но нездравых сильно больше. И ах да, а при чем тут реакт? А вот причем:
Мы вели потрясающие беседы с несколькими опытными React-разработчиками. Никто из них не согласился с названием этой статьи, они говорили, что «испортил» — слишком сильное слово.
Советы хорошие, но пять основных проблем, которые указаны в статье, решить очень трудно, практически невозможно. Интернет, как и классические СМИ — это средство влияния на общественное мнение, и как следствие — на политику и экономику государства.
Это очень серьезная власть и именно ради обладания ею, все олигархи и просто богатые люди стремятся обзавестись своими карманными СМИ, чтобы потом использовать их в своих интересах. И цензура — это логичное следствие этого процесса- ни один главный редактор ни одного СМИ не пропустит в печать никаких статей или комментариев в блогах, ничего, где содержалась бы критика против Хозяина.
Основной способ борьбы с цензурой — это научится думать, критически оценивая те потоки дерьма пропаганды, которые льются на нас, в эпоху интернета вещей, буквально из каждого утюга. Это трудно, опасно, но возможно. Без этого никакие прокси не помогут.
«мол, для того, чтобы судить о литературе или преподавании не требуется многолетняя подготовка»
Тут я вижу интересную грань. С одной стороны можно сказать, что литературу как и любое другое искусство чувствуешь «сердцем». Оно либо резонирует, либо нет. И тогда, действительно, никакой специальной подготовки не нужно. С другой стороны, чтобы «вести умные разговоры» и рассуждения на тему освещенную произведением — тут подготовка и образование как раз-таки способствуют.
Не могу не порекомендовать видео с Борисом Прокудиным на канале ПостНаука Философия безделья в романе «Обломов» — когда впоминаешь, что ты вынес из романа в школьные годы и видишь как его можно интерпретировать, становится, честно, завидно.
И ведь именно поэтому люди часто получают разные впечатления от произведения, прочитывая его в разном возрасте. С одной стороны «сердце» с приходом жизненного опыта резонирует на других частотах, а с другой стороны у человека со временем появляются новые знания и контексты. Соответственно, ты рассматриваешь произведение в «бóльшем количестве измерений».
«Судить» можно и нужно в любом возрасте с подготовкой или без. Это часть обучения. Только «ударив» одно суждениe о другое, можно их изменить. А зачем вести беседу, если ваши суждения и взгляды никак после нее не изменятся. У одного заполняются пустоты, у другого откалываются острые углы. И я считаю даже опасным защищать свою точку зрения от внешнего воздействия. Можно проигнорировать много интересного опыта. Но такой уровень восприятия и принятия пришел ко мне только с годами.
P.S.:
«Из-за этого мифа у меня со студентами периодически бывают стычки: некоторые ставят под сомнение отдельные мои преподавательские приёмы или рекомендации, и в их сознании получается, что это моё частное мнение – против их. И не объяснишь ведь в двух словах, что они, мягко говоря, недостаточно компетентны для того, чтобы иметь на этот счёт хоть какое-то мнение»
Была у меня в восьмом классе учительница по английскому. (Прошу прощения, это чистое совпадение) И она у меня спросила, почему в ответе я применил какой-то там временной оборот. На что я ответил, мол, сделал это «на слух». На это она возразила, что это она со своим опытом можеть делать это «на слух», но никак не я. А я просто аудитивно развит и легко схватываю именно «звучание». И когда проговариваю мысленно, то «слышу», звучит оно правильно, т.е. «естественно», или нет.
Это я к тому, что опасно всех записывать в «некомпетентных» только из-за того, что они еще ученики. Да тяжело, да они спорят. Но спорят-то они, не чтобы Вас позлить. Это способ познания. И тут задача преподавателя — понять, откуда берется такое суждение и попытаться изменить его. Но не способом спора, а встав на сторону ученика. Тут я бы порекомендовал послушать богословов. Они очень классно умеют избегая конфликта не терять своей позиции. Их учат этому в семинарии. Но основа такого «умения» у них это глубокие знания философии, психологии, физики, истории и др. Так вот, что это я хожу вокруг да около? Скажу прямо: может это повод, чтобы углубиться в «человекознание»?
P.P.S.:
И вот, я уже думал заканчивать свое мыслеизложение, но тут увидел, что упустил пожалуй самое главное наблюдение. С одной стороны Вы говорите о доверии, а с другой не доверяете своим ученикам. Вы четко прочертили границу компетентности и того, что кому знать положено, а кто профан «по-статусу». Как-то нескладно получается.
У меня бабушка была учителем английского языка (это опять же, чистое совпадение). Так вот, ее ученики любили. И чтобы было понятно насколько — многие писали ей письма несколько лет после окончания школы. Она никогда не теряла веру в учеников, хотя были всякие, вплоть до криминальных. И они писали ей, рассказывали то, о чем следователю не рассказывали. Вот это доверие.
Подход к автоматизации должен зависеть только от типа приложения, но никак не от предприятия. А скитания по Граблестану неизбежны. Приложение живет, развивается, меняется. Автоматизация, всегда бежит позади и адаптируется. Готовые решения есть только под стандартные задачи, а где вы видели стандартные задачи, ведь под них уже есть готовые решения.
Казалось бы, можно заложиться на эту тенденцию к динамике изначально, при выборе архитектуры автоматизации. Но на практике никогда не дают времени хоть сколько нибудь достаточно всмотреться в перспективу и продумать более менее безболезненный путь. Тебя всегда гонят вперед.
Автоматизация для менеджеров состоит только из преимуществ и единственный ее «недостаток» это ее стоимость. Поэтому они считают всякие ROI. У меня от этого слова глаз дергаться начинает, простите.
Я обычно так обьясняю: задача тестирования предоставлять критическую информацию о состоянии продукта. Автоматизация этого процесса, дает соответственно повторяемость, разгрузку человеческого ресурса, бескомпромиссную точность (которая часто для начинающих оборачивается сюрпризом в виде нестабильных тестов). В результате у нас появляется поток информации, который нужно обработать. Разбирать, является ли остановка ошибкой в системе автоматизации или в продукте. Соответственно, роли немного меняются. Теперь тестировщик занимается анализом того, что выдала автоматизация, и уже по результатам анализа заводит репорты.
У нас например в день вываливается столько результатов тестов, по всем билдам, что просмотреть их все физически невозможно. И тут это промах менеджмента заказчика, что им важно количество автотестов. А то, что генерируемую этими тестами информацию невозможно обработать никакими силами, уже никого не волнует. И получается такая ситуация как «горшочек, не вари». И это я молчу про то, сколько бывает тестов, которые пишут лишь бы цифры сходились. Поставь неправильную цель и загубишь все. А происходит все оттого, что заказик сам знает как правильно, и никого ни о чем не спрашивает.
А вот теперь самое интересное, касательно эффективности.
Я считаю есть единственная метрика эффективности автоматизации. Если с ней плотность выявления проблем в продукте увеличилась. — она эффективна, если нет, то она в данном случае неэффективна. Вообще плотность выявления проблем в продукте, единственная метрика для какого бы-то ни было тестирования. Все остальное не имеет прямого отношения к цели тестирования.
Вы скажете что-то в духе: «Но как же, количество багов в продукте к релизу будет меньше!».
Не согласен. Затраты на выявление следующей ошибки будут расти, да. А количество багов нам не известно никогда.
Вспомним известную цитату Э. Дийкстры: «Тестирование может лишь показать наличие ошибок, но не их отстутствие». Не надо питать иллюзий, любая сколь-нибудь сложная программа — черный ящик.
Так вот, автоматизация тестирования в частности может вполне быть неэффективна на продукте который часто претерпевает изменения, или находится на этапе формирования.
На помощь приходит здравый смысл. Если у вас ручное тестирование находится в хаотичном состоянии, например в основном это исследовательское тестирование, к которому часто прибегают на сырых проектах, который еще не оброс документацией и пр., то автоматизировать наверное рано, получится автоматизированых хаос.
А регрессию, т.е. то, что давно и всегда должно работать автоматизировать вполне нужно.
Исходя из этой задачи вы выбираете, что нужно автоматизировать. Логично начать с тех тестов которые, наиболее легки в реализации.
Бонусом ко всему вышесказанному добавлю, что автоматизатор должен разбираться в архитектуре приложения. Это обязательно, чтобы правильно писать тесты, и чтобы писать правильные тесты. Например, при использовании «серых» методов управления программой, это позволит понять, какие слои приложения будет охватывать сценарий. Если я дёрну какую-то внутреннюю функцию в приложении для чего-то там, эквивалентно ли это тому, что будет происходить при использовании вживую. Очень важно четко понимать где твой автотест заходит за черту своей целесообразности.
Я например пишу е2е тесты под эмулятор приложения. И иногда, несмотря на шестилетний опыт, обжигаюсь на том что забываю, что реальный, назовем его — «бекэнд», будет вести себя не так как моки. Т.е. я проверяю работу приложения с моками «бекэнда». Часто моки ведут себя идеальнее «бекэнда». Тут на помощь приходят разработчики и говорят, что тестировать эту функцию на моках нет смысла. Поэтому нужно разбираться в архитектуре и слоях приложения, чтобы не тратить силы на то, на что тратить силы не нужно, а тратить их на то, что действительно полезно.
P.S. У нас сейчас идет пятая инкарнация автотестирования за восемь лет, самая живучая и перспективная пока, но не без проблем конечно. Правда, проект серийный, поэтому заказчик может себе позволить сеять, сжигать и сеять заново.
Идеология скрама произрастает из исследования Нонака и Такеуши (Ikujiro Nonaka, Hirotaka Takeuchi, 1986, "The New Product Development Game"). Они рассмотрели, как успешные компании изменяют подход к разработке новых продуктов. Раньше разработка новых продуктов проходила фазы, продукт передавался по цепочке от одного отдела другому. А подход «рэгби», как они назвали его в работе, стирает эти границы. Собирают команду, и дают им задачу. Например сделать фотокамеру компактной, надежной, простой и на 30% ниже средней рыночной стоимости. (Т.е. дают явно «невозможную» задачу)
Такая команда представляет собой «Task Force». Выкладываясь более чем на 100 %, люди работают в тесном взаимодействии друг с другом. Они притираются друг к другу и работают как одно целое.
Естественно, для такого взаимодействия необходимо, чтобы у людей не было завышенного эго, чтобы не было рангов и титулов. Каждый имеет свою сильную сторону. Каждый умеет что-то лучше других.
В статье говорится,
It may not apply to organizations where product development is masterminded by a genius
who makes the invention and hands down a welldefined set of specifications for people below to follow
что такой подход может быть не пригоден в организациях, где разработкой нового продукта руководит «гений», который рождает на свет идею/изобретение, и спускает вниз четкую инструкцию по ее реализации.
По моему мнению, основанному на моих наблюдениях по внедрению аджайла в нескольких командах, ключ к успеху зависит именно от этого. Насколько люди смогут отказаться от своего эго и посвятить себя общему результату.
Я думаю, что у японцев другой ментатлитет. Они черезвычайно лояльны, и никогда не проявляют своего эго. Поэтому такой подход работает в Японии. (Подумайте о Камикадзе). И успех внедрения зависит именно от того, смогут ли люди сформировать такую команду, которая будет готова на все ради цели.
Не во всех странах можно найти людей с подходящим менталитетом. А также правовые рамки могут не предусматривать такой режим работы, где человек будет самозабвенно отдавать себя всего работе.
В статье говорится,
It requires extraordinary effort on the part of all project memhers throughout the span of the
development process. Sometimes, team members record monthly overtime of 100 hours during the peak and 60 hours during the rest of the project
что недостатком такого подхода являются возможные пиковые перегрузки до ста часов в месяц, и шестьдесят часов в месяц в остальное время.
Теперь, когда мы поняли что такое скрам как идеология, (это не столько методология, сколько в первую очередь идеология), то попробую дать ответ на вопрос, в чем же функция руководства?
Функция руководства — ставить команде цели.
И другой вопрос: за кем в команде последнее слово ?
Вопрос хороший.
В статье говорится,
Second, a different kind of learning is required. Under the traditional approach, a highly competent group of specialists undertakes new product development. An elite group of technical experts does most of the learning. Knowledge is accumulated on an individual basis, within a narrow area of focus-what we call learning in depth.
In contrast, under the new approach (in its extreme form) nonexperts undertake product development. They are encouraged to acquire the necessary knowledge and skills on the job. Unlike the experts, who cannot tolerate mistakes even 1% of the time, the nonexperts are willing to challenge the status quo. But to do so, they must accumulate knowledge from across
all areas of management, across different levels of the organization, functional specializations, and even organizational boundaries. Such learning in breadth serves as the necessary condition for shared division of labor to function effectively
что в команду берут не лучших специалистов, а «не-экспертов», тогда те будут вынуждены учиться и развиваться вширь. А это в свою очередь является необходимым условием для «совместного разделения труда».
В команде, как я описал ее выше, не может быть таких людей которые тянут одеяло на себя. Подразумевается, что все умеют слушать друг друга. И решение принимается командой, т.е. каждый высказал непредвзято свое мнение, его непредвзято выслушали и непредвзято выразили свои мысли. Непредвзято взвесили все за и против, и приняли решение. Если кто-то будет постоянно выпячивать свое эго — такому человеку нечего делать в команде. Вот и все. В современном скраме, есть скрам-мастер, в конце концов, который выступает в качестве модератора, и не даст никому давить других громкостью.
Поэтому подводя итог, скажу, хотите делать аджайл — берите людей в первую очередь с определенным менталитетом, а не с определенным сертификатом. Людей которые будут готовы «лечь на амбразуру». Но условием для этого, и об этом тоже говорится в статье, является то, что руководство будет давать людям свободу действий. Следить за их успехами, но давать свободу действий.
P.S.
От себя еще добавлю совет: хотите внедрять аджайл, читайте статьи не на тему «scrum», а на тему «психология команды»
В целом автор не пишет ничего вредного или неправильного, всё так. Но есть о чем возразить.
Идея о том, что если много и усердно работать и идти к своей мечте то обязательно достигнешь успеха возникает из за когнитивного искажения, называемого «верой в справедливый мир».
В мире, существует множество предопределённых факторов, о которых страшновато признаваться самому себе. И один из них это уровень интеллекта, залженный генетически, подобно стеклянному потолок ограничивающий способности (и возможности) человека.
Так же очень важен фактор счастливой случайности, о котором ох как не любят говорить достигнувшие успешного успеха. Т.к. это снимает с них ответственность за достижение и переносит на внешние факторы, словно наградные медали снимают с шеи.
Еще очень важно социально экономическое положение человека. Какой-то трудяга с семьёй, задолбан кучей забот и не может позволить себе рисковать. Другой же может десять лет спокойно работать, находясь под покровительством родственников или спонсора, совершить множество попыток в разных сферах жизни, зная что его подстрахуют...
Ну и советы типа «Если вы перфекционист, просто перестаньте бояться» довольно бесполезные, т.к. расстройства личности возникают в детстве и за десятилетия жизни влияют на мышление и поведение человека и чтобы это скорректировать нужно работать, переучивать нейросетку в голове к более здоровым шаблонам восприятия и поведения. А это само по себе большой объём работы и немалый срок.
Как-то все это похоже на "Выучи Х и станешь Y". Хотя все знают, что эта формула по сути вранье. Учиться нужно постоянно, и в лучшем случае она должна выглядеть как "Для работы в качестве Y может быть полезным знать X" И тогда оказывается, что полезным может быть все.
Я например в молодости читал Лебедева по дизайну, и могу аргументированно доносить нефункциональные баги в пользовательском интерфейсе до "стейкхолдеров". И это невероятно полезный навык, понимать азы правильного устройства интерфейсов. И что еще важнее как аргументировать убедительно, но не обидно.
Или например, как насчет навыка письма и общения. Я должен сказать, что комментирование на хабре и других платформах здорово прокачало мои коммуникационные навыки за пару лет. Потому что для этого сперва нужно иметь мнение, а потом постараться выразить его так чтобы никому не навредить, даже если это критика. А тестировщик он всегда критик (в хорошем смысле этого слова). Не критикан, а критик. Для этого нужно развивать критическое мышление. Задаваться вопросами. А почему так. Не принимать все на веру. Спрашивать себя "а что если".
А что касается практики - пожалуйста, бесплатная практика:
Берем любую опенсорсную софтину.
Разбираемся в ее устройстве.
Находим в ней ошибки.
Открываем багтрекер проекта.
Регистрируемся.
Пишем багрепорт с учетом гайдлайнов проекта.
Ждем когда баг категоризируют, распределят и начнут над ним работу
Отвечаем на дополнительные вопросы разработчика. Помогаем ему тестировать дополнительные сценарии, чтобы точнее выявить условия проявления нежелательного поведения.
Ждем когда баг починят и тестируем новый релиз
ProfitОпыт.Эти багрепорты публичные и на них можно легко сослаться, нет NDA. Создайте свой репозиторий на гитхабе и храните там ссылки на свои багрепорты. Понадобиться сослаться в резюме - удобно, одной ссылкой. Будет еще и подтверждение минимального опыта работы с Git. Ну и не будем забывать, что работа над опенсорсом у всех в почете.
Домашнее задание:
Найти публичные багтрекеры десяти опенсорсных проектов в интернетax.
Полезное упражнение: воспроизведите чужой баг
Коли вы уже нашли публичные багтрекеры - покопайтесь в них, найдите открытый баг подходящий для воспроизведения в вашем окружении, воспроизведите его. Упражниение полезно в первую очередь для того, чтобы понять недостатки в багрепортах и самому стараться в будущем этих недочетов избегать.
Еще одно упражнение: Возьмите любое известное вам приложение, например на мобильном телефоне. Проследите за тем как именно вы пользуетесь определенной функцией. Опишите эту функцию в виде тестового сценария. Возьмите другое устройство, и проверьте работает ли этот сценарий на нем.
P.S.:
Лайфхак, если не знаешь что можно тестировать в приложении. Я недавно пробовал ChatGPT и попросил его подсказать тестовые сценарии для <тип приложения>. И получил список вполне годных идей.
В случае формального языка — я очень рад выбору английского. Потому что когда я читаю код, то вместо некого подобия Рапиры (
ПРОЦ СТАРТ(); ВЫВОД: "ЗДРАВСТВУЙ, МИР!"; КНЦ;), я вижу нечто марсианско-непонятное (условно говоря,が(); ら"blahblah"; ひ), и я просто выучил, что в начале любой функции стоитが, в концеひ, аら— это "напечатай вон то", при этом не отвлекаясь на смысл. Ну, практически как в старой хохме про называние цвета, которым написаны буквы — а не того, название которого этими буквами написано.Цитирую абзац, из которого взята фраза на скрин-шоте:
Беда в том, что цитируемый менеджер не допускает даже мысли о том, что единой метрики для разных команд нет и быть не может.
У кого-то продукт менее дефектоопасный, у кого-то сезон более простых проектов, а кто-то и вовсе формально работает компании в убыток, прибирая за другими командами или открыв сезон охоты на легаси... да мало ли причин!
CI/CD в данном случае рекомендуется как дженерик, который с одной стороны облекает труд программистов в постижимую для непрограммистов единую форму, а во-вторых, не мешает и даже полезен самим программистам.
NB: я ни разу не автор - но я осмелюсь предположить, что автор имеет в виду что-то такое. Сам сталкивался и вроде бы что-то в этом понимаю... но мало...
Как НТшник не хотелось бы понижать коллегу.
Но в чём смысл поста? Он бы хорошо подошёл для истории внутри компании, но не для Хабра.
Тоесть просто перечисление инструментов которое используется. Имхо если добавить описание каких-то твиков которые могут упростить жизнь, это было бы полезно.
К примеру, в Apache Jmeter, если в View Result Tree во вкладке Response приходят нераспознаваемые ответы (кракозябры), в файл настроек Jmeter.properties в строку:
Заменить (или закомментировать и добавить) строчку:
То ответы будут корректными. Либо сменить вариант с Text на JSON.
Множество спорных суждений, на сколько я вижу, выходят из непонимания блокчейнов. Например, инновация блокчейнов для сфере платежей в децентрализованном консенсусе (первый придумал bitcoin), и DAO который принёс Eth.
Бесспорно, пихать блокчейны везде - плохая идея, и то что сейчас нет инструментов для работы со всем этим для обычных людей (всё для гиков), а что для обычных с красивым сайтом (binance), то совсем не пахнет как инновация. Не стоит забывать что блокчейн - инструмент, просто все ринулись создавать при помощи него новый банк, а деньги привлекают внимание.
Чтоб разобраться рекомендую только https://vas3k.ru/blog/web3/ , остальное будет про спекуляции, что уводит от идей которые приносит блокчейн.
Например тут всё время пытаются натянуть токен то на "доллар" то на предмет искусства, но ближе всего, если очень хочется аналогий из доцифрового мира, это бензин, за объяснениями к умному vas3k в статью о web3.
Мне кажется, что тут важно упомянуть, что один человек может считать высказывание другого ложью не потому, что оно лживое, а просто потому, что каждый из них видит только часть картины.
Притча про слепых и слона
Один раджа приехал в гости к падишаху из соседнего государства.
Он привез множество подарков, и среди них — живого слона. А так как падишах никогда в жизни не видел это животное, гость решил загадать загадку. Заведя слона в темный зал, раджа попросил правителя: «Пусть твои советники опишут слона, который здесь находится. Хочу узнать, насколько они мудры». Первый советник в кромешной тьме наткнулся на ногу животного. «Этот зверь, как громадное дерево», — сказал он. «Слон — это огромная извивающаяся змея», — возразил ему второй мудрец, который нащупал хобот животного. Третьему удалось погладить туловище слона. «О правитель, они оба лгут, — закричал он. — Слон похож на большой лист бумаги — такой же широкий и шершавый». Недоумевающий падишах обратился к радже: «Скажи, каков этот слон?» Когда гость вывел животное из зала, и мудрецы, и правитель сильно удивились. «Каждый из вас был прав по-своему. И все же все вы ошибались, — обратился раджа к советникам. — Ваши знания были неполными, ведь вы познали лишь часть целого. А потому слон оказался совсем не таким, каким вы себе его представляли».
И еще картинка в тему
А если вспомнить, насколько криво мы можем выражать свои мысли, то часто один просто неправильно услышал другого и назвал свое понимание услышанного ложью
Снижать когнитивную нагрузку (это когда задействованы мозги, скроллинг инстаграма, чтение хабра и "развивающих" статей и т.п.). Регулярно делать что-то скучное чтобы мозг имел возможность разгрузиться. Вроде мытья полов, посуды, прополки грядок и т.п. Современный человек лишен такого режима работы мозга, а он нам необходим.
Начать ходить пешком по 2-3 км в день. Лучше поменьше но пролонгированно, т.е. равномерно в течении месяца, а не так что один день 15 км прошел, а потом две недели не ходил. Важно при этом не грузить мозги прослушиванием музыки, подкастов и т.п.
Отслеживать и останавливать руминацию (зацикленные мысли в голове) делается довольно просто, нужно додумать эти "зависшие" мысли до какого-то вывода. И если руминация возникла, вспоминаете вывод и переключаете внимание на что-то другое волевым усилием.
Спать по 8 часов, выработав привычку оставлять вечером смартфон на кухне, а не залипать в светящийся экран перед сном.
Это самое простое и лишь по верхам. Ну и да, подгонять кофем удушенный хроническим стрессом и нагрузкой мозг это как давить в пол педаль газа на разваливающемся жигуле едущем по дороге с ухабами, лишь усугублять ситуацию.
Еще могу посоветовать отказаться от алкоголя, если употребляете. Но все эти советы лишь симптоматические, если у вас психологические проблемы, тревожное состояние и связанная с этим прокрастинация, то нужно разбираться целенаправленно. И со специалистом.
Если кто-то отвечает на вопрос о том, как писать простой и читаемый код через "прост возьмите готовое" — он профнепригоден, только и всего.
Если и объяснения будут даны, они не отвечают на вопрос "как управлять состоянием". Они отвечают на вопрос "что такое вообще это ваше состояние". А вопрос "как" — как раз и затронет эту вашу популярную библиотеку на Х, потому что напрямую касается вопросов о масштабировании проекта, о легкости внесения изменений, и об этом всём.
А на уровне "данные должны двигаться вниз, а события вверх" — можно управлять хоть голым реактом, хоть самопиской, хоть еще как. Когда это всё зароется в проблемах масштаба — вот тогда и придёт понимание, что тут кое-что еще нужно.
А они дают? Ни разу не видел в живой природе "минимальных тестов рендеринга", которые легчайше делаются и дают огромный профит. Наоборот, любому не набрасывающему на вентилятор, должно быть понятно, что тесты рендеринга — это всегда крайне непростая штука, ибо по своей природе это интеграционные тесты вашего кода с black box многочисленных браузеров.
А если это какие-либо "приближения", как тот же Jest, который проводит "тесты рендеринга" через генережку DOM — они дают не просто 90% выгоды, а ровно 0%. Т.к. тестируют сферическую хрень в вакууме.
См. "как управлять состоянием". На практике этого тупо недостаточно.
Никак. Можно еще долго ломать копья вокруг этого, но практика от теории не отличается только в теории. На практике — есть такие изменения в коде, которые нельзя "удобно анализировать", и которые невозможно свести к "удобным для анализа" за хоть сколько-нибудь вменяемое количество времени.
А за пределами этого замечания — это то же самое, что и "писать понятный код".
Короче, набросы какие-то, из преимущественно спорных моментов и попытке что-то придумать просто потому, что надо бы придумать. Здравые моменты есть, но нездравых сильно больше. И ах да, а при чем тут реакт? А вот причем:
"Просто нам хотелось погромче набросить" (с).
Это очень серьезная власть и именно ради обладания ею, все олигархи и просто богатые люди стремятся обзавестись своими карманными СМИ, чтобы потом использовать их в своих интересах. И цензура — это логичное следствие этого процесса- ни один главный редактор ни одного СМИ не пропустит в печать никаких статей или комментариев в блогах, ничего, где содержалась бы критика против Хозяина.
Основной способ борьбы с цензурой — это научится думать, критически оценивая те потоки
дерьмапропаганды, которые льются на нас, в эпоху интернета вещей, буквально из каждого утюга. Это трудно, опасно, но возможно. Без этого никакие прокси не помогут.Тут нам просто повезло, что нашелся заинтересованый человек, который стал копаться.
Не могу не порекомендовать видео с Борисом Прокудиным на канале ПостНаука Философия безделья в романе «Обломов» — когда впоминаешь, что ты вынес из романа в школьные годы и видишь как его можно интерпретировать, становится, честно, завидно.
И ведь именно поэтому люди часто получают разные впечатления от произведения, прочитывая его в разном возрасте. С одной стороны «сердце» с приходом жизненного опыта резонирует на других частотах, а с другой стороны у человека со временем появляются новые знания и контексты. Соответственно, ты рассматриваешь произведение в «бóльшем количестве измерений».
«Судить» можно и нужно в любом возрасте с подготовкой или без. Это часть обучения. Только «ударив» одно суждениe о другое, можно их изменить. А зачем вести беседу, если ваши суждения и взгляды никак после нее не изменятся. У одного заполняются пустоты, у другого откалываются острые углы. И я считаю даже опасным защищать свою точку зрения от внешнего воздействия. Можно проигнорировать много интересного опыта. Но такой уровень восприятия и принятия пришел ко мне только с годами.
P.S.:
Была у меня в восьмом классе учительница по английскому. (Прошу прощения, это чистое совпадение) И она у меня спросила, почему в ответе я применил какой-то там временной оборот. На что я ответил, мол, сделал это «на слух». На это она возразила, что это она со своим опытом можеть делать это «на слух», но никак не я. А я просто аудитивно развит и легко схватываю именно «звучание». И когда проговариваю мысленно, то «слышу», звучит оно правильно, т.е. «естественно», или нет.
Это я к тому, что опасно всех записывать в «некомпетентных» только из-за того, что они еще ученики. Да тяжело, да они спорят. Но спорят-то они, не чтобы Вас позлить. Это способ познания. И тут задача преподавателя — понять, откуда берется такое суждение и попытаться изменить его. Но не способом спора, а встав на сторону ученика. Тут я бы порекомендовал послушать богословов. Они очень классно умеют избегая конфликта не терять своей позиции. Их учат этому в семинарии. Но основа такого «умения» у них это глубокие знания философии, психологии, физики, истории и др. Так вот, что это я хожу вокруг да около? Скажу прямо: может это повод, чтобы углубиться в «человекознание»?
P.P.S.:
И вот, я уже думал заканчивать свое мыслеизложение, но тут увидел, что упустил пожалуй самое главное наблюдение. С одной стороны Вы говорите о доверии, а с другой не доверяете своим ученикам. Вы четко прочертили границу компетентности и того, что кому знать положено, а кто профан «по-статусу». Как-то нескладно получается.
У меня бабушка была учителем английского языка (это опять же, чистое совпадение). Так вот, ее ученики любили. И чтобы было понятно насколько — многие писали ей письма несколько лет после окончания школы. Она никогда не теряла веру в учеников, хотя были всякие, вплоть до криминальных. И они писали ей, рассказывали то, о чем следователю не рассказывали. Вот это доверие.
Казалось бы, можно заложиться на эту тенденцию к динамике изначально, при выборе архитектуры автоматизации. Но на практике никогда не дают времени хоть сколько нибудь достаточно всмотреться в перспективу и продумать более менее безболезненный путь. Тебя всегда гонят вперед.
Автоматизация для менеджеров состоит только из преимуществ и единственный ее «недостаток» это ее стоимость. Поэтому они считают всякие ROI. У меня от этого слова глаз дергаться начинает, простите.
Я обычно так обьясняю: задача тестирования предоставлять критическую информацию о состоянии продукта. Автоматизация этого процесса, дает соответственно повторяемость, разгрузку человеческого ресурса, бескомпромиссную точность (которая часто для начинающих оборачивается сюрпризом в виде нестабильных тестов). В результате у нас появляется поток информации, который нужно обработать. Разбирать, является ли остановка ошибкой в системе автоматизации или в продукте. Соответственно, роли немного меняются. Теперь тестировщик занимается анализом того, что выдала автоматизация, и уже по результатам анализа заводит репорты.
У нас например в день вываливается столько результатов тестов, по всем билдам, что просмотреть их все физически невозможно. И тут это промах менеджмента заказчика, что им важно количество автотестов. А то, что генерируемую этими тестами информацию невозможно обработать никакими силами, уже никого не волнует. И получается такая ситуация как «горшочек, не вари». И это я молчу про то, сколько бывает тестов, которые пишут лишь бы цифры сходились. Поставь неправильную цель и загубишь все. А происходит все оттого, что заказик сам знает как правильно, и никого ни о чем не спрашивает.
А вот теперь самое интересное, касательно эффективности.
Я считаю есть единственная метрика эффективности автоматизации. Если с ней плотность выявления проблем в продукте увеличилась. — она эффективна, если нет, то она в данном случае неэффективна. Вообще плотность выявления проблем в продукте, единственная метрика для какого бы-то ни было тестирования. Все остальное не имеет прямого отношения к цели тестирования.
Вы скажете что-то в духе: «Но как же, количество багов в продукте к релизу будет меньше!».
Не согласен. Затраты на выявление следующей ошибки будут расти, да. А количество багов нам не известно никогда.
Вспомним известную цитату Э. Дийкстры: «Тестирование может лишь показать наличие ошибок, но не их отстутствие». Не надо питать иллюзий, любая сколь-нибудь сложная программа — черный ящик.
Так вот, автоматизация тестирования в частности может вполне быть неэффективна на продукте который часто претерпевает изменения, или находится на этапе формирования.
На помощь приходит здравый смысл. Если у вас ручное тестирование находится в хаотичном состоянии, например в основном это исследовательское тестирование, к которому часто прибегают на сырых проектах, который еще не оброс документацией и пр., то автоматизировать наверное рано, получится автоматизированых хаос.
А регрессию, т.е. то, что давно и всегда должно работать автоматизировать вполне нужно.
Исходя из этой задачи вы выбираете, что нужно автоматизировать. Логично начать с тех тестов которые, наиболее легки в реализации.
Бонусом ко всему вышесказанному добавлю, что автоматизатор должен разбираться в архитектуре приложения. Это обязательно, чтобы правильно писать тесты, и чтобы писать правильные тесты. Например, при использовании «серых» методов управления программой, это позволит понять, какие слои приложения будет охватывать сценарий. Если я дёрну какую-то внутреннюю функцию в приложении для чего-то там, эквивалентно ли это тому, что будет происходить при использовании вживую. Очень важно четко понимать где твой автотест заходит за черту своей целесообразности.
Я например пишу е2е тесты под эмулятор приложения. И иногда, несмотря на шестилетний опыт, обжигаюсь на том что забываю, что реальный, назовем его — «бекэнд», будет вести себя не так как моки. Т.е. я проверяю работу приложения с моками «бекэнда». Часто моки ведут себя идеальнее «бекэнда». Тут на помощь приходят разработчики и говорят, что тестировать эту функцию на моках нет смысла. Поэтому нужно разбираться в архитектуре и слоях приложения, чтобы не тратить силы на то, на что тратить силы не нужно, а тратить их на то, что действительно полезно.
P.S. У нас сейчас идет пятая инкарнация автотестирования за восемь лет, самая живучая и перспективная пока, но не без проблем конечно. Правда, проект серийный, поэтому заказчик может себе позволить сеять, сжигать и сеять заново.
Такая команда представляет собой «Task Force». Выкладываясь более чем на 100 %, люди работают в тесном взаимодействии друг с другом. Они притираются друг к другу и работают как одно целое.
Естественно, для такого взаимодействия необходимо, чтобы у людей не было завышенного эго, чтобы не было рангов и титулов. Каждый имеет свою сильную сторону. Каждый умеет что-то лучше других.
who makes the invention and hands down a welldefined set of specifications for people below to follow
По моему мнению, основанному на моих наблюдениях по внедрению аджайла в нескольких командах, ключ к успеху зависит именно от этого. Насколько люди смогут отказаться от своего эго и посвятить себя общему результату.
Я думаю, что у японцев другой ментатлитет. Они черезвычайно лояльны, и никогда не проявляют своего эго. Поэтому такой подход работает в Японии. (Подумайте о Камикадзе). И успех внедрения зависит именно от того, смогут ли люди сформировать такую команду, которая будет готова на все ради цели.
Не во всех странах можно найти людей с подходящим менталитетом. А также правовые рамки могут не предусматривать такой режим работы, где человек будет самозабвенно отдавать себя всего работе.
development process. Sometimes, team members record monthly overtime of 100 hours during the peak and 60 hours during the rest of the project
Теперь, когда мы поняли что такое скрам как идеология, (это не столько методология, сколько в первую очередь идеология), то попробую дать ответ на вопрос, в чем же функция руководства?
Функция руководства — ставить команде цели.
И другой вопрос: за кем в команде последнее слово ?
Вопрос хороший.
В команде, как я описал ее выше, не может быть таких людей которые тянут одеяло на себя. Подразумевается, что все умеют слушать друг друга. И решение принимается командой, т.е. каждый высказал непредвзято свое мнение, его непредвзято выслушали и непредвзято выразили свои мысли. Непредвзято взвесили все за и против, и приняли решение. Если кто-то будет постоянно выпячивать свое эго — такому человеку нечего делать в команде. Вот и все. В современном скраме, есть скрам-мастер, в конце концов, который выступает в качестве модератора, и не даст никому давить других громкостью.
Поэтому подводя итог, скажу, хотите делать аджайл — берите людей в первую очередь с определенным менталитетом, а не с определенным сертификатом. Людей которые будут готовы «лечь на амбразуру». Но условием для этого, и об этом тоже говорится в статье, является то, что руководство будет давать людям свободу действий. Следить за их успехами, но давать свободу действий.
P.S.
От себя еще добавлю совет: хотите внедрять аджайл, читайте статьи не на тему «scrum», а на тему «психология команды»