#common #pub

В марте я ходил в гости к ребятам из Выше Вилки (конкретно Илье Шишкову).

Говорили про саморазвитие, бабки и что-то ещё. По ряду тем можно подумать, что мы ещё и про крипту болтали, но нет. Всё цивилизовано. Спасибо Илье за новый опыт. Получилось интересно.

Смотреть тут: https://youtu.be/6BNH4BNhvxY

#cpp

1. [talk] Gazing Beyond Reflection for C++26.

Daveed Vandervoorde рассказывает про осенний state рефлексии. В докладе огромное кол-во примеров. В том числе не самых тривиальных. В том числе со ссылками на godbolt. За полгода, прошедших с конференции, видимо, многое поменялось, т.к. часть примеров уже не работают, но всё равно можно потыкаться и попробовать всякое разное.

Мне очень понравилось, когда на слайде у него было ... как знак неважности происходящего, а в godbolt вместо трёх точек 120 строк какого-то нетривиального кода.

2. [article] Tech Debt doesn't exist, but trade-offs do.

Чувак говорит, что метафора тех долга не прям корректна и надо от неё отказываться, т.к. на самом деле это не долг, который надо обязательно погасить. Это трейд офф и чтобы с ним в будущем разобраться, вам нужно честно ответить себе и бизнесу на k вопросов, которые дадут полное понимание текущих и будущих проблем.

3. [article] How Not To Sort By Average Rating.

Статья 2009 (!!) года про то, как правильно ранжировать айтемы при наличии лайков-дизлайков. Имхо оч забавная, потому что говорит "не надо делать 1 и не надо делать 2, вместо этого делайте 998244353".

4. [article] The Best Programmers I Know.

В конце статьи есть такая цитата

don’t trick yourself into thinking that you can skip the hard work. There is no shortcut.

Так что я ничего про содержание не скажу. Читайте сами.

Я в последнее время начал заниматься всякими конфами и митапами не только со стороны выступающего/участника, но и в каком-то виде организатора. Про внутренние рассказывать не буду, а вот про внешние могу себе позволить. Сейчас, например, я являюсь членом программного комитета самой большой конфы нашей бизнес-группы Яндекс dev day&night.

Там будет два трека для мобилки и один продуктовый. Будет игровая зона. Но нас с вами конечно интересует самое вкусное -- backend.

Я видел доклады ребят и непосредственно участвовал в их улучшении, потому в качестве контента уверен. На всякий, если ленитесь открывать ссылочку, они:
- про то, как работает поиск в Маркете
- про внутреннюю очередь задач
- про геопоиск и R-tree в Еде
- и про нагрузочное тестирование в наших сервисах.

Хотя может вам интересно и продакт-менеджеров послушать. Осуждать не буду.

Конфа 19 апреля с обеда до глубокой ночи (поняли? типа day&night). Регистрация уже скоро кончается. Залететь можно по ссылке.

#common

Сегодня 1 апреля, потому можно позволить себе некоторую вольность в материале.

Меня всегда занимали разные парадоксы. Не все, конечно. Только некоторые. Например, парадокс горки (я не знаю, как он называется в оригинале). Давайте проведём мысленный эксперимент. Вот есть у вас песчинка. Одна маленькая песчинка. Вы добавляете к ней вторую. Теперь это 2 песчинки. Вы добавляете по одной песчинке и в какой-то момент у вас уже не просто много отдельных песчинок. У вас уже что-то вроде горки. Такая небольшая, насыпанная вами сущность-композиция. Если вы продолжите добавлять по одной песчинке, то на бесконечности у вас образуется гора. Огромная такая гора песка. А теперь вопрос: в какой момент она стала из горки горой? Вы теоретически можете добавлять по одной песчинке, считая их, и наверное сможете сказать, что вот эта, n-я песчинка всё меняет. Она перешла черту. Она всё изменила. На практике же такого момента не будет.

Это заставляет меня регулярно задумываться о том, как вообще разграничивать размеры.

