За время загрузки этой статьи на вашем устройстве были приняты тысячи вычислительных решений. В ходе них произошел процесс подключения к сайту, определение возможности обработки этим сайтом безопасного подключения и затем уже страница отобразилась согласно стандартам, гарантирующим единообразное представление на планшете, смартфоне или ПК. Система принятия всех этих решений разрабатывалась в течение тысяч часов, проведенных специалистами в университетах за определением веб-стандартов, после чего еще больше времени ушло на оттачивание языка, и лишь после разработчики использовали полученные инструменты для создания готовых продуктов.
Тем не менее для большинства людей ремесло разработчика ПО кажется чем-то чуть ли не магическим и совершенно абстрактным. Очень распространено предположение, что разработчики должны обладать увесистым интеллектом. То есть, если вы не пишете математические уравнения под Windows и не можете запомнить значение Пи до 40-й цифры, то будто и делать вам в этой области нечего. Многие считают, что разработчик сидит перед пятью-шестью экранами и непрерывно проматывает текст, внося доработки вплоть до полного завершения программы. На уровне воображения это кажется очень непростой задачей.
Я все это говорю, потому что когда-то и у меня были такие же ассоциации. Мне казалось, что разработка ПО является какой-то особенной задачей, подходящей только лучшим из лучших, людям, чей мозг обладал большей вычислительной мощью, чем мой. Однако примерно через десять лет я понял, что это далеко не всегда так. Иногда люди не дают себе даже шанса создать что-либо, так как просто сомневаются в собственной умственной компетентности.
Те, кто мог бы вполне написать небольшой скрипт или простенькое приложение, даже не пытаются, потому что воображают огромную сложность. Лично я считаю, что это ошибка.
Дело не только в интеллекте
Нельзя не согласиться, что в мире есть люди, которые умнее и меня, и вас. Это вполне нормально. Мы можем делать, что угодно, даже выполнять всевозможные упражнения по развитию мозга, но мы никогда не сможем симулировать в сознании космос и на основе этого представления выработать такие же сложные теории, как Стивен Хокинг. Интеллектуальные возможности относительны и на шкале умственного развития мы, как правило, находимся где-то между ниже среднего и выше среднего уровней.
А к какой части этой шкалы мы отнесем разработчиков ПО? Может стоит отнести их к верхнему сегменту, ведь они генерируют сложные теории и код? На основе опыта могу сказать, что нет. Я работаю со множеством разработчиков, и несмотря на то, что среди них есть один, которого можно назвать исключительно умным, все остальные такие же как вы и я. Основное отличие в том, что они поистине заинтересованы в сфере создания ПО.
В воображении многих разработчик — это сидящий в темной комнате перед множеством экранов человек, неустанно пишущий приложения. На деле ПО создается совсем иначе.
Так как же на самом деле работают разработчики?
Они общаются с людьми
Прежде чем начать даже думать о создании приложения, разработчик должен получить некую его концепцию извне. Согласен, есть ситуации, когда программисты работают над собственными идеями, но в большинстве случаев доход поступает именно от работы на кого-то. И здесь есть исключения, например Марк Цукерберг, который задумал идею и затем ее реализовал. Но это просто исключение, таких немного. Как правило, зарабатывают программисты, трудясь на компанию, чье приложение или ПО требует постоянного обслуживания или развития. Поэтому изначально разработчику нужно объяснить замысел приложения и донести, что от него требуется.
В этом случае важно, чтобы исполнитель обладал определенным навыком коммуникации. Ведь когда кто-то описывает свой замысел и желания, пусть даже на высоком уровне, нужно суметь определить все сопутствующие сложности. Иногда заказчики будут просить от вас просто невозможные вещи или требовать реализовать нечто намного более сложное, чем предполагаемая ценность готового продукта. В таких ситуациях нам необходимо уметь объяснить заказчику все сложности и попутно выявить те моменты, с которыми мы не знакомы.
Что я хочу этим сказать? Давайте представим, что разработчик подрядился создать для заказчика приложение “Кошачья фотогалерея”, которое позволит просматривать фотографии кошек. В этом приложении пользователь может двойным нажатием добавлять изображения животных в избранное, делать сортировку по породам и т.д.
Даже в настолько простом приложении разработчик не способен знать наперед о запросах, которые заказчик может внести в любой момент. Попытка предугадать окажется бессмысленной. Более удачной идеей будет обозначить пределы своих возможностей, понимать возможные затруднения и предполагать необходимое на их решение время. При этом вы также будете получать обратную связь от заказчика или коллег, которая поможет оценить успешность ваших проектных решений и другие аспекты.
Суть в том, что разработчикам необходимо общаться с людьми — мы не можем просто реализовывать нечто согласно только нашему видению, ведь с идеей заказчика оно может не совпасть. Если что-то оказывается невозможным, то обязательно нужно сообщить об этом с предложением более оптимального решения или отказа от реализации.
Нужно понимать, что вы будете работать не в замкнутом подвальном помещении, строча код и постепенно заполняя окружающее пространство коробками от пиццы и стаканами из-под капучино. Создание приложения — это комбинация ваших возможностей и общего видения компании. В этом есть социальный аспект. Я не говорю, что нужно читать заказчикам стихи и выступать профессиональным оратором, но имею в виду, что желательно выглядеть респектабельно и стараться прислушиваться к их требованиям. И это является на удивление существенной частью деятельности разработчика — в конце концов, если бы вы являлись крутым специалистом, но при этом не могли понять требований заказчика, то насколько успешен бы оказался такой проект?
Заинтересованность
Нам нужна возможность общаться с людьми, чтобы понимать их желания и то, как воплотить эти желания в жизнь. Когда же дело доходит до самой реализации, то есть фактического написания кода, именно тут люди и пугаются, потому что все им кажется чрезвычайно сложным. Но что на этой стадии в реальности делает разработчик?
На деле он просто выполняет квест по решению задачи. В нашем примере задача гласит “нужно реализовать для пользователей возможность просматривать фотографии кошек на смартфонах и отмечать самые классные”. В этом описании на верхнем уровне можно начать разделять логические компоненты, которые в итоге и составят приложение. Здесь нам нужно ответить на несколько вопросов:
- Как пользователи будут регистрироваться в приложении и входить в него?
- Как будет выглядеть их “кошачья лента”?
- Как будет работать механизм добавления в избранное (двойное нажатие? А может произнесение мяу в телефон?)
- Где будет храниться база избранных изображений?
Здесь-то и начинается самое интересное. Конечно же, кто-то может додуматься просто сидеть и реализовывать перечисленные пункты один за другим. Но, если вы заинтересованы в эстетичности проекта и хотите не просто описать, как нажимать на экран для добавления в избранное, но в то же время учесть удобство для пользователя, то делать это будете с удовольствием и более эффективно.
Лично я считаю, что интерес является наиболее важным аспектом деятельности разработчика. Если вас не интересует то, как все работает, или как достичь наилучшего результата, то на такой работе вы перегорите, так ничего и не добившись. Иногда это приводит к мыслям типа: “Должен быть способ автоматизировать эту задачу”, после чего прорабатываются необходимые шаги и пишется простой скрипт. Не особый интеллект дает вам возможность написать свои первые несколько строчек на Powershell или VBScript, а интерес. Интересно ли вам узнать, из чего получается приложение для смартфона, или о том, как автоматизировать какую-либо работу? Человек с большим интересом всегда будет опережать человека с большим интеллектом. Это факт.
Именно он лег в основу моей карьеры как программиста. Я начал с автоматизации задач посредством простых скриптов, потом перешел к использованию более мощного набора для автоматизации AutoIT3, после чего начал работать в Visual Basic.NET. Далее я начал изучать C#. Все, что я делал и создавал подпитывалось простой мыслью “А как можно сделать X?”, после чего я находил способы применить полученное знание. Не будь во мне такого любопытства, я бы так никогда и не пошел по пути разработчика.
Это творческий процесс
К творческим занятиям обычно относят, что-то вроде написания книг или рисование. Это так и есть, но многих удивит, что и процесс разработки тоже является творчеством. Я вот не очень хорош в рисовании, но при этом много времени провожу за цветовым оформлением приложений, придавая им красивый вид. Это не то же самое, что нарисовать прекрасный закат, но в данном процессе определенно присутствует художественный элемент. И точно также как в рисовании, первые несколько создаваемых вами приложений или функций могут выглядеть несколько угловатыми и несуразными, но со временем результат будет улучшаться.
Идеальным можно назвать разработчика, который обладает навыками коммуникации, креативен и заинтересован в решении задач. Может показаться, что я усложнил понятие идеальный разработчик, включив креативность и общительность, но суть здесь в том, что дело не только в интеллекте.
Решение логических задач
Когда люди думают о приложении или другой предстоящей задаче, то рассматривают его как законченный концепт. Никто не описывает приложение с недоработанной орфографией и временной графикой, всегда представляется готовый продукт. Именно так и определяются цели, потому что люди обычно знают, что хотят получить.
В нашем примере это выглядело бы так: “Мы хотим приложение, в котором пользователи могли бы просматривать фотографии кошек и нажимать на них для добавления в избранное”. Это приблизительная готовая идея для приложения. Разработчик берет эту приблизительную идею и начинает собирать ее воедино, почти что как паззл.
Давайте здесь немножко поразмыслим над тем, какие компоненты могли бы понадобиться в нашем кошачьем приложении. Нам нужен способ получать список фотографий кошек из онлайн-источника, затем сохранять их в приложении. Возможность скачивать файлы реализуется в любом языке или фреймворке и сложностей вызвать не должна.
Но как сохранить метаданные этих приложений о количестве их лайков и информацией о том, кто именно поставил лайк? Для этого можно использовать простую базу данных. Раньше использование БД для хранения подобной информации могло вызывать трудности, но все стало намного проще с изобретением баз данных, наподобие NoSQL. Ответив на два поставленных вопроса, мы получим два компонента для приложения — способ скачивать фотографии с возможностью ставить для них лайки и способ сохранения этих данных. Но теперь перед нами возникает еще больше вопросов, например, как пользователи будут авторизовываться в приложении? Как они смогут делиться фотографиями с друзьями, отправляя им ссылки? Когда мы ответим на эти вопросы, реализовав подходящие решения, список компонентов приложения расширится.
Позже все заготовленные компоненты вы объединяете воедино. На ранних стадиях разработки приложения многие его части могут быть просто временными заменителями или так называемыми плейсхолдерами. Позднее, определившись с дизайном, и решив, как именно реализовать все эти возможности, вы замените их на постоянные. Когда вы только начинаете или просто создаете приложение для себя, можете затрачивать на проработку каждой реализации любое количество времени, Код не гниет и не стареет — он всегда сохраняет тот вид, в каком вы его последний раз оставили.
Здесь стоит отметить, что иногда, решая некоторую серьезную проблему или реализуя сложную функцию, у нас опускаются руки. Причина в том, что затрачивается через чур много усилий для достижения конкретной задачи. Когда вы зацикливаетесь на одной проблеме достаточно долго, она начинает утомлять. К счастью, обычно существует несколько способов решения задачи. Если вы окончательно застряли, то просто попробуйте подойти с другого угла. К тому же, нам свойственно хорошо запоминать сложные проблемы, и в дальнейшем они решаются куда быстрее.
Лучшее время — сейчас
Когда я только начинал заниматься разработкой ПО, соответствующие инструменты стоили очень дорого. Для Visual Studio была доступна только платная версия или урезанная Express. Стоимость платного варианта приближалась аж к $800 AUD, и это нужно было заплатить еще до того, как вы начнете создавать, что-то, что потом можно будет продать. Поэтому в качестве хобби такой вариант практически не рассматривался. Помимо этого, далее нужно было заплатить за лицензии других частей экосистемы, таких как сервера баз данных, фреймворки для создания приложений и прочее.
Сегодня же мы наблюдаем совершенно иную среду. Версия Visual Studio для сообщества бесплатна и снабжена тем же набором возможностей, что и Visual Studio Pro, только без бирки с ценником $800. Перед нами есть выбор бесплатных фреймворков: React Native, Xamarim, Flutter, … . При этом между собой мы сейчас связаны как никогда лучше — люди предлагают помощь и делятся возможными решениями в онлайн-чатах, таких как Slack и Discord, не говоря уже о Stack Overflow.
Так что, если вы задумали окунуться в эту сферу, то сейчас для этого самое подходящее время. Начните с малого — если у вас есть монотонная задача, почему бы не попробовать ее автоматизировать?
В настоящее время мы работаем по принципу взаимного диалога и предлагаем клиентам наилучшие продукты. Мы делаем это сегодня и с тем же успехом будем создавать приложения будущего.
Но, как и в любом деле, откуда-то нужно было начать. В определенный момент все мы знали о разработке ПО столько же, сколько сейчас знаете вы. В вашем случае началом может стать простой поиск возможного решения по автоматизации задачи или выяснение, как можно создать простое приложение для смартфона. А вот конечная точка пути станет известна лишь позже. Вполне может быть, что вы станете преуспевающим разработчиком ПО.
Читайте также:
- 6 ответов на вопрос: «почему читать код важнее, чем писать?»
- 5 эффективных Unix-команд для устранения неполадок
- Декларативный код против императивного
Читайте нас в Telegram, VK и Яндекс.Дзен
Перевод статьи Lew C: Anyone Can Be A Software Developer — It’s Not Magic
