Путь к истинному мастерству: больше, чем просто инструменты

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

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

Не начинайте свой проект с выбора фреймворка

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

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

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

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

Быстрая разработка приложений не решает всех ваших проблем

В некоторых сообществах, таких как сообщество Laravel, поощряется быстрая разработка приложений. Они показывают примеры небольших команд или разработчиков-одиночек, зарабатывающих много денег. Заманчиво. Однако это не означает, что они создают высококачественное программное обеспечение. Обычно они жертвуют хорошей архитектурой, чтобы быстро начать свой бизнес. И, поскольку они индивидуальные разработчики, я их полностью понимаю. Для них это эффективно. Проблема в том, что они продвигают этот подход как правильный путь! Быть хорошим архитектором программного обеспечения — это не одно и то же. Важно помнить, что простое знание того, как программировать, не делает кого-то ведущим экспертом в отрасли. Как я уже говорил, любой может изучить основы веб-программирования всего за шесть месяцев.

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

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

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

Что еще?

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

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

А пока предлагаю вам прочитать Кричащую архитектуру Роберта С. Мартина (дяди Боба).

Спасибо за чтение! Если вам понравилась эта статья, дайте мне знать ваше мнение в разделе комментариев! Вы можете следить за мной на https://twitter.com/akmandev и https://www.linkedin.com/in/ozanakman. Я стараюсь регулярно делиться идеями по разработке программного обеспечения, которые помогут вам улучшить свои навыки и быть в курсе последних тенденций в отрасли. Я ценю вашу поддержку и надеюсь связаться с вами в ближайшее время!

Первоначально опубликовано на https://akman.hashnode.dev.