Вот есть эти наши микросервисы. У них в названии есть МИКРО. Типа маленький. Сервис на 10^(-6). Но что такое микросервис на самом деле? Вы можете активно его развивать, регулярно дописывать код и в какой-то момент понять, что теперь компилируется он слишком долго, изменения занимают всё больше времени. Деплоится тоже долго -- команда во время релиза успевает сделать три другие задачи. Но в какой момент надо было остановиться и сделать что-то в другом месте?
Может ваш микросервис сам по себе даже и небольшой. Кода в нём не так много. Зато внутри у него 5 слоёв абстракции, 13 библиотек, бдшка и задачи в 3 очереди кладутся. Там может хорошая декомпозиция и нет огромных файликов, с другой стороны по 40 хедеров на директорию, 6 из которых уже несколько лет отключены в проде, но всё ещё лежат, ведь никто просто давно на них не обращал внимания.

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

Есть ещё такие сервисы, которые называют микромонолиты. Типа микросервис, который уже большеват. Что-то типа 10^6 * 10^(-6). Микромонолит такой же опасный, как микролит в почке. Он сейчас вроде есть и никому не мешает, но в один момент резко стрельнет и будем всей разработкой пищать.

Ещё у вас может быть монолит в микросервисе. Это когда из 20к строк половина -- один файл. Я даже видел чуть более интересные случаи: полный готовый коммерческий продукт с графикой и сложной математикой в одном файлике на 10к строк. Чем не монолит? Такое тоже наверное надо распиливать.

Или вот это, популярное в Clickhouse small update на +1000 -700 строк. Декомпозицию на задачи мы тоже не забываем.

Или вот эта небольшая задачка от продукта. Где надо 5 кнопок из места в место перенести и это выливается в 1.5 месяца разработки. Небольшое изменение вроде, а вы там какие-то схемы сидите рисуете.

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

Или моё любимое: two-pizza team -- команда, которую можно двумя пиццами накормить. Типа маленькая. Никогда не понимал, что это за объём такой странный. 2 пиццы это нам с девушкой на двоих, причём 1.5 съем я. Мы конечно отличная команда, но наверное это не то, что имеется в виду. Делает ли моя возможность съесть 1.5 пиццы меня командой на 0.75? А если я голодный, то я и целой командой себя назвать могу? Может 10X инженеры на самом деле просто голодные?

Или когда про людей думаешь. Говорят вот "он большой человек".
А я большой? Ну физически может и да. Чуть больше среднего человека. В моей стране так точно.
По возрасту тоже большой, то бишь взрослый.
По виду ещё старше. Мне из-за бороды в среднем лет 10 сверху накидывают.
А в душé? А как люди меня видят? Какой задел для роста у меня остался? Я ещё горка или уже гора? Когда я ей стал? Может меня тоже пора распилить?

У вас спина белая.

#cpp #highload #common

0. [talk] The Beman Project: Bringing C++ Standard Libraries to the Next Level.

Докладчик рассказывает про bemanproject, который должен помочь во внедрении предложений в стандарт через получение раннего фидбека о потенциальной имплементации пейперов. Если точнее, то сначала про мотивацию, потом про принципы работы и в конце накидывает примерчиков. В конце участники проекта коллективно отвечают на вопросы о проекте.

Имхо очень естественное и красивое дополнение к процессу принятия пейперов. Выглядит ну очень вкусно. Интересно только, кто осмелится затаскивать к себе либу, чтобы тестить потенциальные новинки пораньше и репортить фидбек, ведь это тянет за собой постоянное обновление либы, ресурс на переход на стандартные средства и потенциальное выпиливание outdated кода, который принят не был.
Хочется посмотреть на это через пару лет.

1. [article] The billion docs JSON Challenge: ClickHouse vs. MongoDB, Elasticsearch, and more.

