Вам «шашечки» или ехать? Разберем вопрос в контексте новичков в IT

Думаю многие встречали мем из серии «Чтобы войти в IT, нужно всего лишь…». Всего лишь что? Конечно, выучить язык программирования, алгоритмы, структуры данных, паттерны и принципы проектирования. Но правильный ли это ответ? В этой статье я хочу разобрать, почему перечисленные выше вещи правильнее будет назвать «шашечками», и затронуть тему того, а как же, все-таки, ехать?

Я далеко не первый человек, который затронул эту скандальную тему. И, зачастую, находится далеко не один комментатор, который на подобные статьи говорит "Ну да, давайте слушать какого-то *имя автора статьи/доклада/видео*, а не выдающихся специалистов из *ведущая IT компания*, которые говорят, что нужно учить паттерны и алгоритмы". Эта статья вряд ли станет исключением, но это не повод не говорить на эти скандальные темы)

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

Как уже, наверное, заметил читатель, я буду задавать вопросы и давать на них ответы. Притом важно рассказать в контексте чего я буду отвечать на эти вопросы. Я предлагаю рассмотреть ситуации с точки зрения становления Frontend разработчиком, однако весь материал статьи так же применим и к другим сферам разработки.

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

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

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

Так же я не стану затрагивать специфику разработки на исследовательских проектах, сконцентрировавшись на бизнес отрасли.

Теперь, когда все точки расставлены, перейдем к содержательной части статьи.

Разработчик занимается разработкой, это ни для кого не секрет. Но что мы подразумеваем под словом «разработка»? Согласно определению из wikipedia, разработка ПО — это деятельность по созданию нового программного обеспечения. «Создание» подразумевает некий процесс и, в случае с ПО, в него входит далеко не только написание кода. Рассмотрим простой пример — разработка лендинга.

Когда будущий Frontend разработчик только начинает свой путь становления, его первым «полноценным» проектом может стать как раз таки лендинг. Он изучает HTML, CSS, немного JS, вооружается редактором кода и начинает «разрабатывать». Итог — лендинг разработан, но почему такая работа никому не нужна? Потому что это был учебный проект? Нет. Потому что написать код это лишь отдельный этап создания ПО.

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

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

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

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

Думаю ни для кого не секрет, что главная цель бизнеса — это быть коммерчески успешными. В простом случае это подразумевает максимизацию доходов и минимизацию расходов, что позволяет получить бизнесу наибольшую прибыль. Пока разработчик пишет код, он тратит время, которое стоит денег. Когда же разработчик наконец решает задачу, бизнес может получить с этого пользу. Из этого следует такая закономерность:

Бизнес не хочет, чтобы разработчики просто писали код. Бизнесу важно, чтобы разработчики решали его задачи и проблемы.

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

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

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

Материалов разбирающих, что такое паттерны и принципы достаточно много. Причем часто в них говорят о так называемом чистом коде. Но помогает ли это в реальной разработке?

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

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

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

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

Тогда закономерно будет задать вопрос. Как новичок, не обладающий собственным опытом, может распознать эту некую типовую ситуацию на, возможно, не типовом проекте? А затем грамотно применить там необходимый «опыт», который к тому же был просто вычитан и запомнен из интернета? Никак. А если и сможет, то это было лишь везением.

Поговорим о паттернах

Давайте рассмотрим интересный паттерн Стратегия. Сам по себе паттерн покрывает достаточно простую и частую ситуацию в разработки, как подстановка поведения.

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

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

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

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

И наконец, на проекте сложилась ситуация, когда есть страница, которая не имеет футера, но при этом она не должна иметь крестика в углу экрана, да еще и отображаться должна вертикально.

На этом моменте в компонент Layout вносятся последние костыли с флагами и кучей проверок, после чего его записывают в технический долг, а новичок перестает спать ночами, зная что рано или поздно ему придется отрефакторить, а этот компонент используется в целых 100 местах в проекте.

Когда же все пошло не так? Тогда, когда новичок начал использовать Стратегию для поведений разной семантики. То есть, семантически на проекте оказалось два Layout. Вертикальная страница с опциональным футером и горизонтальная страница с заголовком и контентом, которую можно закрыть — карточка открытого товара.

