Перевод статьи «How a year-long LeetCode habit upped my professional game» из блога Злых марсиан.
Культ лайвкодинга и алгоритмических задач процветает до сих пор. Вопросы в стиле «как преобразовать бинарное дерево» или «как написать пирамидальную сортировку» регулярно встречаются на собеседованиях не только в бигтехе — хотя это и не те задачи, которые каждый день решает среднестатистический разработчик. Из-за этого многие программисты начинают искренне ненавидеть алгоритмы.
Однажды я зашла на LeetCode, одну из популярных платформ для решения алгоритмических задач. Сразу уточню: мне не нужно было готовиться к собеседованию, и моя работа не требовала продвинутого знания алгоритмов. Тем не менее я заметила, что у меня стали заполняться пробелы в знаниях, и я продолжила решать задачи — каждый день понемногу.
С тех пор у меня накопилось более 400 решённых задач на LeetCode. Теперь я уверена, что такие платформы как LeetCode, HackerRank или CodeWars, при правильном подходе, способны поднять профессиональные навыки любого разработчика на новый уровень.
Вот чему я научилась за год ежедневного решения задач:
В моём коде стало меньше багов. Навык самопроверки улучшился, появилась привычка думать об ограничениях и пессимистичных сценариях;
При этом заметно увеличилась скорость написания кода. Многие вещи теперь делаются на «автомате»;
Я больше не боюсь сложных рабочих задач;
Я научилась качественнее объяснять свои решения и больше думать о чистоте кода;
Мой уровень самодисциплины возрос.
Но обо всём по порядку.
1. Больше внимательности, меньше багов
Привычка думать о случаях, в которых написанный тобой код «сломается», – очень полезна для разработчиков.
Я люблю LeetCode за то, что он мягко заставляет тебя если не писать, то хотя бы мысленно просчитывать разные тестовые сценарии. Перед тем, как принять решение задачи, платформа всегда проверяет его по многочисленным тестам.
Может случиться так, что падает всего один сценарий из сорока, и он вынуждает тебя переписывать половину твоего кода. Это может сильно раздражать. Да и в целом видеть после отправки решения грустные красные буквы «Wrong Answer» – удовольствие ниже среднего. Особенно если задача сложная.
Поэтому с увеличением количества решённых проблем я заметила, что стала чаще анализировать указанные ограничения перед тем, как приниматься за задачу; больше думать о том, в каких случаях код даст сбой; и проверять всё больше тестовых случаев перед тем, как отправить итоговое решение.
Особенно приятно то, что с течением времени это стало проявляться не только при решении алгоритмических задач, но и на моей работе, а также при написании собственных проектов. Как правило, в обычной рабочей атмосфере нам не высвечиваются слова «Wrong Answer», когда мы допустили ошибку — это всплывает позднее в виде бага у клиента.
Поэтому задаваться вопросами в духе «упадёт ли моя функция, если входные данные были очень большие или, наоборот, пустые» – отличная привычка. Тренировка на коротких алгоритмических задачах помогает развить её лучше всего.
Что ещё поможет, чтобы наработать внимательность и делать меньше ошибок?
Обращать внимание, как те или иные ограничения в задаче влияют на предполагаемое решение. Например, если в массиве может быть миллиард элементов, то решение брутфорсом вряд ли подойдёт;
Анализировать, насколько велика сложность решения по времени и по памяти, используя нотацию «О» большое. Не стоит обращать внимание на процент «успешности» времени выполнения кода, который показывает Leetcode после отправки. Он бесполезен; в этой статье подробно рассказывается, почему это так;
Всегда помнить про пессимистичные сценарии, а не только про общие.
2. Скорость написания кода растёт, решения изобретаются быстрее
Я не ожидала этого, но с приятным удивлением заметила через полгода: у меня стало уходить примерно в 1.5 раза меньше времени на задачу по сравнению с тем, когда я начинала.
С чем это связано? Даже при выборе разнообразных задач в них прослеживаются общие паттерны и подходы к решению. Например, обход бинарного дерева – через несколько месяцев периодического решения «деревьев» ты напишешь этот алгоритм с закрытыми глазами и без лишних раздумий.
Это касается и скорости выбора способа решения. В своё время я набила шишек, выбирая изначально неверный подход к задаче. Это нормальный процесс обучения; сейчас я быстрее соображаю, куда нужно пойти в начале, чтобы с большей вероятностью выйти на верный ответ. Например, если не знаешь, как решить задачу, где в качестве входных данных даётся массив элементов, то сначала попробуй отсортировать его.
Может быть, вам никогда не понадобятся алгоритмы из сложных задач на Leetcode. Но быстро писать реализацию несложных вещей и совершенно не задумываться над ней довольно неплохо, не правда ли?
Вот мои советы по развитию скорости:
Осваивайте темы в комфортном для себя темпе, переходите к следующей, только когда вы уже чувствуете уверенность в текущей. Например, сначала прорешайте 7 лёгких задач на деревья, 10 средних и 4 сложных, и только затем переходите, например, к спискам. Я не советую брать каждый день случайные задачи, поскольку это не позволяет сфокусироваться на освоении конкретной темы;
Не забывайте повторять старые темы. Даже если вы освоили тему деревьев, выполняйте задание по ним каждые пару недель;
Попробуйте решить лёгкую для себя задачу, но введя ограничение по времени, – например, десять минут. Иногда создание искусственной нехватки времени может заметно увеличить продуктивность.
3. Прививка от страха перед сложными задачами
Я не пытаюсь продвигать иллюзию того, что продвинутое знание алгоритмов, вообще-то, абсолютно необходимый навык, без которого нельзя стать программистом. Для определённых разработчиков, работающих со сложными предметными областями и оптимизациями, – вполне возможно, это будет очень нужно. Но не всем подряд.
Я – фронтенд-разработчик, и за последний год встречалась с необходимостью использовать нетривиальные алгоритмы несколько раз. Наиболее сложные случаи были связаны с визуализацией графов.
Но хоть это и было несколько раз, я чётко осознаю, что столкнись я с такими задачами раньше – я бы испугалась сильнее и потратила бы на задачу больше нервов и времени. Однако с закалкой на LeetCode я восприняла их не как «что-то новое и страшное», а «наконец-то интересное и азартное».
Алгоритмические задачи не только отлично готовят к сложным рабочим задачам, которые встречаются редко, но метко. Я заметила, что активное решение лёгких задач позволяет нарабатывать автоматизм и даже подтянуть знание языка программирования.
Например, сейчас я совершенно не задумываюсь, как работают встроенные методы в JS: что возвращает .push(), или мутируют ли исходный массив методы .slice() или .splice(). Эти знания нельзя назвать алгоритмическими, однако регулярное решение LeetCode помогает твёрдо их усвоить.
Вот как можно начать чувствовать себя намного увереннее независимо от уровня сложности задачи:
Некоторые сложные задачи могут быть довольно экзотическими, так что не расстраивайтесь и не опускайте руки, если не можете их решить. Даже если вы готовитесь к собеседованию, по статистике, они встречаются очень редко.
Не забывайте пробовать применять полученные знания на работе ('use it or you lose it'). Например, когда это уместно и имеет смысл, попробуйте использовать структуру данных Set вместо Array;
Если вы только осваиваете новый язык программирования, то простейшие задачи хорошо помогают с этим. Вы поймёте синтаксис и особенности языка намного быстрее, чем если бы просто читали теорию.
4. Почва для искусства объяснения решений и чистого кода
Пару раз я натыкалась на критику, что сайты вроде LeetCode плохи тем, что они позволяют писать код как угодно грязно, лишь бы он работал. Это верно; но приучение разработчика писать чисто и не является их основной целью.
Тем не менее я заметила, что всё же есть возможность научиться писать код чище и объяснять решения, используя LeetCode. Почти всегда на подобных сайтах есть раздел, где разработчики публикуют собственные решения. Иногда их можно оценивать, и тогда в топ попадают наиболее понятные решения с лучшими объяснениями.
Когда я начала прояснять непонятные задачи, вчитываясь в решения и объяснения опытных разработчиков, мой процесс обучения пошёл в гору. Я и сама попробовала выкладывать собственные решения. К тому времени я поняла, что людям полезно, когда решения объяснены кратко, но ясно.
И тогда я стала работать над детальным описанием решений, а ещё над чистотой кода — стыдно ведь выложить грязное решение на общий суд. Мне хотелось, чтобы мой вариант был максимально понятным и читаемым. Впоследствии я заметила, что стала переносить этот принцип и в рабочие задачи. А ещё – лучше объяснять свои решения коллегам.
Так как же улучшить навык чистого кода и объяснения решений, пользуясь LeetCode?
Не стесняйтесь публиковать свои решения, даже если они не уникальны (только сначала постарайтесь максимально почистить код);
Потренируйтесь писать объяснения своих решений. Постарайтесь формулировать их так, чтобы всё понял даже новичок;
Решив задачу, посмотрите решения, находящиеся в топе выложенных. Это позволит научиться не только новым подходам, но и тому, как качественно умеют преподнести своё видение проблемы некоторые разработчики.
5. Почва для искусства объяснения решений и чистого кода
В любом деле важна мотивация и регулярность, будь то вышивание, занятия спортом или решение алгоритмических задач. Если мотивация заниматься на LeetCode уже появилась – из-за желания получить работу мечты или из-за чего-то ещё — то дело остаётся за регулярностью.
Я сделала решение задач своей привычкой и твёрдо решила, что буду находить время для этого время каждый день – хотя бы по полчаса. Когда копится стрик на протяжении одного, двух, трёх месяцев, пропустить новый день становится уже обидно.
Будет легче, если решать задачи каждый день в одно и то же время. Я выбрала время утром перед работой, но кому-то удобнее заниматься вечером. При выборе важно учитывать свой уровень интеллектуальной активности в течение дня, у всех он разный.
Несколько советов, чтобы сохранять мотивацию для достижения регулярности (без неё никуда):
Не пытайтесь каждый день решать много сложных задач, вы просто быстро выгорите. Постепенно увеличивайте сложность и уделяйте задачам определенное время (например, сорок минут в день);
Отслеживайте свой прогресс. Вы можете вести календарь и отмечать каждый день, когда садились за решение задач. Когда мотивация угасает, посмотрите, как далеко вы уже продвинулись;
Никогда не сравнивайте себя с другими. Чье-то опубликованное решение может выглядеть намного лучше вашего, но как узнать, сколько лет этот программист потратил на изучение алгоритмов?
Ежедневно хвалите себя: как только вы начинаете день, вы уже начинаете знать немного больше, чем вчера.
Подводя итоги. Чему же я всё-таки научилась?
За год на LeetCode я поняла, что алгоритмические задачи – не панацея, но отличные помощники. Они способны привить автоматизм при написании рутинного кода, убрать страх трудностей, приучить думать о разных тестовых сценариях. Публикация решений, с учётом старания сделать их чистыми и детальными, позволяет прокачать навык объяснения своего кода.
И даже если вы не стремитесь на собеседование лайвкодингом, самодисциплина, прокачанная в процессе регулярного решения задач, поможет в любой работе.
Всё ещё сомневаетесь? Просто попробуйте решить первую задачу сегодня.
Комментарии (81)
gandjustas
14.07.2023 11:09+30Решение абсолютно любых задач постоянно возрастающей сложности в течение года приведет к тем же результатам.
Правда на работе можно 10 лет перекладывать json и фактически ничему не научиться.
SerJook
14.07.2023 11:09+21Зачем мне нужен LeetCode, если я каждый день гоняю джейсоны туда-сюда?
tandzan
14.07.2023 11:09+13Потому что HR важно, чтобы кандидат знал деревья
чему их учат на курсах
Politura
14.07.2023 11:09В литкодовских задачках встречаются только обычные бинарные деревья, больше ничего из той картинки там нет.
vmarunin
14.07.2023 11:09Нет. Есть немного задач, где обычных бинарных не хватает.
Есть на Фенвика, который пишется слёту. Но штук 10-15 я решал именно красно-чёрными. В язык Go поставлена внешняя либа с деревьями. И в Python подтянута внешняя либа с хитрой структурой (которая в каком-то смысле эквивалент сбалансированных деревьев)
SiGGthror
14.07.2023 11:09+11Defined behavior - это поведение которое не определено в спецификации. Интересные курсы
Leetc0deMonkey
14.07.2023 11:09+4Представьте сколько годных программистов было отсеяно. И сколько чудаков прошли на следующий этап. На котором тимлиды бы стонали "ах как мало толковых".
yeputons
14.07.2023 11:09Может быть весело и интересно. А ещё это один из способов потренировать умение видеть крайние случаи.
acordell
14.07.2023 11:09+3За LeetCode не скажу, а вот на Codeforces, где, бывало, сиживал вечерами, красивый и чистый код не в почете. Только хардкор по скорости и краткости.
Leetc0deMonkey
14.07.2023 11:09+6Если на работе работать, то все 5 пунктов прокачиваются и без литкода.
iuabtw
14.07.2023 11:09+151) Ник в тему
2) Ну повезло Вам с работой. Я пару лет провёл на легаси-дрочильне, где вся прокачка была только в умении "взять побольше да кинуть подальше". И платили не плохо, даже временами было стыдно, что я такой фигнёй занимаюсь за такие деньги.
panzerfaust
14.07.2023 11:09+3Работа не этническая принадлежность. Ее выбирают. Я сейчас не конкретно про вас, но киснуть на легаси-дрочильне, а потом идти на литкод и "прокачиваться" там - это какая-то логика наизнанку. Лучше напрячься и попасть на проект, где реально приходится ломать голову, как линейную сложность превратить в константную, а не синтетикой на литкоде заниматься.
iuabtw
14.07.2023 11:09+11Я вижу тут замкнутый круг - чтобы попасть на сложный проект, надо пройти сложный литкод-собес, а где опыт алгоритмов взять, кроме синтетики?
Ту работу я выбрал сам, по задачам она устраивала примерно полгода, а дальше покатилось. Можно ли позволить себе менять работу каждые полгода? Ответ, по-моему, очевиден - нет, потому что в какой-то момент резюме начнёт летать в мусорку с первого взгляда HR.
Я для себя нашёл на литкоде неплохие карточки с разбором алгоритмов по темам, плюс практику. Узнал всякого нового, думаю, поможет в будущем. Я не считаю, что пройдя весь литкод на 100% я стану лучшим погромистом в мире, но это неплохой вариант обучения.
Politura
14.07.2023 11:09+5Зачем менять работу, если она нравится? Это как человеку, который ходит в спортзал три раза в неделю посоветовать сменить работу на работу тренером, только потому-что ему нравится там заниматься.
Работа может быть интересной архитектурными задачами, которые приходится решать и получать удовольствие. Литкод же - про алгоритмические задачи, как головоломки, и точно также получаешь удовольствие если наконец-то решил какую-то сложную задачку. Но типы задач сильно разные.
ninaTorgunakova Автор
14.07.2023 11:09Работа может быть интересной архитектурными задачами, которые приходится решать и получать удовольствие. Литкод же - про алгоритмические задачи, как головоломки, и точно также получаешь удовольствие если наконец-то решил какую-то сложную задачку. Но типы задач сильно разные.
Всё так, подписываюсь под вашими словами
Leetc0deMonkey
14.07.2023 11:09+51) Ник в тему
Да. Вопреки мнению в статье, в западном (американском) айти распространено и прямо противоположное отношение к литкодрочерам: непосредственно в разработке абсолютно бесполезная публика.
iuabtw
14.07.2023 11:09+1Это мнение и у нас распространено, много кто хейтит программистов-олимпиадников.
Politura
14.07.2023 11:09+1Первый пункт, по сравнению с литкодом, будет на порядки медленнее прокачиваться. Нужно сделать ошибку, которую не выявят тесты, которые сам-же и написал, потом дождаться, пока она вслывет на проде и еще не факт, что именно тебе достанется тикет на исправление. Короче, никакой обратной связи, либо она есть с сильной задержкой. На литкоде же в тестах как-правило будут крайние случаи, и нажав кнопку проверки сразу получишь обратную связь.
Firz
14.07.2023 11:09+2Алгоритмические задачи с Литкода
Ожидание: супер сложные алгоритмы, решающие проблемы мироздания
Реальность: https://leetcode.com/problems/add-two-integers/p.s. Ну ладно, кто-то непонятно зачем закинул это туда, но самое страшное вот это:
Acceptance Rate 87.8%iuabtw
14.07.2023 11:09+3На литкоде сидят не только суровые сеньор-джсон господа, поэтому есть совсем никакие задачи. Также там есть обучающие материалы, в целом подходящие для вкатывания в алгоритмы с ноля.
По поводу Acceptance Rate - это любители нажать submit до того, как проверили все случаи через run.
Firz
14.07.2023 11:09+2По поводу Acceptance Rate — это любители нажать submit до того, как проверили все случаи через run.
В контексте этой конкретной задачи, мне кажется, это любители нажать submit до того как вообще что-то напишут)
Rollant
14.07.2023 11:09+3Или любители повыпендриваться, как здесь: https://leetcode.com/problems/add-two-integers/solutions/1968134/21-different-ways-to-solve-this-problem/
Mapaxa864
14.07.2023 11:09Да можно просто случайно опечататься и написать = вместо +, не заметя, что шифт не отработал например :)
serge-sb
14.07.2023 11:09+2Смех смехом, но переполнение при сложении двух знаковых целых чисел - это UB. @xortator, если я слишком паранойю, поправьте меня. Ваша статья здорово мне вынесла мозг)
multiprogramm
14.07.2023 11:09Там в условии:
-100 <= num1, num2 <= 100
С другой стороны, конечно, если int размером в байт, то можно и UB.
orenty7
14.07.2023 11:09Низя инт размером с байт, по стандарту он должен хранить числа от -(2^15 - 1) до +(2^15 - 1)
Leetc0deMonkey
14.07.2023 11:09В ЦПП единственное требование к инту это не быть меньше шорта. А у оного не меньше байта (чара).
yeputons
14.07.2023 11:09+1Неверно, это не единственное требование: https://eel.is/c++draft/basic.fundamental#4
Firsto
14.07.2023 11:09Ну вот вам следующий уровень, без операторов "+" и "-": https://leetcode.com/problems/sum-of-two-integers/ :)
ilya-chumakov
14.07.2023 11:09+2Это буквально первая задача из гайда литкода для абсолютных начинающих. Своеобразный hello world. Попробуйте задачи уровня Hard.
nameless323
14.07.2023 11:09+1Ну на самом деле даже на олимпиадах где я участвовал (лет 15 назад хехе), были подобные задачи, они были за день до олимпиады, чтобы проверить среду, что все настроено нормально, что все сабмитится. Ну и заодно разные задачи можно решать очень разными способами, даже есть задачи hard которые очень легко решаются в лоб и литкод их пропускает, а вот оптимальные решения уже интересные и догадаться до них очень не просто.
iboltaev
14.07.2023 11:09+5Везет человеку с мотивацией. Меня за 2.5 года только на 120 задач хватило (80 мидях). Ненавижу их решать. Вроде ведь и получается, где-то 5-8 мидях за день могу решить, несколько дней порешаю - и полгода отходняк, а то и год. Вроде и понимаю, что надо, а не могу себя заставить. Треш какой-то.
Dolios
14.07.2023 11:09Если вам это не нравится, но вы считаете, что вам это надо, на хабре была хорошая статья.
Leetc0deMonkey
14.07.2023 11:09+7Ненавижу их решать. Вроде ведь и получается
Strong hire! Мозг кандидата, настроенного на решение реальных проблем бизнеса, всегда будет сопротивляться всякой херне типа литкода.
iboltaev
14.07.2023 11:09+1если бы еще бизнес думал так же) все же большое количество контор считают, что им нужны алгоритмически подкованные люди. Я и сам считаю, что алгоритмическая подготовка - это must have, насмотрелся и нафиксился случаев, когда вектор вместо мапы/сета, односвязный immutable список копируют за O(N^2) на ровном месте, компоненты связности самописные и за квадрат, parquet-файл с сервера отдают постранично, каждый раз перечитывая его с начала (итого - квадратичная сложность, ну а чо такого), ну и так далее. Как бы реальные проблемы бизнеса вроде как решены, но сильно через одно место. Но у меня какой-то внутренний протест против именно задрачивания.
Leetc0deMonkey
14.07.2023 11:09+2И я тоже насмотрелся как на фронтенде иммитируют работу СУБД и помпезно решают задачи которые там попросту не должны появляться.
Если у вас вектор таких размеров что нужна мапа "для скорости", есть вероятность вы занимаетесь хернёй типа выгребания raw данных из базы и ручной их обработкой.
qw1
14.07.2023 11:09На типичных страницах со срачами столько комментов, что квадратичный алгоритм по ним покажет заметную нагрузку на CPU в браузере.
Leetc0deMonkey
14.07.2023 11:09В первую очередь, мне их зачем-то все загрузят. Будто я собираюсь их все до единого прочитать.
qw1
14.07.2023 11:09Я до сих пор пользуюсь "старой версией" Хабра, где все комменты грузятся сразу на одну страницу. Это банально удобнее:
- работает поиск
- можно проскипать пару неинтересных веток, цепляясь глазами за ключевые слова
- если вырубится сеть, можно спокойно дочитать.
DarthVictor
14.07.2023 11:09+2Я – фронтенд-разработчик, и за последний год встречалась с необходимостью использовать нетривиальные алгоритмы несколько раз. Наиболее сложные случаи были связаны с визуализацией графов.
У фронтендеров слегка отличаются задачи от типичного leetcode / codewars и прочих. При чем и по реальной работе и по вопросам на собеседованиях. Фронтам не особо нужны задачи на динамическое программирование или backtracking, но зато нужно больше задач на обход деревьев и задачи на асинхронность. Особенно на асинхронность. На литкод недавно даже отдельный блок с JavaScript добавили. Также рекомендую https://bigfrontend.dev/
MiraclePtr
14.07.2023 11:09Как правило, в обычной рабочей атмосфере нам не высвечиваются слова «Wrong Answer», когда мы допустили ошибку — это всплывает позднее в виде бага у клиента.
Если у них в компании реально всё устроено как "херак-херак-и-в-продакшн", то прям сочувствую. У меня вот, например, первый "wrong answer" выдает IDE по результатам проверки типов, работы линтера и статического анализатора, потом юнит-тесты, потом интеграционные и ручные тесты (которые пишет другая команда, что в избежать замыливания взгляда разработчика). Все ради того, чтобы оно не долетело в виде багов к клиентам.
Я не ожидала этого, но с приятным удивлением заметила через полгода: у меня стало уходить примерно в 1.5 раза меньше времени на задачу по сравнению с тем, когда я начинала.
А авторка точно уверена, что это произошло благодаря литкода, а не благодаря тому, что она в течении этих полугода на работе каждый день решала реальные рабочие задачи?
ninaTorgunakova Автор
14.07.2023 11:09+1На моей текущей работе всё отлично со внимательностью к таким вещам, но до неё я повидала всякое (и наслышалась от знакомых тоже). Далеко не во всех местах реальной разработки всё так же хорошо, как у нас с вами сейчас.
Ну и плюс в тексте я упоминала это ближе к контексту, когда падает один крайний кейс из нескольких десятков. Даже с очень грамотно построенными процессами, от всех возможных багов на 1000% не застрахуешься наверняка, разное случается.А авторка точно уверена, что это произошло благодаря литкода, а не благодаря тому, что она в течении этих полугода на работе каждый день решала реальные рабочие задачи?
Уверена: на тот момент, когда я решала, моя работа была достаточно рутинной.
SiGGthror
14.07.2023 11:09+2Уверена: на тот момент, когда я решала, моя работа была достаточно рутинной.
Так это буквально и есть обучение - вы решали рутинные задачи и спустя какое-то время начали их выполнять быстрее.
Ascar
14.07.2023 11:09+2Лучше вечер потратить на прочтение полезной книжки про юнит тестирование например и багов станет меньше.
ninaTorgunakova Автор
14.07.2023 11:09+2Можно и нужно! Книжки и юнит тестирование — это прекрасно. Одно другому не мешает.
Ascar
14.07.2023 11:09+7Вообще то мешает, общий ресурс время.
ninaTorgunakova Автор
14.07.2023 11:09+2Вам виднее, на какие вещи тратить своё время. Я рассказала, по каким причинам решила тратить своё свободное на задачи, и развитие внимательности стало одной из них. Хорошо совместилось с навыком тестирования и улучшило качество самопроверки.
Ascar
14.07.2023 11:09+1Что за навык "тестирование"? Вы тестировщик? Программирование состоит не только из локальных алгоритмов. Большая часть времени это организация архитектуры, рефакторинг и здравые решения, на одной внимательности вы не выедете, если вдруг у вас получится спагетти код который будет без ошибок. Бинарный поиск или быстрая сортировка не скажут вам как сделать не спагетти.
Да и это банально не интересно набивать алгоритмы вместо изучения интересных и полезных кейсов. Очнитесь.
nameless323
14.07.2023 11:09+2Большая часть времени это организация архитектуры
Большая часть времени это у кого? Лично у меня организация архитектуры занимает меньшую часть, а большую алгоритмы, математика и всякие скорее лоу левел оптимизации. Те же алгоритмы это скорее для меня частные случаи интересных и полезных кейсов и мне интересно их изучать. Программирование большое и интересные и полезные кейсы для всех разные. Я например точно так же могу сказать "зачем тратить время на архитектуру приложений, хотя гораздо интереснее и полезнее потратить время на изучение процессорных и GPU архитектур, математику и алгоритмы (те же lock-free)".
Tsimur_S
14.07.2023 11:09+1Лучше вечер потратить на прочтение полезной книжки про юнит тестирование например и багов станет меньше.
Но и к офферу в FAANG не приблизит.
Zara6502
14.07.2023 11:09+6писал ранее - участь решать задачи вы приобретаете только один навык - умение решать задачи. для того чтобы эти решения перешли в что-то большее - нужно образование или определенные навыки с рождения (гены).
как хороший пример - зазубривание билетов при сдаче экзамена ПДД. Это абсолютно никак не помогает в изучении ПДД и тем более не дает никаких навыков вождения, если - про если я уже написал выше. У большинства никаких "если" в принципе нет. Поэтому подача таких ресурсов как панацеи это какая-то глупость.
Давайте посмотрим на мои 25 лет работы - я написал кучу кода на разных ЯП и ни разу в жизни не занимался чем-то что потребовало бы от меня знаний теории графов, деревьев или бинарных поисков, сортировок, поиска подстроки в строке и т.п. Если такие вещи и использовались, то как встроенный инструмент библиотечных функция ЯП. Причем то, чем я занимался в 1999 году вообще никак не пересекалось с работой в 2005 году и тем более сейчас. Опыт 1999 года мне совсем не пригождается сейчас. Несомненно есть люди, которые работают в определенном направлении и все эти задачки для них реальность, но из статей-то этого и не видно, всегда подача такая что без LeetCode ты вовсе не человек.
nameless323
14.07.2023 11:09Ну как минимум там хочешь-не хочешь познакомишься со структурами данных и попробуешь их, узнаешь что такое сложность алгоритма и почему она важна и так далее. Например я видел людей которые не знают чем std::vector реально от std::list или std::map от std::unordered_map, что в общем-то не лишние знания (хотя для этого можно по диагонали учебник алгоритмов прочитать, но кому-то формат литкода проще). И нарешивать тысячи заданий для этого не обязательно. Хотя имхо это вполне себе занятные тематические головоломки.
Zara6502
14.07.2023 11:09это вопрос самообразования. никто не сомневается что нужно читать, изучать, пробовать и т.п. а литкод только еще один из инструментов. я же конкретно указываю на аспект, где литкод подают (как и изучение алгоритмов) как всепоглощающую обязательность без вариантов).
как пример могу привести себя - если я просто прочитаю про std::vector но не буду им пользоваться, то я забуду про него через неделю, а через пол года, если появится задача где его нужно использовать, я опять окажусь в ситуации - не знаю, надо почитать, попробовать. То есть я никогда не покрываю знанием весь ЯП со всеми библиотеками. У меня есть пару знакомых, у которых феноменальная память и они всё держат в голове, они и пишут хорошо и зарабатывают много, но я не они. И я когда-то давно думал что я один такой, но позже узнал и других людей и много материалов почитал про память в целом и оказалось наоборот, что такой как я это и есть норма, а все кто лучше меня, вот такие они уродились молодцы.
nameless323
14.07.2023 11:09Ну я и не призываю именно сидеть и прорешивать, хотябы просто ознакомиться с алгоритмами и структурами данных (для кого-то формат литкода удобнее, для кого-то учебник). Просто если даже у вас память не очень, вы можете ознакомиться со структурами данных и посмотреть что из ни что в вашем языке и у вас есть все равно неплохой шанс когда вам нужен определенная структура вы можете вспомнить "ага, я помню что что-то когда-то читал, что конкретно было не помню, но надо пойти посмотреть данную тему", если никогда не читали, то и вспоминать нечего и есть вероятность выбрать плохую структуру/алгоритм потому что он работает, а о существовании аналогов не знаете. То есть не с целью вызубрить изучать, а просто ознакомиться по крайней мере с основными алгоритмами и структурами и их маппингом на контейнеры языка.
Хотя конечно надо учитывать что в принципе память у меня не плохая (по крайней мере на уровне "ага, я помню что то читал по теме, кажется в этой статье/книге, надо бы перечитать"), работа связана с математикой/алгоритмами/оптимизацией в основном и есть определенный биас по этой теме.
Zara6502
14.07.2023 11:09мысль понятна, но я не об этом. впрочем не важно.
когда вам нужен определенная структура вы можете вспомнить "ага, я помню что что-то когда-то читал
у меня это так не работает. я скорее всего даже не вспомню что вообще читал об этом.
если никогда не читали, то и вспоминать нечего
пока я с чем-то работаю почти каждый день, у меня это так и происходит - ага, я вчера что-то похожее делал, надо почитать СНОВА и вспомнить как это я делал. ВЧЕРА дружище, не месяц назад, а только вчера. Если я это читал прошлой осенью, то в лучшем случае я вспомню что читал что-то по C#, а что именно - никто не знает. Я IDE VS современный чем обожаю, так это подсказками по формату данных, я вижу что выше использовал например GetInteger, набираю, а он мне показывает как его оформлять, ибо я не помню. В общем всё очень сложно))))
вероятность выбрать плохую структуру/алгоритм потому что он работает, а о существовании аналогов не знаете
никогда в жизни такое не делал и никогда не знал о таком выборе и об альтернативных вариантах. как правило я пишу в гугле направление в котором хочу двигаться, нахожу варианты, читаю, изучаю, выбираю, если есть из чего. В основном пишу чтобы работало, а потом оптимизирую. Часто оптимизация равна написанию с нуля. Я пишу софт очень долго, поэтому в явном виде никогда в этом направлении не работал профессионально. По сути я пишу его в голове как некую структуру, а потом просто заворачиваю в код. Структуру конечно всегда привязываю к платформе, на которой это будет работать, например на старых системах это вопрос выбора аппаратных возможностей и ограничений например по памяти.
не с целью вызубрить изучать, а просто ознакомиться по крайней мере с основными алгоритмами и структурами и их маппингом на контейнеры языка.
когда я сравниваю ассемблерные команды MOS 6502, которых 200 штук всего и их документацию и MS .NET, который я вообще не знаю кто-то выучить весь способен? То я не представляю сколько нужно времени чтобы хотя бы ознакомиться с .NET, я уж молчу чтобы знать весь АП со всеми библиотеками и еще и профессионально им пользоваться. Я на 6502 пишу довольно часто и часто же читаю мануал по его инструкциям. Я конечно помню всякие BNE, STA, но я могу не помнить например работает ли команда только с регистром или можно передавать и адрес памяти. Полез в мануал, прочитал. Через неделю еще раз и т.д.
Поэтому что-то учить заранее не вижу смысла, тем более не ясно будешь ли этим вообще пользоваться, а некоторые вещи даже из примеров непонятно как использовать и зачем.
PS: есть такая штука как MSDN, думаете кто-то её знает наизусть? Не уверен что это возможно в принципе.
nameless323
14.07.2023 11:09Ну я в общем то не к тому что надо пытаться прочитать или выучить тот же MSDN, если попробовать прочитать и запомнить весь cppreference то можно в психбольнице оказаться нечаянно :) Я скорее про случаи что вам могут скорее всего пригодиться и более базовые - прочитать какие основные контейнеры есть и каким структурам данных соответствуют и какие основные алгоритмы в языке есть - сортировка например, поиск, да и наверное всё. В моем представлении это что-то вроде того как вы начинаете новый язык учить и смотрите как там циклы, условия работают, как функции объявлять и т.д. А вот как раз конкретику можно уже и гуглить каждый раз (условно хорошо знать что есть std::map и для чего сама структура подходит, а уж как конкретно из нее например удалять, да можно и загуглить когда надо, обычно тех же контейнеров в языке ну штук 10 наберется, реально полезных которых после прочтения в голове стоит оставить штук 5). Но это само собой личное ИМХО и на истину в последней инстанции не претендую, для каждого оптимальный вариант может быть свой.
olegkusov
14.07.2023 11:09+3Нужны нормальные исследования
Это может быть самовнушением. Корнер кейсы можно обдумывать и при TDD подходе.
heartdevil
14.07.2023 11:09+1Как по мне, алгоритмы и структуры данных -- это мат. часть, которую лучше знать, чем не знать. Вот до какой степени, зависит от ваших нужд. В таком изучении больше "системности" что-ли в знаниях.
Попробую привест три аналогии:
1) Можно научиться играть на гитаре не зная нот и вообще теории музыки. И многие так и поступают. Если эта глубина владения инструментом вас устраивает, то и не стоит дальше идти. В этом ничего плохого нет. А если захотите расширыть свои занния, то придется учить музыку. Будет ли это лучше, чем учиться сразу "правильно", сложный вопрос. Но по мне, скорее всего это хуже.
2) В шахматы тоже можно научиться хорошо играть просто начав играть. Если вас устраивает ваша игра в шахматы, то дальше что-то учить нет смысла. Но если хотите играть лучше, придется учить мат. часть. И опять же, будет ли такой подход лучше, тяжело судить
3) Иностранный язык. Можно бегло научиться говорить и писать, без особых знаний грамматики языка. Этого почти всегда достаточно для обширного числа работ на которые устраиваются люди. Но если возникает необходимость вести диалог в более формальной плоскости, сразу выявляются проблемы.
Суть в том, что хорошее знание мат. части в любой области никогда не навредит. Скорее всего, оно сделает вас только лучше.
Вы в любом случае решаете какие-то задачи на работе. Причем всегда. Явно или не явно вы пишете алгоритмы и используете стурктуры данных. Так вот вам предлагается тренажер, где вы можете прокачать этот навык да еще и мат. часть поднатаскать. Почему бы этим не воспользоваться?
squonk
Зашел на LeetCode: Kotlin 1.3.10 - за год ничего не изменилось
12rbah
Не использую котлин, но вряд ли для решения алгоритмических задач нужна актуальная версия языка или это не так?
Germanets
Тоже не использую Котлин, но понимаю, почему люди недовольны платформой, где последня версия языка - 4хлетней давности, при этом языку чуть больше 10 лет. Тем более что речь-то не проcто про написание валидного кода - там ещё и соревнование по затраченной памяти и скорости.
Norgorn
Но тогда понятно, ведь при обновлении версии пришлось бы выбросить все старые результаты? Как вариант, могли бы предоставить выбор - или стабильная версия, или последняя но вне зачёта (или в отдельный зачёт)
qw1
Там никто не считает секунды и байты, единственный критерий — прошло/не прошло.
Недовольство коментатора, как я понимаю, в том, что приходится себе наступать на горло и даунгрейдить привычный код, который пишешь на автомате, до версии, поддерживаемой сервисом. На работе уже давно пользуешься новым синтаксическим сахарком, а тут нельзя.
mello1984
Конечно, можно решать и на старой библиотеке, но в новых версиях добавлено очень много методов в стандартную библиотеку. Эти новые методы позволяют написать в 1 строчке то, для чего в старой либе нужно 2-3 и более строк. Но проблема ещё в том, что время введения функций ведь мало кто помнит, а в результате - ошибки компиляции и переписывание (да, со временем запомнится, но в целом это бесполезная информация). В результате - просто писать не очень приятно и уж лучше пайтон/джава...
0xd34df00d
Более того, там даже хаскеля до сих пор нет!
Inspector-Due
Более того, у Scala как-то странно считается время исполнения! 700 мс на очень маленьком тесте. (Ну и Scala 3 нет)
Но вообще очень жаль, что Haskell нет на большинстве подобных площадок. А если и есть (например, CodeForces или sort-me), то либо старая версия GHC (8.10.7), либо даже нет самых базовых вещей по типу
vector(приходится юзатьarray, а тут уже не получится воспользоваться AoS/SoA). С другой стороны CF и sort-me про спортивное программирование (бег в мешках?), а Haskell, как показывает практика, слабо для этого подходит.yeputons
Мне казалось, 700 мс — вполне типичное время запуска виртуальной машины с нуля и подгрузки всех классов.
Inspector-Due
orenty7
Codewars, сильно разнообразнее в плане языков: хаскель уже стабильный, агда в бете