Чуваки из ClickHouse сделали бенчмарк, в котором обрабатывали 5 агрегационных запросов на датасете из 1 млрд реальных JSON. Сравнение было с MongoDB, Elasticsearch, DuckDB и PostgreSQL (думаю, вы уже поняли, кто показал себя лучше всего).
Во-первых, имхо очень хороший пример того, как надо бенчмарки описывать. Во-вторых, я не прям уверен, что сравнение всё-таки корректное, т.к. все рассматриваемые бдшки (кроме DuckDB, это хз что такое) концентрируются на не совсем тех же задачах (в моей голове), так что могут спокойно на конкретных сценариях проигрывать. И это нормально.
В-третьих, тем удивительнее, что эластик не пальцем деланый и результаты по перфу на этой задаче у него уходят недалеко. Новое открытие для меня.

2. [article] My DOs and DON’Ts of Software Architecture.

Вот вроде почитаешь статью и подумаешь, что всё очевидно. И непонятно зачем на это время тратил(-а).
На практике, правда, всё не так clear, и иногда распознать базовые случаи, в которые стоит поступить ровно так, как написано, сложно. Или иногда сложно понять, а как правильно сейчас поступить.
В моей голове эти пунктики очень хороши для вашего роста, если вы хотите расти быстро. Но ещё важно не забывать, что иногда надо не расти, а учиться. И что эти вещи не всегда в моменте совместимы. Вдолгую да, но не всегда сейчас.

#cpp

Наконец выложили все интересные мне доклады с C++ Russia 2024. Чекаем:

1. [talk] О денотации: разрешение имен и его пересмотр в C++23. Константин Владимиров.

Надо думать, да. Но кайф.

Мне ещё, чисто концептуально, понравился мув сделать список рекомендуемых вопросов и ответов на них. Я такое повторял пару раз и было красиво.

2. [talk] Обзор C++26. Александр Фокин.

Местами кайф. Дай бог дожить до всего этого счастья в проде.

3. [talk] Контракты для С++. Тимур Думлер.

От кого ещё слушать про контракты, если не от одного из авторов пропозала.

4. [talk] LeakSanitizer и менеджмент памяти. Алексей Веселовский.

Немного хардкорчика и внутрянки санитайзеров.

5. [talk] Pets, cattle and automatic operations with code. Святослав Фельдшеров.

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

6. [talk] Дерево смещений: работаем с динамически изменяемыми сегментированными массивами. Роман Панов.

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

7. [talk] Грязные C++ трюки из userver и Boost. Антон Полухин.
Или можно почитать текстовую версию на habr.

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

8. [talk] Улучшенные версии STL-контейнеров из библиотеки Boost. Илья Мещерин.

Несложно и интересно. Мне вообще вот такое всё интересно. Про контейнеры и штуки около. Думаю, что надо бы вылить своё понимание этой всей мишуры в вас когда-нибудь.

9. [talk] Полезные трюки С++ на примере организации пайплайна. Павел Сухов.

Я уже кидал ссылку на текстовую версию доклада коллег из Доставки.
Понравилось, что речь про реальную задачу и что в этой реальной задаче получилось поюзать нетривиальные возможности плюсов. Всё то, чего мы так сильно хотим, но так редко можем.

10. [talk] JSON в C++: проектируем тип для работы с JSON-значениями. Павел Новиков.

Забавно, что Павел придумал себе проблему и сражается с ней.
У Павла ещё была вторая часть этой эпопеи на C++ Zero Cost Conf, но она мне меньше зашла. Оставлю тут для полной картинки.

11. [talk] Опасность устарела, неопределенность недопустима: undefined behavior в С++20/23/26. Сергей Талантов.

Хороший доклад про undefined behaviour. Имхо этого никогда не бывает много. Мы ж не хотим сегфолтики в проде ловить??

12. [talk] constexpr-аллокатор для контейнеров стандартной библиотеки. Сергей Добычин.

Я люблю контейнеры, люблю аллокаторы (пруфы раз два) и люблю constexpr. Тут всё разом. Доклад немного напряжный. Надо думать. Но имхо резы у чувака крутые.

13. [masterclass] Выше вилки от Ильи @imhired Шишкова.

