365 дней богу Алгоритмов

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

Для меня уже не первый вызов себе. С 2018 по 2019 устраивал «365 дней Хемингуэю». Тогда у меня был литературный запой. Я прочитал за год около 100 книг и ежедневно писал небольшие рассказы, качая навык сторитейлинга.

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

Такие челленджи дают уверенность, что побеждает не сильнейший. Побеждает самый стойкий. Проверю же свою

Как решать алгоритмы?

Точного ответа никто не может дать. Изучая советы по подготовке к изучению алгоритмов выявил для себя такую стратегию:

Не стоит сразу брать и решать литкод. Эту тактику я взял у создателя комьюнити фаанг-интервью, который попал вроде в гугл. Эти стратегии транслируют в книге “cracking the coding interview”.

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

Этому меня научил и Стивен Кинг. Нет, он не решал алгоритмы. Он написал книгу «как писать книги». Ее я брал за основу к своему прошлому челенджц. Где для написания хороших книг нужно уметь много читать и уметь много писать.

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

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

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

Бинарный поиск

Решил начать с основ. Почти все книги про алгоритмы начинаются с этого. Почему? Да потому что этот алгоритм лежит в основе системной функций сортировки, почти во всех языках.

В чем его идея?

Мы делим пополам заранее отсортированный массив, чтобы обнаружить нужный элемент. Вот и всё.

Алгоритм такой:
1. Сортируем массив данных
2. Делим его пополам и находим середину.
3. Сравниваем средний элемент с заданным искомым элементом.
4. Если искомое число больше среднего — продолжаем поиск в правой части массива (если он отсортирован по возрастанию): делим ее пополам, повторяя пункт 3. Если же заданное число меньше — алгоритм продолжит поиск в левой части массива, снова возвращаясь к пункту 3.

Задача в литкоде

сложность: logn (без сортировки)

#365_дней_богу_Алгоритмов #1

Swift Learning Roadmap 2023

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

- Знание языка
- IDE
- GIT
- UI

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

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

Проход отсортированного бинарного дерева

Тут я взялся за дейли контест.

Алгоритм такой:
1. Ищем родительскую ноду
2. Идем по левой
3. Доходим до конца
4. Идем вправо

- Литкод задача

- Хорошее объяснение бинарных деревьев

#365_дней_богу_алгоритмов #2

Мода на решение задач в литкоде становится все популярнее.

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

В статье автор высказывает мнение о пользе.

Я же считаю, что ежедневное нарешевание задач равно улучшению общих физических показателей.

Как в спорте. Спортсмены 70-80% бегают, прыгают, развивают тело. Увеличивая базовые показатели скорости, силы и выносливости. А потом остальные 20-30% тренируют в зале технику: играют в игры, борятся, спарингуют.

Условно алгоритмическая секция — это что-то вроде оценки твоих базовых показателей.

https://habr.com/ru/post/709550/

Обратный обход бинарного дерева

Последний из основных способов обхода дерева. Решил через очередь.

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

Задача на литкоде

Сейчас пока решаю задачи на уровне интуиции, а мб потом начну подключать попытки осилить математические доказательства

Не знаю стоит ли делать отдельные посты про полезные ссылки и объяснять деревья без задач. Ибо это пост ради поста, а без практики это все из головы ветром сдует.

Ставь 💅 если делать отдельные посты про техники. Или 🗿 если публиковать только ссылки с задачами. А там сами уже разберутся

#365_дней_богу_алгоритмов #5

Корень числа с бинарным поиском

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

Наглядный пример поиска корня. Изи решается через тот же бинарный поиск

Задача в литкоде

#365_дней_богу_алгоритмов #6

Онанизм на код ревью

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

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

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

Хороший код — это не косметика, читабельность, соответствие линтер правилам.

Хороший код — быстрый, стабильный и поддерживаемый. В последнюю очередь это про правила линтера

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

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

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

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

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

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

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

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

Задача программиста решать задачу. А потом учиться решать ее красиво