💴 PCI DSS в Додо
Недавно послушал на нашем девфоруме сказ от восхитительного Матвея Григорьева о том, как Додо прошло PCI DSS сертификацию.

Это такая штука, которая нужна всем, кто принимает больше 6 миллионов платежей по карте в год. Додо принимает сильно больше — примерно 40 миллионов платежей в год.

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

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

Два основных вывода, которые я сделал для себя из этого доклада:
1️⃣ Облака — это топчик. Всем надо быть в облаках. Если кто-то сомневался, то сомневаться не нужно. Ибо львиная доля сертификации прошла тупо потому, что облачный провайдер сам когда-то прошел сертификацию.
2️⃣ Инженерная культура роляет. Просто из-за того что работающие у нас люди знают базовую гигиену, процесс сильно упрощается. Так что если вы не вкладываетесь в культуру, из-за того что эти инвестиции не окупаются, то технически это правда, а практически это покупает время и нервы.
3️⃣ Кубер — роляет. Я это и так знал, но все же, было классно услышать, о том, как гибкость, которую он дает, помогла быстро занести все нужные компоненты в удовлетворяющий всем условиям контур.

Такие дела. С крутыми людьми работаю, однако.
#опыт

🤷‍♂️ Почему принцип Парето так часто срабатывает?
Короче, это мегапушка. Прочитал тут просто НАИОХУИТЕЛЬНЕЙШУЮ статью не про программирование. Автор Эдриан Гор, основатель Discovery (не телеканал, если что, а фонд такой).

❓ Вы вот не задумывались почему в современном мире принцип Парето такая имба? Это не такой очевидный вопрос. Почему некоторые усилия приносят 80% результата, а другие только 20%?

Автор статьи утверждает, что вообще это не всегда было так, и до определенного момента в мире доминировало Гауссово распределение. Ну то есть если переводить на понятный язык: "30% усилий вероятнее всего дадут 30% результата"

❗️ И, если подумать, то, черт возьми, да! Для современного человека, правило Парето настолько естественно, что он даже не сразу понимает насколько оно по сути абсурдно. К примеру, если вспахать 20% поля, то ты вспашешь… 20% поля. Не бывает такого, чтобы ты выбрал какие-то нужные 20% поля, а еще 60% вспахались сами по себе.

Но тем не менее правило Парето работает, и мы это видим. И дело в том, что мир стал сложнее устроен.

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

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

Мне эта гипотеза показалась довольно интересной. Я не супер-знаток теории графов, но короче, кажется что в этом что-то есть.

🅰️ Мне нравится, что в конце статьи автор делится тем, что с этим всем делать на практике.

Инновации
"Сосредоточьтесь на смелых решениях в хвосте распределения, вместо того, чтобы добиваться последовательных изменений."

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

Управление рисками
"Одним из многообещающих подходов является объединение экстремальных значений и правдоподобности различных будущих сценариев (теория потенциальных неожиданностей Джорджа Шекла) для принятия решения в условиях крайней неопределенности.

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

Автор рекомендует заниматься такой штукой, как Scenario Planning. То есть прикидывать варианты развития событий и присваивать им вероятности того что они произойдут. Ваще мега-полезная штука особенно в такой неопределенности как сейчас.

Управление людьми
"Во-первых, нанимайте и удерживайте лучших специалистов на всех уровнях организации. Редкие звездные кадры по-прежнему будут сильнее других влиять на результаты компании — помните, что степенной закон упрям, — но это не значит, все усилия на найму и удержанию персонала должны быть сосредоточены только на них."

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

Вот такое чтиво сегодня!

🎢 Как я использую Chat GPT
С удивлением узнал от коллег, что у нас не все еще юзают ChatGPT на постоянку. ( Да как так-то ⁉️) Во многом потому, что не вполне понимают, чем им этот инструмент может помочь (считают слишком тупой эту штуку, если по-честному)

Короче, я посчитал, что просто обязан теперь всем пропагандировать работу с чатом ГПТ. Посему, решил показать, как я сам пользуюсь этой штукой, и как она мне помогает на примерах:
1️⃣ Проверяю смысл иностранных слов. К примеру у меня был выбор названия классов между Location и Coordinates. В чем разница? Оказалось, что Location более абстрактная структура данных, и может содержать в себе Coordinates, но вдобавок содержит в себе скорость, направление и прочие штуки.
2️⃣ Строю SQL запросы. Описываю свои таблицы и взаимоотношения между ними, индексы, которые там есть и прошу построить оптимальный запрос. Если что-то не выходит, то уточняю запрос.
3️⃣ Пишу всякие yml для Github Actions и прочего. Мне всегда лень это делать, а эта штука сильно ускоряет процесс. Просто говоришь, что тебе нужно и какие есть параметры и на выходе получаешь готовое решение.
4️⃣ Формирую Regex'ы. Вот это самое облегчающее мою жизнь действо. Если помните, то были даже всякие конструкторы для Regex'ов. Вот они теперь нахер не нужны. Даешь пару шаблонов, говоришь, какую последовательность нужно вытащить и получаешь рабочий Regex. Да а еще XPath'ы идут в ту же копилку.
5️⃣ Пишу бойлерплейт. К примеру код хэндлера просто генерирую в этой штуке. В идеале хочу прийти к AI aided testing, чтобы писать сразу тесты и код промптом. Но это подходит только для хорошо организованного проекта со стандартной структурой. Если там какой-то лютый велосипед, то все идет прахом.
6️⃣ Если учитывать копилот, который я себе недавно поставил, то он пока не приносит такого удовольствия, как я ожидал. То, что подсказывает, порой не подходит, но в целом что-то он упрощает, это да.
7️⃣ Пишу посты сюда (Да да, я сюда только матерок вставляю, а вы не знали? Ладно, это просто смехуечек. Посты здесь ручной работы!)

