В IT чудес не бывает

"Разрабатываем без нянек" (с) или как минимизировать участие тестировщиков в вашей работе

ЗЫ умел я раньше в почти лонгриды. Там, при желании, можно найти ответ на вопрос, смогут ли разработчики тестировать.

#классика #testing

Да будет срачик.

Вот интересно.
Какое соотношение проблем продукта от незнания каких-то алгоритмов или там паттернов системного дизайна к проблемам "мы все знаем, но просто не подумали в момент реализации", "не написали тестов/не до конца проверили фичу", "не предусмотрели такой вариант использования", "у нас не было времени" (это мое любимое) и тдтп.

Ну то есть пока, за все время (долгое, очень долгое время), я о-о-очень редко сталкивался с проблемами того, что применили не тот алгоритм (хотя вот буквально недавно было что-то похожее).

Зато проблем от того, что просто бездумно (так кажется) фигачим все, что только можно, в базу и так же все пачкой запрашиваем из базы, от того, что куски ранее работающей функциональности в какой-то момент времени перестают вызываться (рефакторинг, ептеть), запросы в базу/в бек не профилируются и тому подобных приколов - громадье.

Или "мы не продумали архитектуру". Да не можете вы продумать архитектуру навека, у вас требования к продукту меняются каждые полгода. Все что можно и нужно попытаться "продумать" - это то, как быстро менять реализацию. А быстро - это только с тестами получится, но на них часто забивают (времени много ведь занимают)...

Я тешу себя надеждой, если делать все, как учат в паттернах системного дизайна, то менять тоже можно будет быстро. Но в реальности такого чуда ни разу не встречал.
Было ли с кем-то такое чудо?

#holywar

“Тестирование никогда не покажет того, что ошибок нет. Только то, что они есть.”

В чем прелесть цитат в интернете, что фиг найдешь оригинал, особенно если что-то похожее говорят (или повторяют друг за другом) известные люди.

Поэтому тут без ссылки на автора, вдруг потом мне припишут 🫠
#мысли_вслух #testing

Когда ты подготовил письмо о релизе, и тут приходят очередные результаты секьюрити сканов со свежими базами уязвимостей...

#it_memes

А как же эту архитектуру ПО лучше описывать?

The Ultimate Guide To Software Architecture Documentation
• Why should we document software architecture?
• How should we structure software architecture documentation?
• How should we visualize software architecture?
• How do we write and manage software architecture documentation?

Еще полезного из прошлых постов:
• Про полезные практики фиксации принятых решений по реализации фичей.
• Как принимать архитектурные решения?

#tech_read

А что такое архитектура ПО на самом деле?

"Software architecture is about the significant design decisions, where significance is measured by cost of change"

Simon Brown "Software Architecture for Developers"

Очень откликается это определение. Весь вопрос в том, как это все описано.

#tech_read

Что общего у морского огурца и архитектуры ПО?

Морской огурец, к примеру, может дышать через жопу. Эволюционно так сложилось. И многие программы по внутреннему устройству легко затыкают его за пояс — череда меняющихся требований приводит к появлению забавных и жутковатых внутренних механизмов, оказывающих не самое лучшее влияние на развитие продукта.

Григорий Петров: "Изменяющиеся требования — проклятье индустрии"

#tech_read

Примеры неправильного использования DORA-метрик:

1. Фокус на DORA-метриках вместо бизнес-показателей компании/продукта
2. Сравнение метрик 2х команд между собой, вместо того, чтобы отслеживать их изменения для одной команды
3. Неверное толкование и понимание метрик.
4.Фокус на количественных значениях метрик в ущерб удовлетворенности инженеров
5. Культурное несоответствие между тем, что и как декларируется и что на самом деле применяется в процессах

И есть у меня ощущение, что это можно отнести ко многим метриками и процессам их запуска...
#metrics

Забавное из наблюдений: компании накручивают ожидания по опыту кандидата - кандидаты в ответ накручивают опыт - компании начинают еще больше задирать ожидания.
А все из-за того, что все так и не научились оценивать реальные, а не календарные знания.
Это трындец и сюр какой-то :)

При этом историю "кто ищет волшебника - найдет сказочника" никто ведь не отменял.

И все топчутся вокруг магической цифры 3 в качестве первичного фильтра для резюме на входе.
Как будто именно после 3 лет работы раскрываются неведомые чакры и приходит дзен.
При этом абсолютно точно, что 3 года в одной компании, 1+1+1 в разных - это ведь разный опыт. При чем оба варианта имеют свои плюсы/минусы и особенности.

Опять же, чем 2 года опыта хуже 3-х?

Продолжаем наблюдения...

#мысли_вслух #собеседования

Знаете, то самое чувство, когда хочется такое же сесть и написать, но... всегда есть какое-то "но" (а потом еще и пруфы будут спрашивать 😂, хотя оно понятно почему)

А там всю статью можно дергать на цитаты...
Все про мои "любимые" разделение и специализацию.
PS которые конечно важны, но всегда есть "но", контекст и нюансы.

#it_философия

Если для того, чтобы понять, почему ваши юнит-тесты фейлятся, приходится дебажить код, то вы написали не юнит-тесты.

Если для определения причины фейла автотеста приходится его перезапускать - вы написали хреновый код и, возможно, хреновые тесты.
Настраивайте логи, учитесь их использовать. В продакшене возможность повторить действие вызвавшее ошибку - редкость.