Очередное напоминание про то, что мы работаем так или иначе ради бабок и что их надо где-то брать. Вот если ребят внимательно послушать, то складывается хорошая картинка.

Онлайн часть C++ Russia 2025 начинается уже завтра. Туда вы можете зарегаться бесплатно в рамках комунити дня.
Я планирую выступать на следующей неделе с, кажется, единственным лайтнингом в этом году и заодно у Паши Сухова на докладе про шаблоны поторчу экспертом. Можете меня где-нибудь найти поболтать, если интересно : )

#highload #cpp #common

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

std::remove(vec.begin(), vec.end(), 0);

И для примера

vec = {1, 4, 0, 2, 0, 0}

получаю

{1, 4, 2, 2, 0, 0}

Где-то есть баг.

Очевидно, что баг был в моей интерпретации алгоритма. Вот как выглядит стандартное использование std::remove до C++20:

vec.erase(std::remove(vec.begin(), vec.end(), 0), v.end());

В голове я строю последовательность происходящего:
- все нули ушли в конец
- получаю итератор на первый нуль
- удаляю все нули.

И в первом пункте уже ошибка. Ведь нули не ушли в конец. Наоборот, в начало ушли все не нули. Что там в конце, меня ебать волновать вообще не должно. Оно всё равно будет удалено.

То есть мы имеем на текущий C++20-й момент:
- удаляем элементы мы с std::erase/std::erase_if
- если я хочу все нули в конец, то мне нужен std::partition
- std::remove/std::remove_if нужен только ради обратной совместимости, т.к. никакой уникальной задачи он уже не решает. Жаль братка.

1. [talk] Как развивалось прогнозирование в Яндекс Погоде.

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

2. [article] Accelerating LinkedIn’s My Network tab by reducing latency and improving UX.

Суть статьи в названии.
У нас есть какая-то похожая задача, потому было интересно почитать. Жаль только, что они всё же различаются достаточно, чтобы не суметь перенять подход.

3. [article] Your business value.

Очень хорошая статья, которая в каждом предложении напоминает про то, зачем профессия программиста существует. Она, так сказать, постоянно cycle on a subject о вашей личной полезности для бизнеса и разбирает кейсы роста/увольнений в зависимости от разных факторов.
Будьте профитными.

Антон Полухин выложил статью про новинки в C++26: C++26 — встреча ISO в Хагенберге.

Из новых фич к нам подъехали:
- std::hive (пейпер P0447 пережил 28 ревизий и наконец сложился)
- constexpr all the things (покрыли ещё пару кусков стандартной либы)
- #embed
- контракты и другие движения в сторону увеличения безопасности нашего кода
- честный relocate для некоторых типов
- и другое: simd, новые алгоритмы и другие приколюхи.

Осталось дождаться это счастье в компиляторах👉👈

А ещё 25 марта пройдёт встреча РГ21 по C++. Встречу проведёт Антон. Можно обсудить новости последней встречи комитета по стандартизации, задать вопросы и получить на них ответы и потусоваться на афтерпати после : )

Онлайн и оффлайн, Москва.

Регистрация тут.

#common #highload

Иногда я замахиваюсь на что-то, что не могу скушать за один присест. Как сейчас. Я хотел просто написать небольшой постик про базу CRDT, а когда пошёл вникать, понял, что базово не получится. Получится скорее душно; придётся потратить больше времени, чем я готов; а чтобы нормально разобраться и объяснить, по-хорошему бы что-нибудь сесть покодить. Потому вместо готового текста сегодня сборка материалов по одной теме (я видел у людей, так делают).

Материалы, помеченные звёздочками, скипабельны, но могут помочь в более глубоком понимании.

Что впитать по CRDT.

На всякий случай я дам вам критерий, который поможет вам отсеять душные тексты от дворового контента (если вы любитель читать формальные статьи, то скипайте этот абзац): если в статье про CRDT вы встречаете слово "полурешётка", то закрывайте её. Вероятно это очередная статья на хабре, в которой формализм есть только для потешения эго автора. Всё, что нам нужно помнить про требования к свойствам операций для CRDT, -- это идемпотентность и коммутативность. Из них следует, что если у вас есть одинаковые множества операций над объектами (в любом порядке), то и стейты объектов будут одинаковыми. Больше пацанам и дамам ничего знать не надо.