👍 Если подводить какой-то Rule of Thumb для использования ChatGPT в работе, то для меня он звучит примерно так "отдавать этой штуке все, что мне самому было бы скучно делать".

Так скажу, что ChatGPT на данном этапе сделал работу несравненно лучше. Если когда-то испытывали восторг от использования ReSharper (если кто-то вообще еще помнит, что это такое), то тут примерно те же ощущения.

Ну и, если вы поделитесь своими кейсами использования в комментах или в личке, то я буду неимоверно вам признателен!

🔬Мелкая декомпозиция, как она ускоряет разработку в разы?

Одна из самых полезных фишек, которую мне вдолбили в голову в Додо — задачу нужно дробить максимально мелко.

Если честно, я был убежден, что в Додо это очевидно всем, но недавно меня спросили: "А в чем плюс мелкого дробления задач?" Я рассказал на пальцах. Но меня еще раз спросили. Я снова рассказал. Но МЕНЯ ЕЩЕ РАЗ СПРОСИЛИ СЕГОДНЯ. Решил расписать, чтобы просто кидаться ссылочкой.

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

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

👯‍♀️ Две команды делали два новых сервиса. Сервисы предельно схожи по функционалу. В обоих нужно было собирать из шины сообщения и показывать цифры на телевизоре (разумеется в красивой оболочке, чтобы было секси и все такое).

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

Вторая команда выбрала вариант с выкаткой пустого сервиса в прод и постепенным доведением, мелкими шагами, до пригодного для демки вида.

Казалось бы, первый вариант правильный. Зачем тратить место на проде, если сервис еще не готов? Вот тут и произошла загвоздочка!

В какой-то момент в командах произошла одна и та же ошибка: сообщение из шины консьюмилось неверно и приводило к падению приложения. Разумеется на момент ошибки это было неизвестно, поэтому команды взялись за разбирательства

У команды номер один в момент поломки был готов и фронт и бэк, поэтому матрица диагностики состояла из трех вариантов:

1️⃣ Сломан бэк, фронт в порядке
2️⃣ Бэк в порядке, сломан фронт
3️⃣ Самый худший вариант: Сломано и то и другое.

У команды номер два матрица диагностики была такая:
1️⃣ Что-то сломано в бэке.

Чувствуете разницу? Три варианта против одного. Более того, в случае, если команда один сломала и фрон и бэк, то поиск проблемы усложняется многократно!

У команды два диагностика минимальна: "Мы выкатили коммит, где всего десять строчек. В них что-то видимо и сломалось."

В первом случае ошибку долго искали, и ошибка уже задевала пользователей. Во втором случае ошибку нашли быстро. И это были первые недели разработки, где у сервиса еще не было пользователей, так что никто не был задет.

В первом случае выкатка заняла время разработки + долгое время диагностики. (2 месяца в сумме)

Во втором случае только время разработки. (1 месяц в итоге)

И это то самое преимущество, которое дает мелкое дробление задач — устойчивость перед так называемыми Черными Лебедями. Вроде все очевидно.

И вы спросите, Димас, ну все же очевидно! Почему тогда люди не понимают, что дробить задачи нужно мелко?

Дело в том, что, если, у обеих команд все пошло бы гладко, то вся эта матрица проблем свелась бы к нулю. И тогда мелкая декомпозиция и время её выкатки не сильно отличится от времени выкатки БОЕВОГО МЕГАКОНЯ.

Тут я упомяну Канемана в суе. У него есть хорошая теория, что человеческое сознание делится на две системы Система 1 и Система 2.

Система 1 - это штука, которая работает быстро, не тратит энергию мозга, но и результаты выдает скверные. Она задействуется всегда, по делу и без.

Система 2 включается только в том случае, если мы напряжем мозги и потратим хуеву тучу энергии. Но и результат будет лучше.

Так вот. Чтобы расписать вышеприведенную матрицу надо напрячь мозги. Более того, нужно еще где-то на подкорке понимать, что может случиться ⬛️ 🦢Черный Лебедь. А это мысль неприятная, думать её тоже больно, что дополнительно толкает мозг думать проще "Выкатим все разом, ну там же ломаться нечему!"

🅰️ Итого, ТЛДР: Мелкая декомпозиция не помогает сделать быстрее в идеальном случае, она обеспечивает устойчивость по отношению к Черным Лебедям. Но вообще, по-честному, скажу так. В айти закон Мерфи работает всегда: "Если что-то может сломаться, то оно сломается" А это значит, что мелкая декомпозиция с ОЧЕНЬ большой вероятностью действительно ускорит разработку.

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