Мысли вслух

Что лучше для web-приложений - монолит или микросервисы? Многие ответят на этот вопрос, что, мол, все инструменты хороши, если их использовать по назначению. В таком случае у меня, как у человека, в силу своего возраста, довольно консервативного и неохотно воспринимающего непроверенные временем концепции, возникает другой вопрос - а чем хорош монолит? Где его ниша? Стоит ли переключаться на микросервисы или монолит ещё не изжил себя и на мой век хватит?

В фокусе моих интересов не гигантские web-приложения типа Gmail, Facebook, Twitter, а web-приложения, созданные на базе таких платформ, как Wordpress, Drupal, Joomla, Django, Magento и им подобным. Под катом мои субъективные мысли на этот счёт. Ничего нового - всё те же 33 буквы кириллицы и 26 букв латиницы вперемешку.

Причина появления микросервисов

Для начала хорошо бы определить, в чём причина появления микросервисов? Чем оказался плох монолит?

Здесь мне очень помогла статья "Архитектура микросервисов" (автор оригинала - Herberto Graca, перевод - @AloneCoder. Основные отличительные черты микросервисов:

• разграничение контекстов: что бы ни подразумевалось под словом "контекст";

• надпроцессное взаимодействие: части одного приложения взаимодействуют посредством HTTP-запросов, а не в рамках процессов одного сервера;

• независимая масштабируемость: части приложения, как следствие предыдущего пункта могут размещаться на разных аппаратных ресурсах и масштабироваться отдельно от других частей;

• гетерогенность используемых инструментов: различные части приложения могут быть написаны на различных языках программирования;

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

Таким образом, основное ограничение монолита - это то, что он не может быть отмасштабирован частично.

Пределы вертикального масштабирования

Вертикальное масштабирование (наращивание мощности аппаратных ресурсов) вполне доступно для монолита. Где же граница, после которой вертикальное масштабирование становится неэффективным? У меня нет большого опыта работы с высоконагруженными системами, поэтому я основываюсь на стороннем опыте. Так, Александр Бындю в своей статье "Переход от монолитной архитектуры к распределенной" даёт такие количественные характеристики:

• Работа с большими объемами данных - для нас от 500 ГБ и таблицы от 100-150 млн. записей уже считаются большим объемом. ...

• Работа с нагрузками - либо от пользователей (примерно от 100 запросов в секунду к вашим серверам заставят вас задуматься об оптимизации запросов и скорости отклика), либо от внутренних сервисов. ...

Исходя из этого, могу предположить, что монолитное web-приложение вполне комфортно будет масштабироваться вертикально:

• на базах общим размером до 0.5ТБ;

• с таблицами, в которых количество записей не превышает 100 млн.;

• при сетевых нагрузках не выше 100 запросов/сек.

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

Получается, что, если web-приложение не выходит за указанные рамки (или, что касается базы данных, удерживается в этих рамках), то есть смысл оставаться в рамках монолитной архитектуры.

Микрофронтенды

С некоторым для себя удивлением осознал, что микросервисы - это про масштабирование backend'а и только про него. Пользовательский интерфейс отрабатывает на фронте, в браузере клиента. И по своей сущности является классическим "монолитом" - взаимодействие компонентов фронта происходит либо в рамках одного процесса, либо на уровне процессов одного аппаратного устройства и ни о каком горизонтальном масштабировании речь не идёт в принципе. Причём такое положение одинаково для любого типа фронта - SPA, PWA или классическая HTML-страничка с фрагментами JS. В статьях типа "Разделение монолитного приложения на микросервисы" вы ничего не найдёте про то, как делить монолит, чтобы компоненты фронта соответствовали "своим" микросервисам.

Т.к. зависимость по данным между фронтом и микросервисами остаётся и должна поддерживаться (новый атрибут у сущности в микросервисе может требовать новое поле на форме в UI), то микросервисный подход с бэка "протекает" на фронт в виде микрофронтендов.

Из 4 основных характеристик микросервисов, описанных выше, в разделе "Причина появления микросервисов", к микрофронтендам можно отнести только две:

• разграничение контекстов;

• гетерогенность используемых инструментов (если под "инструментами" подразумевать фреймворки - React, Angular, Vue, ...);

В минусе - надпроцессное взаимодействие и горизонтальное масштабирование.

Что характерно, первая причина (разграничение контекстов) является следствием появления микросервисов на бэке и главной причиной возникновения самого понятия "микрофронтенд".

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

Из непонятного - зачем к web-компонентам, виджетам, портлетам, добавились ещё и микрофронтенды?

Монолитен ли монолит?

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

Если рассматривать классическое web-приложение с точки зрения надпроцессного взаимодействия, то на каждом уровне своя группа процессов (браузер, backend, базы данных), а контексты вполне себе разграничиваются на уровне отдельных модулей (библиотек, компонентов, плагинов). Такая архитектура позволяет масштабироваться горизонтально в определённых пределах - "балансировщик нагрузки + несколько экземпляров backend'а", "база данных на запись + кэширующие in-memory DB на чтение". Но чего себе точно не может позволить классическое web-приложение, так это независимого масштабирования частей приложения на уровне отдельных модулей/плагинов (контекстов).

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

Плагины

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

Но внутри плагина сквозное зацепление по данным между пользовательским интерфейсом, бизнес-логикой и хранилищем всё равно остаётся. Поэтому плагины оформляются в виде отдельных пакетов, в которых совместно находятся элементы кода, соответствующие всем трём уровням приложения (UI, бизнес-логика, данные). Сами пакеты распространяются через соответствующие менеджеры пакетов (maven, composer, npm).

Платформы

Многие современные web-приложения строятся на базе какой-нибудь платформы (framework - Wordpress, Django, ...), предоставляющей базовую функциональность, и набора плагинов для этой платформы (публичных или собственного производства), позволяющего удовлетворять бизнес-потребности заказчика.

И если плагины позволяют разделить функциональность приложения на части, то платформы - это как раз тот инструмент, что вновь объединяет части в единое целое. Причём делают они это отдельно для каждого уровня (UI, бизнес-логика, данные), предлагая плагинам соответствующую инфраструктуру для встраивания в приложение на отдельном уровне и для передачи данных плагина между уровнями:

Зачастую платформы используют метаданные менеджеров пакетов (файлы package.json, composer.json соответствующих пакетов) для распознавания "своих" плагинов в общей массе зависимостей приложения.

Режимы работы web-приложения

Web-приложение в общем случае может работать в следующих режимах:

• Web UI: поддержка работоспособности пользовательского интерфейса на клиенте (раздача статики, обмен данными, представление данных в браузере);

• Web API: backend-сервисы для доступа к бизнес-функциям приложения (с фронта или от сторонних приложений);

• CLI: консольный доступ к бизнес-функциям приложения (как правило, сервисным);

• Cron: выполнение задач по-расписанию (например, зачистка устаревших или временных данных);

• Async: асинхронная обработка ресурсоёмких событий (например, списание продуктов со склада при оформлении заказа в магазине);

Для работы в режимах, допустим, CLI и Cron приложению не обязательно нужно находиться на одном аппаратном устройстве. Несмотря на общую кодовую базу, приложение в разных режимах можно запускать на разных серверах (тоже своего рода горизонтальное масштабирование). Главное, что их связывает - единое хранилище данных, которое, кстати, можно попытаться разбить "побазно" и каждую базу разместить на отдельном сервере (подход из мира микросервисов). Для приложения в режиме Web API можно сделать балансировку нагрузки и также разнести экземпляры приложения по разным серверам.

Резюме

Строго говоря, термин "монолит" неприменим к web-приложениям в силу их распределённости (клиент-сервер). Можно принять за "монолитное" приложение, у которого:

• единая кодовая база (с учётом, что клиентская часть реализована на HTML/CSS/JS, а серверная - на Java/C#/PHP/Python/JS/Go/..., но собирается всё в единое приложение);

• модули (plugins), реализующие различные контексты приложения, объединяются одной платформой (framework) для обеспечения сквозной работоспособности модулей на различных уровнях приложения (UI / бизнес-логика / данные);

• общее логическое хранилище данных (которое может быть разнесено на различные сервера по типам данных - файлохранилище, RDBMS, in-memory DBs);

• приложение в различных режимах работает, как правило, в рамках процессов одного аппаратного устройства (разумеется, с учётом разделения по уровням - UI / бизнес-логика / данные);

На мой субъективный взгляд у приложений такого типа в современном мире есть ещё достаточно перспективное будущее в ограниченной нише мелко-средних web-приложений (БД до 0.5ТБ, < 100 млн. записей на таблицу, < 100 запросов в сек. по сети).

Смысл заморачиваться микросервисами в web-приложении есть только в том случае, если приложению грозит шанс стать популярным и выйти в разряд highload-приложений. Но, как писал классик "Все счастливые семьи похожи друг на друга, каждая несчастливая семья несчастлива по-своему." (с) В случае выхода приложения на highload нужно будет "творчески осмысливать" создавшуюся ситуацию и предпринимать шаги по снижению напряжённости, соответствующие данному конкретному случаю. Благо, что сам характер web-приложения предполагает распределённость и есть некоторое поле не только для вертикального, но и горизонтального масштабирования "монолита".

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

Послесловие

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

Очень сожалею, если вас напрягло прочтение моего опуса, но прошу отметить, что вы это сделали совершенно добровольно. И если вдруг вы решите поставите посту минус с пометкой "Ничего не понял после прочтения", то попробуйте перечитать ещё раз - вдруг всё-таки что-то поймёте. Или найдите другую причину. Спасибо за понимание :)

Если же кто-то нашёл для себя что-то полезное - я только рад.

"Счастье для всех, даром, и пусть никто не уйдёт " (с) АБС

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

Человеческие возможности велики, ноограничены. По некоторымприкидкамобщий объём памяти нашего мозга может достигать 5 петабайт это 5 тысяч терабайтов или 5 миллионов гигабайтов. Да, много. Но не бесконечно много. А ведь ещё нужно обрабатывать входящую/исходящую информацию (изображение, звук, запах, вкус, тактильные ощущения, речь, моторика), выполнять прошитые программы (инстинкты) и создавать новые (обучение) это уже не просто память, а устройство обработки информации (процессор). Которое располагается там же, где и память в мозге человека, и использует те же самые аппаратные ресурсы (нейроны и синапсы). То есть, вряд ли объём наше памяти дотягивает до этих самых 5-ти петабайт.

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

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

Нашим предкам было проще, для них мир не менялся с такой скоростью, с какой он меняется для нас. Особенно это касается информационных технологий.

Ведь что я наблюдаю в области web-приложений? Во-первых, война браузеров породила кучу альтернативных технологий (JavaScript, Java applets, ActiveX, Flash, Dart), во-вторых, стандарты webа (HTML, CSS, Browser API) представляют собой результат компромиссов между ведущими игроками, а разработчики вынуждены поддерживать различные имплементации функционала через те жеполифилы. Разнообразные варианты доставки JS-кода в браузер CommonJS, AMD, CMD, UMD, ES6. Славное прошлое ложится тяжким бременем на плечи современного web-разработчика. А ещё на них ложится и не менее славное настоящее Angular, React, Vue, Svelte, Ember, Микросервисы на различных языках программирования Go, Java, Ruby, Python, PHP, NodeJS, C#,

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

Мы не забываем пройденное, мы накапливаем знания. Как снежный ком HTML, CSS, JS, ES6, TypeScript, Web 2.0, SPA, PWA, SEO, SSR, headless, microservices, AWS, Docker, Kubernetes, Мы уже не можем просто так создать HTML страницу и выложить в Сеть, мы должны сначала продумать вот это вот всё и принять решение, что чистого HTMLа будет достаточно. Насколько проще было принимать такое решение, когда мы только и знали, что HTML.

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

Да, человек может либо глубже изучить меньшее количество технологий, либо большее количество технологий, но поверхностно:

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

Эволюция в IT сейчас похожа на сёрфинг нужно поймать волну и держаться на ней, пока у той есть достаточно энергии:

Затем брать доску (интеллект) и искать новую волну (технологию).

А потом опять, опять и опять

Благо, что волн становится только больше.

В индустрии сложилось устойчивое мнение, что Service Locator является анти-паттерном. Из wiki:

Стоит заметить, что в некотором случае локатор служб фактически является анти-шаблоном.

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

Вот что пишут в интернетах по поводу Локатора:

Некоторые считают Локатор Служб анти-паттерном. Он нарушает принцип инверсии зависимостей (Dependency Inversion principle) из набора принциповSOLID. Локатор Служб скрывает зависимости данного класса вместо их совместного использования, как в случае шаблона Внедрение Зависимости (Dependency Injection). В случае изменения данных зависимостей мы рискуем сломать функционал классов, которые их используют, вследствие чего затрудняется поддержка системы.

Service Locator идёт рука об руку с DI настолько близко, что некоторые авторы (Mark Seemann, Steven van Deursen) специально предупреждают:

Service Locator is a dangerous pattern because it almost works. ... Theres only one area where Service Locator falls short, and that shouldnt be taken lightly.

Т.е., Локатор чертовски хорош и работает почти как надо, но есть один момент, который всё портит. Вот он:

The main problem withService Locators the impact of reusability of the classes consuming it. This manifests itself in two ways:

* The class drags along theService Locatoras a redundantDependency.

* The class makes it non-obvious what itsDependenciesare.

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

Другими словами, вот так создавать объекты и внедрять в них зависимости благословляется:

public function __construct(IDep1 $dep1, IDep2 $dep2, IDep3 $dep3){    $this->dep1 = $dep1;    $this->dep2 = $dep2;    $this->dep3 = $dep3;}

а вот так - нет:

public function __construct(ILocator $locator){    $this->locator = $locator;    $this->dep1 = $locator->get(IDep1::class);    $this->dep2 = $locator->get(IDep2::class);    $this->dep3 = $locator->get(IDep3::class);}

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

Property Injection should only be used when the class youre developing has a good Local Default, and you still want to enable callers to provide different implementations of the classs Dependency. Its important to note that Property Injection is best used when the Dependency is optional. If the Dependency is required, Constructor Injection is always a better pick.

Если мы перепишем наш класс с Локатором в таком виде:

public function __construct(ILocator $locator = null){    if ($locator) {        $this->dep1 = $locator->get(IDep1::class);    }}public function setDep1(IDep1 $dep1){    $this->dep1 = $dep1;}

то, а) мы делаем его независимым от наличия Локатора (например, в тестовой среде), б) явным образом выделяем зависимости в setter'ах (также можно аннотировать, документировать, ставить префиксы и решать проблему "неочевидности" зависимостей любым другим доступным способом, вплоть до Ctrl+F по ключу "$locator->get" в коде).

