Мы застреваем в тупике, в версии разработчика, и иногда мы не знаем, как выбраться. Вот четыре идеи о том, что вы можете сделать, чтобы попытаться выйти и развиваться как разработчик.
Мы, как разработчики, так и люди, всегда должны стремиться учиться и расти. Благодаря самопознанию и самомотивации мы можем научиться быть лучшими людьми и лучшими профессионалами. Расширяя наши области знаний, мы открываем для себя новые идеи, новые мировоззрения, новые вызовы и новые вопросы, на которые нужно ответить. В этом духе я составил небольшой список вещей, которые могут стать хорошей темой для вашей следующей кроличьей норы в 2 часа ночи или для самостоятельного обучения.
Многопоточность в Python
Если вы разработчик Python, вам обязательно нужно научиться многопоточности. «Но разве в Python нет GIL, поэтому многопоточность в принципе бесполезна?» Я слышал, вы спросите. Ну нет, это совсем не так. Фактически, есть несколько сценариев, в которых использование потоковой передачи в Python чрезвычайно полезно. Хорошее практическое правило состоит в том, что если ваше приложение ожидает на каких-либо ресурсах медленнее, чем диск, вы можете использовать потоки для распараллеливания операций. Хороший пример из реальной жизни - это времена OpenStack Havana.
Компания, в которой я работал в то время, имела массовое развертывание OpenStack в нескольких центрах обработки данных, и, учитывая, что нашему приложению требовалась географическая избыточность, у нас были экземпляры в нескольких регионах, с несколькими средами для каждого региона. Это вызвало небольшую головную боль при проведении инвентаризации всех наших виртуальных машин, так как на панели управления не было возможности увидеть на 1000 футов все, что связано с нашей организацией. Помня об этой проблеме, я создал приложение Flask, которое обращалось к API OpenStack и получало список экземпляров для каждого региона и среды, в которых мы находились, а затем обновлял гигантскую таблицу на базовой веб-странице. Всего у нас было около 9 или 10 вызовов API, которые должны были произойти, чтобы получить полный список экземпляров. Мой первый черновик приложения занял целую минуту или две, чтобы заполнить список, причем все вызовы API выполнялись последовательно. Хотя это сработало, пользовательский опыт был не самым лучшим: сидеть и ждать, пока страница загрузится более минуты, - это хороший способ скучать и расстраиваться. Поэтому я вернулся и переделал приложение для использования потоковой передачи. Поскольку большая часть задержки связана с сетевым вводом-выводом, приложение фактически проводит большую часть своего времени в режиме ожидания, ожидая сетевых ответов. Я мог бы использовать это время простоя, выполняя все вызовы API параллельно, позволяя ядру планировать потоки и использовать как можно больше времени простоя. Это позволяло приложению получать список экземпляров от одной-двух минут до нескольких секунд. При правильном приложении и сценарии использования многопоточность в Python может стать мощным инструментом.
Учите противоположный язык
Я вырос как парень из Python. Это был первый язык, который я по-настоящему выучил (в прошлом я взломал несколько браузерных JS, но это не в счет), и это все еще моя первая любовь. Но несколько лет назад меня побудили изучить го, и я очень рад, что я это сделал. Не потому, что Go - лучший язык в мире - далеко не так, - а потому, что переход от одной парадигмы к совершенно другой парадигме позволил мне по-другому думать о коде и дал мне еще один инструмент в моем наборе инструментов для решения проблем. Поэтому, когда я говорю изучать «противоположный» язык, я имею в виду вот что: если ваш основной язык - это интерпретируемый язык с утиной типизацией, такой как Python, противоположным языком будет что-то вроде Go или C ++ - скомпилированный, статически типизированный язык, который заставляет вас больше сосредоточиться на управлении ресурсами, чем на Python или Ruby. Если вы в основном Java-разработчик, я настоятельно рекомендую вам изучить что-то вроде Haskell или Elixir, что-то, что выводит вас из зоны комфорта в ментальное пространство, в котором вы не привыкли работать.
Еще раз изучить стандартную библиотеку
Это может показаться немного безумным, но выслушайте меня. Как и во многих вещах, люди попадают в ритмы, они находят то, что им нравится и что работает, и используют эту вещь или этот метод в качестве основного. Это не плохо и не хорошо, это просто то, что есть. Однако одним из побочных эффектов этого является то, что мы иногда отказываемся от лучшего решения в пользу того, которое мы знаем. Чтобы бороться с этим, я бы посоветовал вам заново изучить стандартную библиотеку вашего языка. Это не то, что люди обычно делают после того, как выучили язык, но вам обязательно нужно вернуться и проверить его снова. Уже выучив язык, могут быть некоторые пакеты или концепции, которые вы не понимали полностью на первый взгляд, но теперь имеете контекст. Несколько раз я сталкивался с определенной проблемой, которую я не совсем понимаю, как решить, и, решив вернуться и просмотреть stdlib Go, я смог найти гораздо более простой способ решения эта проблема. Или иногда это не конкретная инженерная проблема, а скорее расплывчатое «Интересно, можете ли вы сделать ______…», которое спровоцировало глубокое погружение в stdlib.
Попробуйте заново реализовать то, что уже существует
Иногда вам становится скучно, иногда вы застреваете в колее. Ничего страшного, бывает. Когда это происходит, мне нравится пытаться заново реализовать какую-нибудь известную функцию или алгоритм. В последний раз, когда я делал это, я пытался воссоздать алгоритм пузырьковой сортировки в Go. Я добился успеха? В конце концов. Было ли это эффектно? Абсолютно нет, но цель упражнения заключалась не в этом. Так в чем суть? Чтобы выйти из своего обычного ритма и сделать то, чего я никогда раньше не делал. В этом списке вы можете почувствовать какую-то тему, но выход за пределы вашей обычной сферы влияния всегда является хорошей идеей и может привести к важным открытиям. В данном случае люди вроде Кен Томпсон намного умнее меня, но второстепенным было то, что независимо от вашей первой попытки что-то сделать, всегда есть место для оптимизации и улучшения.
Вывод
Быть разработчиком может быть стрессовой работой и отнимающим много времени хобби, но это не значит, что это должно быть скучно. Всегда есть чему поучиться, области, которые нужно понять лучше, и идеи, которые нужно преобразовать из концепции в реальность. Это всего четыре способа помочь вырваться из цикла повторений, но есть и другие. Есть ли у вас любимая? Я хотел бы это услышать, дайте мне знать в комментариях ниже!