Опытный программист в такой ситуации создал бы сразу два Layout: PageLayout и CardLayout, — и не попал бы в цепкие лапы технического долга, однако новичок недостаточно опытен, чтобы понимать, что Стратегию можно использовать лишь в семантически одинаковых поведениях, таких как onClick callback’и, которые описывают разные поведения, но при этом семантически всегда являются всего лишь реакцией на клик пользователя.

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

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

Возьмем, к примеру, SOLID. Простой принцип построенный вокруг одной идеи «Давайте писать расширяемый и поддерживаемый код». Статей и видео на эту тему очень много, так что не стану разбирать что означают отдельно взятые буквы. Но у большей части этих материалов обычно отсутствует важный пункт повествования.

А всегда ли нам нужен расширяемый и поддерживаемый код?

Обычно этот пункт прописывается в условном ТЗ на разработку ПО. А если такого пункта в ТЗ нет? Значит, наверное, «заказчик» забыл его добавить. Тогда «заказчик» должен заплатить за расширяемый и поддерживаемый код, даже если ему нужен был сайт, где по центру экрана располагается мем с котом, который он хочет скидывать в своих переписках.

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

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

По итогу, заказчик получает работу с ценником в 50 тысяч рублей, за которую он платить, конечно, же не хочет, но и разработчик не хочет получать за 2 месяца потраченного времени 300 рублей.

Обычно такое называется оверинженирингом, но можно ли ругать за это новичка? Вряд ли, ведь ему никто не объяснил, когда нужно писать расширяемый и поддерживаемый код. Притом «когда» тут подразумевает не только требование клиента, а так же и этап создания проекта, его потенциальные размеры, стратегия выхода на рынок, размер команды, ее компетенции и еще множество факторов.

Если коротко отвечать на вопрос о «шашечках»

Будет правильно сказать, что паттерны, принципы и еще много чего безусловно полезны в разработке, однако новички не в состоянии их грамотно применять. Не нужно обходить их стороной, но на начальном этапе развития специалиста достаточно будет рассмотреть эти темы обзорно. Потратить тонну времени на попытку разобраться и понять эти вещи, а затем все равно ошибиться в их применении, создав проблемы себе и команде, как минимум не эффективно. Цель новичка — стать разработчиком. Знание паттернов, принципов безусловно признак хорошего разработчика, но хорошим — разработчика делают не они.

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

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

Это могут быть Ваши собственные жизненные проблемы и задачи. Так же может быть полезно спросить своих друзей и знакомых, а чем Вы можете им помочь? Попробуйте написать и помочь с публикацией сайта визитки Вашему знакомому дизайнеру. Или же напишите скрипт для Excel Вашему знакомому менеджеру, чтобы упростить ему жизнь и сократить время решения типовой задачи подготовки отчета с 3 часов до 30 минут.

Даже в такой ситуации Ваше решение не факт, что будет использоваться из-за многих факторов, однако Вы получите опыт анализа проблемы, решения задачи в условиях ограничений, таких как ограничения технологий или понятности использования. Вряд ли Ваш знакомый примет скрипт на питоне, который нельзя запустить просто тыкнув на какой-нибудь exe файл) Самое главное в таких задачах доводить дело до конца, чтобы столкнуться с как можно большим количеством этапов создания ПО. А если Вам доведется еще и баги править после фидбека Вашего знакомого, то это точно станет для вас незаменимым опытом)

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

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

Разработка программного обеспечения — это интересная и сложная сфера, однако не стоит забывать, что эта сфера совсем не про написание кода, а про решение задач и проблем. На начальном этапе новичкам нужно научиться решать реальные задачи и проблемы и не придумывать ненужные сложности там, где это не требуется.

Если не понимать зачем применяется и используется та или иная технология, подход или принцип, то Вы рискуете не решить проблему, а лишь создать еще большие.

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

Так же как с «шашечками» в такси. Первоначальная задача такси — это довезти Вас из точки А в точку Б, то есть — ехать, однако хорошее такси вряд ли будет без «шашечек»)

Благодарю за уделенное на прочтение моей статьи время!