Вот мы и подошли к тому моменту, когда, на мой взгляд, использование Локатора оправдано. В комментах к статье "Какое главное отличие Dependency Injection от Service Locator?" коллега @symbix резюмировал тему статьи так:

SL работает по принципу pull: конструктор "вытягивает" из контейнера свои зависимости.

DI работает по принципу push: контейнер передает в конструктор его зависимости.

Т.е., по сути дела, DI-контейнер объектов может использоваться и как Service Locator:

// push deps into constructorpublic function __construct(IDep1 $dep1, IDep2 $dep2, IDep3 $dep3) {}// pull deps from constructorpublic function __construct(IContainer $container) {    if ($container) {        $this->dep1 = $container->get(IDep1::class);        $this->dep2 = $container->get(IDep2::class);        $this->dep3 = $container->get(IDep3::class);    }}

Как мы уже отметили выше, первый способ считается допустимым, второй - анти-паттерн. Но к чему приводит применение первого способа в промышленных объёмах? К тому, что, чтобы запустить приложение, мы должны при создании заинжектить в конструктор приложения его зависимости, а в их конструкторы - зависимости зависимостей и т.д. по всей иерархии. Т.е., чтобы объект приложения был хотя бы создан, мы должны по цепочке создать все зависимости, упомянутые во всех конструкторах, даже если мы собираемся всего лишь получить справку о параметрах запуска приложения в консольном режиме.