А теперь ссылочки.

[*articles] Можно начать с нескольких статей Matthew Weidner:
- Introduction
- Semantic Techniques
- Algorithmic Techniques
- Further Topics
Они немного душноватые, но если посидеть и подумать, а не смотреть тикток параллельно с чтением, можно что-нибудь понять.
[*articles] Если у вас много-много времени, то можно почитать 12 статей от Bartosz Sypytkowski. Каждая из них поменьше, так что может пойдёт легче.
Если прочитаете и то, и это, будете совсем большими молодцами и, много всего поймёте.
[*talk] Или может вам больше нравится видеоформат, так что можете послушать ликбез по основным структурам данных в CRDT концепции: CRDT: Datatype for the Apocalypse. Правда сумейте вовремя остановиться, а то с какого-то момента начинаются Elixir-специфичные вещи, а мы всё-таки с вами на C++ пишем.

[talk] Теперь слушаем рассказал Martin Kleppman: CRDTs and the Quest for Distributed Consistency. Тут он рассказывает и про Operational Transformation (OT), и про CRDT, и про очень важный в этой сфере Automerge. Есть много примеров, которые сильно качают понималку.

[*talk] Дальше можно посмотреть старенький доклад про зачатки Google Docs и увидеть (если внимательно присмотреться) некоторые проблемы OT. Примерно так гуглодоки сейчас и реализованы.
[*article] Ну и тут вы можете почитать про то, как потенциально могут работать Google Sheets: Conflict-free Replicated Spread Sheets.

Дальше можно посмотреть отличный доклад того же Martin Kleppman: CRDTs: The Hard Parts. Тут вы узнаете, почему из "Hello Alice!" и "Hello Charlie!" может получится "Hello Al Ciharcliee!", про [открытые] проблемы перемещения элементов/символов/поддеревьев.

[*article] Интересно, что в докладе выше Kleppman говорит, что у LSeq есть проблемы, т.к. этот подход interleaving. А вот Bartosz Sypytkowski писал про non-interleaving версию. Что-то там проапдейтил, лис.

[*article] Опять же в докладе Kleppman рассказывал про проблемы оверхеда CRDT. И это то, из-за чего CRDT иногда недолюбливают. Тут статья оптимизацию частных случаев: Making CRDTs 98% More Efficient.

[*article] Тут есть очень прикольная (и жирная) статья про то, как в каком-то Loro реализовывали свой очереднярский CRDT алгоритм для текста. Понравилось, потому что в начале есть интерактивная штука потыкаться и очень много букав. Прям фундаментально тему осветили.

[talk] Ещё есть вот такой несложный докладик про то, как работает delta -- коллаборативный сервис для ведения заметок в Яндексе. Я вот им прям каждый день пользуюсь и очень довольный.

[*site] И если вдруг вам не хватило контента, идите на crdt.tech. Там ещё тыща тыща постов, докладов и настоящих статей.

Что-то люди напридумали себе проблем и сидят их решают. Коллаборативное редактирование какое-то. Консенсус. Раньше вот угольком по очереди на камне мамонтов рисовали и всё норм было. Чего завелись.

#common #highload

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

0. [article] Taking a Look at Compression Algorithms.

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

1. [article] SQL as API.

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

2. [article] Don't make these feature flag mistakes.

Автор рассказывает про потенциальные проблемы, связанные с использованием feature flag'ов, и их решения. Среди прочего есть маленькая история про то, как компания чуть не обанкротилась из-за проблем с этим инструментом. Но, что важно, в конце напоминает, что полностью отказываться от этого инструмента нельзя, т.к. он всё же жутко полезный.

#common #highload

Принёс доклады с Saint Highload++ 2024.

1. [talk] Как работать с поставщиками на примере поиска доступных отелей. Иван Чернов.