Лайфхак: пишите тестами в логи приложения (хотя бы старт-стоп теста) - офигенно удобно потом разбирать результаты.

Вообще, то, насколько быстро вы можете определить причину фейла, показывает насколько хорошие тесты и код вы написали, а также то, насколько правильно выбрали уровень “пирамидки” автотестов для проверки этой фичи.
#test_automation

Зарисовка "Разбирая автотесты"
Тот момент, когда то, что должно быть #it_memes, стало регулярной "работой" с утра...
Начиная с какого момента "разбор результатов автотестов" становится именно разбором, а не просто очередным перезапуском упавших (чтобы они стали зелеными) ?
У кого как?
#test_automation

Observability 1.0 is about MTTR, MTTD, reliability, errors...how you operate your app and fix issues.
Observability 2.0 is about how you develop your app.
Which means you need to understand things like how your code works and how people use it -- and not just when it breaks.

Charity Majors 🔥

#observability

Регламенты пишут, чтобы понимать: кого наказать, когда наказать и как сильно...
#мысли_вслух

По мотивам конференций на этой неделе.
Всегда думайте про то, что вам рассказывают. Конечно вам не врут. Просто могут недоговаривать... ;)
Поэтому, кулуары - наше все.
А уж спикерская... Эмм-м-м, кладезь реальных историй...
#it_memes #байки

Я тут подумал и грех будет не выложить эту простыню, может кому поможет.
Если ты помнишь, я всегда увлекался психологией и прочей херней про работу мозга.
Так вот выложу несколько вводных которые стоит обдумать:
1) Если ты (абстрактный ты) считаешь что у тебя синдром самозванца, то парадокс, ты уже считаешь себя достойным профессионалом(тут подвох что "считаешь"). Мы же не приписываем синдром самозванца новичкам и профанам?
2) Синдром самозванца это объяснительная модель. Ты, а точнее твой мозг чего-то хочет, но хочется и колется, и вот он объясняет себе "Ну у меня же синдром самозванца, куда уж там, куда с таким синдромом сунуться-то, остается только погрустить что я такой и пожалеть себя". Причем эта жалость может крыться вполне себе за смелостью со стороны.
3) Зачем тебе синдром самозванца? В смысле у тебя синдром самозванца, ну и чо? Дай мне конкретики! Не можешь претендовать на зарплату соответствующую твоим навыкам? Я сказал конкретики! Не можешь попросить повышение зарплаты, потому что(ага, видишь объяснение еще одно) считаешь что не достаточно хорош? Ну а если недостаточно хорош, чего тогда хочешь? Или все таки считаешь что достаточно хорош? Боюсь пойти и озвучить свои требования - вот это хорошо.
Найти зачем тебе этот синдром и что ты им прикрываешь тоже хороший путь избавиться от него.
4) Ну и последнее. Ок, у тебя синдром самозванца и тебе это не нравится. А делаешь ты что, чтобы поменять ситуацию? А как должно быть? Часто в статьях о синдроме самозванца я вижу(читая комментарии), что люди ищут 1. Панацею - прочитаю статью и я уверенный в себе красавчик, специалист и меня все хотят. 2. Оправдание что ситуацию не поменять у меня лапки, так умные люди пишут. Тут же как с тренажерным залом, после первой тренировки у тебя не вырастут мышцы и жир не сойдет, это работа над собой. Вот хотя бы просто берешь и записываешь свои достижения, глядишь на них, любуешься раз в неделю и понемногу начинаешь свыкаться с мыслью что "идите вы на хер, сами вы самозванцы, а я на своем месте".
У меня например каждый квартал и каждый год подведение результатов и достижений - а чего сделал, а какую пользу можно извлечь итд итп.

Хорошая напоминалка самому себе...

"Синдром самозванца - прекрасный маркер, что вы развиваетесь. Как только кажется, что это все не вы, или это все удача - 100% что-то сделали. Точно чем-то отличаетесь. Гарантировано не как все. Я не знаю способа, чтобы победить, вылечить этот синдром. Но я знаю, как его поставить на место. Надо просто помнить, что оценка "3" звучит как "удовлетворительно". А что может быть лучше удовлетворения тебя и окружающих? В конечном счете только это и имеет смысл." Дмитрий Волошин (ссылка на старый его пост в FB)
#развитие

Measuring Developer Productivity via Humans
про то, чем качественные метрики в разработке отличаются от количественных и как их получать.

#metrics

Про продуктивность, попытки ее измерить, кооперацию и соревнования между сотрудниками. И про то, что усиливает синергию от взаимодействия.

“Если люди не взаимодействуют и не кооперируют - не вините людей. Посмотрите на процессы: если индивидуальные метрики людей падают, когда они кооперируются, то зачем им кооперироваться…
...
Важно создавать процессы и организации, в которых взаимодействие будет выгоднее”
Прикольный ролик, кстати, может казаться единорожным, но тут смотря с какой целью смотреть.

#management #metrics

Сегодня буду на Heisenbug-е.
Если у кого-то аналогичные планы, то можно пересечься для автограф-сессии, себяшек и обнимашек, ответов на вопросы и общения вживую :)
Пишите в комментах или личку.
Буду помогать ребятам на этом докладе.
https://heisenbug.ru/talks/d8a8602a19fd452dae38204b3762256a/?referer=/schedule/days/