#qa
Котаны, за свою карьеру приходилось работать в разных командах и кампаниях, но закономерность всегда следующая: без нормально построенного тестирования продукт рано или поздно загибается, стагнирует и выдавливается с рынка конкурентами. Сразу скажу, я не QA-инженер, и дальше могут быть неточности, но в целом соображения такие:
1. Есть такая штука: уровень зрелости кампании. Если вкратце, то идея такая: сначала кампания -- это стартап, для которого важно набрать аудиторию и выйти на максимально большой рынок. Это стадия роста. Дальше идут стадии связанные с осмыслением процесса, уменьшением churn'а(оттока недовольных клиентов), повышения качества оказания услуг и т.д. Так вот, с каждым из этих уровней связан определенный "допустимый уровень качества". Это QAшное понятие, которое определяет с каким кол-вом дефектов какой важности можно ехать на прод(что-то вроде модного нынче error budget'а).Смысл в том, что чем выше уровень кампании, тем, выше допустимый уровень качества(спасибо кэп). И вот тут вылезает 1я важная компетенция QA -- эти крутые парни и супер-девчонки умеют правильно выставлять приоритеты дефектам(по четким, на секундочку, критериям, а не от балды) и следят за тем что бы качество продукта не пробило дно.
2. Вангую, что каждый разработчик писал тесты. Не важно, интеграционные/юнит/еще какие-то, важно то, что рано или поздно в покрытом тестами функционале все равно находился баг. Причем вылезал в самом странном месте и на входных условиях, которых никто никогда и предположить не мог. Коллеги придумали кучу способов это забороть типа ScalaCheck и т.д., но реально работает только штука придуманная тестировщиками, а именно тест-дизайн. Вдаваться в подробности тут не буду, но это сложная наука, которая учит как писать тест-кейсы так, что бы описанная выше ситуация не происходила. Кароч QA-инженер с молоком матери впитывает умения писать тест кейсы таким образом, что бы будучи протестированным, функционал реально работал согласно ожиданиям
3. QA -- тестируют функционал на корректность и соответствие заявленным требованиям(спасибо, кэп[2]), по этому они лучше всех знают как ДОЛЖЕН работать продукт. Дело в том, что в отсутствии аналитиков и солюшн архитекторов тестировщики -- единственные люди обладающие в должной мере знаниями о продукте и тех. компетенциями что бы адекватно провалидировать требования и высказать при случае свое "фи" продуктологам и/или указать на противоречия в консернах
4. Тесткейсы -- это реально наиболее близкая к боевым условиям спецификация продукта. Что говорить, тесткейсы на Cucumber(нотации Given-When-Then) многие используют как реальную исполняемую спецификацию проекта. И если у вас на проекте вдруг(хе-хе) нет документации, то можно смело просить тест-кейсы и разбираться по ним.

Кароч, котаны, любите и берегите своих тестировщиков. Помогайте им чем можете. И если на Вашем новом проекте нет тестирования, не описаны тесткейсы и ваще "да че тут тестировать, сами как нибудь...", то может не надо в такое влазить?)

#code (from Clean code by Robert C. Martin)

Чет ору: https://m.habr.com/ru/post/456558/ Кто еще не заклеил камеру бумажкой: все, пора)

В тему предыдущего поста:

