Отвечаю на вопрос "А как решать задачи на литкоде?", который часто встречаю в разных формулировках у себя в комментариях.

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

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

Выбирайте популярные задачи, у которых высокий процент принятия, начинайте с Easy задач. Не на каждом собесе спросят Medium, а Hard вообще нужен только чтобы потешить своё самолюбие.

Итак, как решать задачи на LeetCode

Открываете задачку. Читаете условие, выводите для себя границы задачи. Я в каждом ролике начинаю с чтения условий задачи, объясняю своими словами, что имеется в виду.

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

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

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

Воспроизведите код как запомнили: это важно сделать по памяти, ведь когда вы запоминаете, вы не заучиваете расположение символов, вы выстраиваете логическую связь: что за чем идёт, какие сравнения, и так далее.

Если не удаётся воспроизвести, пересмотрите разбор и попробуйте ещё раз.

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

Если полученный код не работает, сравните через любой diff checker (в PyCharm это compare with clipboard). Возьмите готовое решение, поменяйте там переменные на свои, сравните, где вы перепутали оператор, добавили лишний отступ, или обратились не к той сущности.

После того, как удалось подготовить рабочее решение, и литкод показал вам случайные числа, поставьте себе напоминание на завтра, чтобы вы решили эту задачку снова. Через неделю вернитесь к этой задаче вновь. После решения вернитесь к этой задаче ещё через месяц.
Так вы запомните суть и решение этой задачи.

Ну, это всё актуально, если вам действительно хочется разобраться и научиться.
Через сотню-другую задач вы начнёте замечать повторяющиеся модели / структуры задач, и будет легче.

Оказалось, что никаких секретов нет. Делают как делают. Чаще всего делают как попало. Потому что самое главное, чтобы хоть как-то работало. А какой ужас творится под капотом.. лучше бы вот это реально никому не показывали.

Да, есть крутые спецы, которые умеют построить технологичные и понятные системы. Но они существуют где-то там, в другом месте. А работать придётся с тем, что есть. С тем, что выполняет бизнес-требования.

С4
В проекте всегда можно выделить несколько уровней абстракции, и именно про это модель C4. Четверка в названии означает уровни:

1. Диаграмма системы — что приносит пользу пользователю. Система состоит из контейнеров.
2. Диаграмма контейнера — наши программистские сущности: базы данных, s3, отдельные приложения и микросервисы, это всё контейнеры. И каждый контейнер состоит из компонентов.
3. Диаграмма компонента — это модули ПО. Например, микросервис состоит из нескольких компонентов: СУБД, контейнер с приложением, веб-сервер.
4. Диаграмма кода — каждый компонент как-то напрограммирован. Вот тут можно сделать описание модулей и классов (опускаться до этого уровня обычно не нужно).

Кто кого?
Ещё есть правило, что нужно указывать направленность взаимодействия. Например, код ходит в базу данных. Да, тут сразу понятно, кто к кому обращается, ведь БД сама не ходит к приложению.
Если взаимодействие с API, то указывать направленность очень важно: мы можем запрашивать данные с внешнего ресурса, а также ресурс может уведомлять наше приложение о новом событии. И при указании направленности мы ещё и подписываем стрелочку, уточняем, что именно тут происходит.

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

PlantUML всё ещё актуален для Sequence диаграмм — схем с последовательностью действий, например “пользователь запросил А, система вытащила данные из B, перепроверила через C и отдала пользователю”. А вот если структура системы описана по C4, то это гораздо понятнее.

Кстати, что PlantUML, что C4 рисовать руками не нужно, используйте для этого текстовый формат: его легко версионировать и распространять. Есть свои языки для этого, а также реализации на привычных нам Python, JS и тд.

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

И наоборот, это хороший способ что-то забыть. Вот думаешь “я бы не хотел об этом вспоминать”, и вспоминаешь об этом раз за разом. А стоит подумать “буду об этом помнить”, и забываешь в ближайшее время.

У меня лучшие подписчики. Конечно, у каждого блогера именно его подписчики самые лучшие.

Спасибо, что читаете. Отдельное спасибо всем, кто проявляет активность: ставит реакции, пишет комментарии.

Например, этой ночью успели обсудить математические правила по приоритетам операций, финансовые инструменты (ипотеки, вклады), так ещё и успевали отвечать на вопросы по коду.

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

А кто считает, что я неправ, что у меня лучшие подписчики, можете отписываться, ведь качество важнее количества.

При этом важно уметь задавать вопрос. Если вы не можете описать проблему, сформулировать мысль, то вам не смогут помочь. Помните про непривет и проблему XY.

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

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

А одинэсники.. они просто счастливы.

Часто испытываете синдром фронтендера?

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

Паркинсон сформулировал закон тривиальности так: «Время, потраченное на обсуждение пункта, обратно пропорционально рассматриваемой сумме». Это всё про то, что людям легко обсуждать незначительные решения, но тяжело принимать действительно важные.

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

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

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

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

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

Можно объяснить чисто экономически: раз они звонят тебе, им от тебя что-то нужно. А если им от тебя что-то нужно, насколько это выгодно тебе? Если бы это была win-win ситуация, стали ли бы они тебе звонить? Более того, ни одна win-win сделка на самом деле не является таковой, ведь каждая из сторон идёт на компромисс.

Ну вот и всё, просто отключаем приём звонков, да?

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

Да, курьеры Озон (хоть и не все) уже научились писать СМС и даже в Телеграм, чтобы уточнить время доставки. Но, к сожалению, передать информацию текстом могут не все. И это печально.

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