Тонкий баланс между требованиями проекта и профессиональным развитием

Вы бы выбрали технический стек в дополнение к своему резюме? Вы знаете кого-нибудь, кто перестраивает во имя профессионального развития?

Я спрашиваю, потому что в последнее время проводил много времени с Kubernetes, оркестратором контейнеров и крутым парнем в мире DevOps. Я давний поклонник контейнеризации (а кто нет), но Kubernetes - это значительный шаг вверх по лестнице сложности. И это сопровождается предупреждающими знаками - например, огромные компании с высокооплачиваемыми разработчиками, которые допустили базовые ошибки Kubernetes и причинили себе массу головной боли (см., Например, известные хаки в Tesla, Capital One и Авива). Другими словами, Kubernetes-land обещает большие преимущества, но также создает значительные препятствия.

Это достойно стека?

При оценке такой технологии, как Kubernetes, наиболее очевидный вопрос: «Принадлежит ли она к вашему стеку?» Тот же вопрос возникает, когда вы смотрите на облачные среды, такие как AWS и Azure. Или серверное программное обеспечение, такое как Nginx и MongoDB. Или фреймворки приложений, такие как React и Blazor. Вы уловили идею. В мире полно проблем и инструментов; наша задача как разработчиков - заставить их встретиться посередине.

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

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

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

Изобретая колесо для удовольствия и получения прибыли

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

Опытные разработчики знают, что все можно построить с помощью «классических» технологий, таких как стек LAMP и обычный JavaScript. Фактически, быстро развивающиеся фреймворки могут просто увеличить отток, потреблять больше ресурсов и замедлить вашу работу. Новые технологии полны новых головных болей, которые только и ждут, чтобы их открыли.

Но потом такое случается:

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

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

- таотау

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

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

Следуя за толпой или присоединяясь к сообществу?

В своей профессиональной жизни я стараюсь не усложнять. И при выборе технического стека есть много возможностей следовать заповеди программиста YAGNI (Вам это не понадобится) или столь же полезному ISW (It Still Works). Однако есть один нюанс.

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

Причины, подобные этим, означают, что не всегда нужно переусердствовать с новой блестящей вещью. Но что, если ваша потребность прогрессировать как программист перерастает вашу компанию или ваши контракты? В конце концов, вам, возможно, придется двигаться дальше. Но сначала поищите другие способы устранить пробелы и найдите время для работы с передовыми технологиями. Присоединяйтесь к сообществу, которое использует новые технологии из вашей области. Создайте хобби-проект. Еще лучше, внесите свой вклад в проект с открытым исходным кодом, где вам нужно будет применить новый материал к практической части живого программного обеспечения. В конце концов, вы найдете схему, которая переводит ваши существующие навыки разработчика - решение знакомых проблем - в аналогичные концепции в новой технологии. И если вас не отвлекает маркетинговая шумиха или вас берет на себя разработчик FOMO, это того стоит. От этого зависит ваш рост как разработчика.

Вы предпочитаете придерживаться проверенного факта или работать на переднем крае? Оставьте комментарий ниже, чтобы сообщить нам об этом! А чтобы получать рассылку раз в месяц с нашими лучшими техническими историями, подпишитесь на Информационный бюллетень Young Coder.