Долго тут вынашивал одну мысль, которой в итоге решил поделиться:
Каждый руководитель в определенный час Ч слышит от инженера что-то типа "ну это не поддерживается в текущей архитектуре, надо это переделать, то перенастроить, тут хранилище жопой сделано и ваще все не по феншую. На все про все надо каких-то пол-года и будет прям конфетка." Дальше обычно идет басня про НФТ а-ля нагрузки держать будем и изменения вноситься будут сами и ваще TTM упадет до 1 дня. На вопросы можно ли это имплементить итеративно и/или распараллелить между несколькими инженерами обычно ответ отрицательный.
Так вот, это не так! Все что разрабатывается дольше того самого человекомесяца отлично бьется отдельные стори. Как минимум на MVP и на все остальное(что уже не маловажно, т.к. позволяет оценить продуктовую ценность, проверить идею и т.д. и т.п.). Более того, все что оценено больше чем в человекомесяц отлично параллелится(только не за неделю до релиза, а сразу). Если не параллелится(вот совсем никак), то тут уже должны возникнуть вопросы к реализуемому дизайну и архитектуре.
Почему же инженер так поступает? Нет, он вам не враг и тоже хочет сделать хороший продукт. Дело в том, что у вас с ним совсем разные консерны. Вы хотите получить больше денег, удержать продукт на плаву, занять рвнок и т.д., а вот он хочет совсем другого: он хочет вносить меньше регрессии, хочет не просыпаться по ночам от звонков pagerduty и, конечно, хочет рассказать за кружечкой что его бенчмарки показали результат в 100500rps. И, конечно же, он хочет быть уверен, что все это будет сделано именно так как он этого хочет, потому что он знает и умеет, а вот остальные -- не факт! И для этого ему надо войти в пресловутое состояние потока и не отвлекаться на другие задачи, тем более, что так будет быстрее и эффективнее.
Мораль сей басни такова: 1. товарищи продуктологи, взаимодействуйте с IT как можно чаще! Доносите до них важность и ценность своей работы. Максимально обосновывайте свои консерны и обозначайте цели, стоящие перед вами как перед командой и кампанией. IT -- это не просто инструмент, это люди, со своим мнением, целями и видением. И очень важно, что бы это видение было консистентным
2. Товарищи инженеры, будет очень здорово, если вы постараетесь влезть в шкуру тех самых аналитиков/менеджеров/CTO, которые ставят вам задачи(тем более, что сейчас очередной виток моды на T-shaped😜)

📘 И продолжая тему подписок. Чуть больше месяца назад, Red Hat на своём сайте запустили раздел "Enable SysAdmin" - блог для сисадминов с различными статьями разной степени полезности.

Бывалым админам часть материалов там будет и так знакома, а вот тем, кто приходит к тем же devops практикам из разработки (без админской базы), обратить внимание на эти публикации будет полезно.

#линк #напочитать

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

#books
Кстати про кафку: в книжке Гвен Шапиры для юных кафковедов на первых же 50 страницах описаны юз-кейсы и проблема Linkedin, для решения которой кафку, собственно, и придумали...но кого это останавливает, правда?

​​HashiCode: Terraform remote state backend locking

Awesome article from Daniel Mangum which started a blog post series that his called "HashiCode" where he do deep dives into the source code for HashiCorp tools!

First episode covers everything from .tfstate files to Go polymorphism patterns, all in search of how Terraform handles locking with the S3 remote state backend.
Also, these posts will be a great place to get started if you want to get involved in contributing in the open source community.

#terraform

Как написать самый хреновый софт, который только видел мир. Часть 1
В свое время Хоар назвал изобретение null pointer "ошибкой на миллиард долларов". Может быть и так, но чаще всего NPE -- это просто последствия кривых рук и политики "оттягивания конца". Каждый слышал про fail early, но, почему-то, в боевом коде все предпочитают тянуть до последнего, откладывая или вообще исключая проверку предусловий(описаных тем же самым Хоаром). В результате получается хрупкий код, кидающий NPE отовсюду. Гораздо хуже, если в результате отсутствия проверки предусловий нарушается консистентность данных: допустим, нам надо сохранить профиль пользователя. Профиль состоит из инфы, улетающей в базу, и аватарки, хранящейся в S3. И вот наш замечательный код, естественно без предусловий, сохраняет инфу в базу, а аватарку пользователь не выбрал. И при сохранении в сторадж у нас летит NPE. Хорошо, если мы умышленно сделали аватарку опциональной, но что если нет? В этом случае у нас будет наполовину сохраненный пользователь. И решать такие проблемы придется руками.
Да, пример надуманный, но ситуация страшная. Программирование по контракту и валидация контрактов классов -- единственное что может спасти код от хаоса(если, конечно, вы не любите просыпаться от PagerDuty по ночам)