Люблю доклады про поиск в любом виде. С лета как раз из-за этого доклада Ваню и читаю (@chernov_sharit).

2. [talk] Про UUID v.7. Андрей Бородин.

Хороший доклад про технические детали реализации uuidv7 в БД. После него как раз пошёл писать пост про uuid'ы.

3. [talk] Регламент для работы с ошибками в Go. Илья Сергунин.

Люблю доклады, которые пытаются систему дать. Конечно, если кто-то после таких рассказов начинает душнить, что надо делать только так а не эдак, то пошёл в жопу, но забирать себе разумные поинты никто не мешает.

4. [talk] Геораспределенные системы. Евгений Кузовлев.

Хороший доклад про базу геораспределённых систем. С примерами ещё. И Евгений рассказывает приятно.

5. [talk] Enterprise deploy: почему это больно. Филипп Дельгядо.

Системно и подробно про деплой как концепцию.

6. [talk] Механизм пререндера в браузерах. Алексей Кузнецов.

Было прикольно погрузиться в область, в которой я совсем ничего не понимаю. Хороший понятный рассказ про что-то новое.

7. [talk] «А так можно было?» — обзор нестандартной криптографии. Сергей Прилуцкий.

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

#math #cpp #highload #common

0. [talk] YouTube Scalability.

Доклад про то, как скейлился youtube. Чувак рассказывает про основные проблемы, с которыми столкнулась [тогда ещё] небольшая команда, вплоть до невозможности загружать видео на платформу. Между делом бывают забавные вставки. Несмотря на то, что информация не везде знакомая, рассказывают очень понятно.

Доклад довольно старый. 2007-ого года. Я в школу в том году пошёл.

1. [article] 2D Visibility.

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

2. [article] Cognitive load is what matters.

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

3. [article] End-to-end Шифрование.

Вастрик написал пост про End-to-end шифрование. В своём классикал стиле и как для тупых.

4. [article] 4 billion if statements.

Автор увидел тик-ток, где кто-то ифал каждое число, чтобы определить чётное оно или нет. И автор решил посмотреть, насколько сложно вообще такое написать. Он начал с простого ифания нескольких чисел, потом пошёл генерить код, после чего пошёл генерить asm. И после некоторых манипуляций всё заработало! Такой минизабавыч в конце.

#cpp #common #math

1. [talk] C++ Reflection Is Not Contemplation.

Доклад Andrei Alexandrescu с CppCon 2024 про рефлексию. Чуть-чуть посмотрели на базу, посмотрели на несколько последних пропозалов и ушли в сторону в какие-то абстрактные рассуждения. В классической свободной заводной манере. Лайкнул.

2. [talk] Building Cppcheck - What We Learned from 17 Years of Development.

Автор cppcheck рассказывает про то, как развивался проект и про разные вехи на этом пути. Не прям технический доклад. Интересно посмотреть на историю известной тулзы.

3. [article] Preferring throwaway code over design docs.

Автор предлагает почаще кодить прототипы перед тем, как писать дизайн доки/писать финальное решение. Так вы получаете некоторые знания о потенциальных проблемах заранее. А ещё позиционирует смерженные pull request'ы как хорошую "документацию", т.к. они всегда актуальны для какой-то точки в истории. Со вторым я согласен. Но с первым нет. В условиях постоянной гонки и нехватки ресурсов нет времени садиться писать код для большинства фичей. А там, где ошибка стоит дороже всего (большие проекты с жёсткими дедлайнами) такой подход может сильно скушать время, т.к. для большой фичи -- большой прототип.

4. [article] Probability and Games: Damage Rolls.

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

В дополнение закину вам баянистую таску с собеседований в тему (правда не знаю, куда конкретно; мне её рассказывали много-много лет назад).
У вас есть функция rand6(), которая равновероятно возращает целое число из отрезка [0; 5]. Как из неё сделать:
- rand2?
- rand36?
- rand5?
- rand10?
Все они должны строиться поверх rand6 и производных и должны возращать числа равновероятно.