"Анти-паттерн" Service Locator же позволяет нам "вытягивать" из контейнера нужные нам зависимости по мере обращения к ним:

class App {    /** @var \IContainer */    private $container;    /** @var \IDep1 */    private $dep1;    public function __construct(IContainer $container = null) {        $this->container = $container;    }    private function initDep1() {        if (!$this->dep1) {            $this->dep1 = $this->container->get(IDep1::class);        }        return $this->dep1;    }    public function run() {        $dep1 = $this->initDep1();    }    public function setDep1(IDep1 $dep1) {        $this->dep1 = $dep1;    }}

Итого, приведённый выше код:

• может быть использован без контейнера в конструкторе за счёт возможности внедрения зависимости через setter (например, в тестах);

• зависимости явно описываются через набор private-методов с префиксом init;

• иерархия зависимостей не тянется при создании экземпляра данного класса, а создаётся по мере использования.

В таком варианте использования паттерн Service Locator вызывает во мне положительные эмоции и не вызывает отрицательных. Ну если только за малым исключением - при внедрении зависимостей в конструктор (режим "push") DI-контейнер знает, для какого класса создаются зависимости и может внедрять различные имплементации одного и того же интерфейса на основании внутренних инструкций. В режиме "pull" у контейнера нет информации для кого он создаёт зависимости, нужно её дать:

$this->dep1 = $this->container->get(IDep1::class, self::class);

Вот в таком варианте Service Locator становится очень даже "pattern" без всяких "anti".

Всем привет, меня зовут Иван, я разработчик, пишу на Java. Хочу поделиться с вам мыслями и совместно порассуждать, когда не стоит идти учиться на программиста.

Что я имею ввиду? Если совсем коротко: не надо заниматься программированием, если вам это не нравиться. Глупее некуда, зачем вообще озвучивать то, что понятно всем по умолчанию, скажете вы. Но, не все так просто, отвечу я.

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

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

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

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

1. Что меня привлекает в данной профессии? (Если ответ деньги, можете смело откладывать это в сторону и искать то, что вам будет нравиться независимо от прибыльности)

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

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

Вывод: прежде, чем кинуться изучать Python или Java, PHP или JavaScript изучите сначала то, за что вы планируете получать эту саму "большую зарплату". Ведь если в какой-то области у вас не получается зарабатывать деньги, может быть вы делаете то, за что не платят?

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