#eda
Тут интервью с Udi Dahan'ом(евангелистом CQRS и т.д. и т.п) подъехало: https://www.infoq.com/articles/cloud-transactions-dahan Много всего про messaging, consistency и транзакционность.
Кстати у дядьки крутой блог, стоящий того что бы его упомянули хотя бы из-за http://udidahan.com/2011/04/22/when-to-avoid-cqrs/

Chernobyl DevOps: Software Engineering, Disaster Management, and Observability -- статья о том, что DevOps культура может вынести из Чернобыльской трагедии.

+ обсуждение на Reddit. Не конкретно этой статьи, но скорее впечатлений systems engineers от просмотра сериала от HBO

#culture #devops

Статья от Фланта про гитОпс: https://habr.com/ru/company/flant/blog/456754/ как всегда подробно и с личным опытом)

Что мы в Авито знаем о микросервисах?
Рассказывает Вадим Мадисон, руководитель разработки System Platform → http://bit.ly/2ZDqiLS

Пост будет полезен тем, кто ориентирован на создание большой микросервисной архитектуры и тем, кто уже столкнулся с проблемами быстрого роста. Заходите в комментарии поговорить о растущих объемах, сложности и рисках микросервисной архитектуры.

Ж -- жаваскрипт)) https://link.medium.com/s1hNUvEdJX

#shitcode
Как написать самый хреновый софт, который только видел мир. Часть 2
Из всех мейнстримовых принципов проектирования, мейнстримового SOLID'а, всяких DRYев и прочих GRASP'ов, я наиболее нежные чувства питаю к KISS(keep it simple, stupid) или, по-русски, принципу наименьшего удивления. Как-то коллега сказал: "пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте", но, тема в том, что все эти изменения входных параметров по ссылке(ну ее кортеж же возвращать?!), передача нескольких значений как разделенных запятыми строк, название переменных в стиле item1, item2 и т.д. заставляют глаза даже психически здорового человека наливаться кровью.
Более того, этот код не сможет опознать даже сам автор через пару недель.
Хз что мотивирует писать такое, но лечится это даже не ударом книжки Макконела по голове, а соблюдением четырех основных правил(два из которых можно забить в линтер):
1. Иммутабельность -- тут все просто. Надо стараться, по возможности, оперировать неизменяемыми объектами и переменными(это касается как кода, так и API, если что! Безумно бесят GET-запросы, которые insert'ы в базу делают)
2. Чистота -- результат функции должен быть детерменирован(т.е. при передаче одних и тех же параметров мы гарантировано получим один и тот же результат). Если это не возможно, то это должно быть понятно из названия функции/метода. Это правило лежит в основе CQS Бертрана Меера.
3. Адекватный нейминг. Тут все ясно, но на всякий случай: из названия должно быть понятно что лежит в переменной, из названия должно быть понятно что делает функция
4. Закон Деметры. Спорная штука, но ИМХО, очень сильно улучшающая читаемость кода, если применять без фанатизма

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

Котаны, если кто не в курсе, то вчера по всем восточным европам моргал интернет. Причина -- BGP оптимизации, которые просочились "наружу". Естественно, проблема затронула всех провайдеров облачных сервисов, в том числе и CloudFlare.
Меня в данной ситуации удивляет не столько масштаб бедствия(с каждым бывает), сколько поток токсичности со стороны сообщества в сторону Cloudflare. Говно случается! Пару месяцев назад Яндекс.Облако потеряло клиентские виртуалки. За несколько дней до этого Azure уронило DNS. Про фиаско GitLab с Postgres до сих пор все вспоминают. Цимес в том, что аварии неизбежны и все что можно сделать пост-фактум -- это максимально быстро восстановиться и, конечно же, научиться на своих ошибках.
P.S. блейма от Cloudflare в сторону Verizon я тоже не понимаю
P.P.S. вот статья-постмортем от cloudflare про причины аварии: https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today/