Что не так в статьях «Что должен знать начинающий программист»

Рассказывает эксперт курса «Профессия веб-разработчик»университета digital-профессий Нетология,Ильназ Гильязов

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

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

Хочется задать следующий вопрос авторам этих списков: «Часто ли начинающему программисту дают задание:

• оптимизировать производительность или потребление памяти приложения или сервиса (ведь для этого изучаются алгоритмы и структуры данных);
• проектировать приложение или сервис, его части, или перепроектировать существующее (ведь для этого изучаются паттерны проектирования);
• реализовывать многопоточность?»

Редко когда ответ на этот вопрос будет положительным.

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

Если с первым пунктом всё более-менее понятно, то о втором нужно поговорить подробнее. Что это за «более важные знания и навыки»?

Ответ достаточно простой. Первое — знания о том, для каких целей создаётся приложение или сервис. Второе — знания о том, как приложение или сервис функционируют в Production-среде.

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

Критически важные навыки

Почему критически важно понимать цели и задачи приложения или сервиса?

Потому что почти никто не создаёт приложение или сервис ради красивого и правильного использования алгоритмов, структур данных и паттернов проектирования. Приложения и сервисы создаются для решения конкретных бизнес-задач. Самая банальная истина — если приложение или сервис не решает поставленных бизнес-задач, то красота кода и всё остальное значения не имеют.

Почему критически важно понимать, как приложение функционирует в Production-среде?

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

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

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

Всё как раз наоборот: только через приобретение смежных компетенций мы можем увеличивать скорость. Яркий тому пример — кроссфункциональные команды, пропагандируемые Agile и DevOps. При этом Agile и DevOps уже стали основными подходами к разработке приложений и сервисов.

Где и чему учиться

В части понимания бизнес-задач — читать блоги о программных продуктах и выступления на конференциях Яндекса, Mail.ru, Rambler’а и других компаний, где они рассказывают, какие новые функции они внедрили и почему (почта, такси, поиск, афиша, маркет и другие сервисы).

Чем хороши выступления докладчиков — чаще всего они строятся в формате, из которого чётко понятно, как решалась проблема:

1. Была конкретная проблема.
2. Выработали конкретные гипотезы по конкретным соображениям (включая то, какие гипотезы и почему).
3. Протестировали гипотезы (включая то, как тестировали).
4. Выбрали сработавшие гипотезы.
5. Внедрили и получили обратную связь.

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

В части функционирования в Production-среде поможет установка и настройка Linux (права, пользователи, процессы, сервисы Systemd и файерволы), Docker. Остальное зависит от типа разрабатываемого сервиса — для веб-сервисов чаще всего используется СУБД, reverse-proxy (nginx), системы кэширования.

После того, как научитесь настраивать вручную, необходимо смотреть в сторону автоматизации повторяющихся операций, таких как Configuration Management (например, Ansible) и Povisioning tool (например, Terraform).

Виртуальные серверы, на которых можно безопасно потренироваться, стоят от 150 рублей в месяц. Облачные сервисы различных уровней предоставляют ограниченный ресурсами бесплатный доступ (Heroku, Openshift), либо триальный период (AWS, Google Cloud Platform, Azure).