Что нужно знать новичкам в ИТ о разработке информационных систем?

— …Да и не только новичкам, кстати.Я готовлю обучающий курс для наших ребят и, для того, чтоб замотивировать себя на дальнейшую работу, я решил опубликовать вводную часть здесь, в виде статьи. В основном тут текст сумбурный - это мои заметки, не судите строго.Буду признателен за любые советы и обратную связь.

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

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

Понимаю, все эти «Корпоративные Информационные Системы» звучат задротно и канцелярно, но именно представление о типовом устройстве информационной системы является основным — а уже потом идут всякие "Клиент-серверы", "Монолиты", "Микросервисы", "Двух- и трёхзвенки" и эти ваши "Толстые клиенты".

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

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

Думаю, такая картинка знакома всем.

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

Более того, для многих, «Клиент-сервер» — это когда «Есть клиент, сервер и база данных». При этом:

Да оно и понятно — в интернете тонна однообразной информации, зачастую от онлайн школ. При этом фокус внимание всегда смещён в подробности реализации «квадратиков» и «стрелочек», оставляя за скобками общий механизм взаимодействия.

Получается интересная тема: почти 99% собеседуемых джунов (и мидлов) уверенно и по заученным шаблонам рассказывают, что “фронт ходит в API”, тут же рассказывают, что “SOAP - это протокол, а REST - архитектурный принцип”, говорят, что умеют писать «простые SQL-запросы» (что это вообще такое?), но при этом не понимают для чего вообще нужна клиент-серверная архитектура, зачем нужно API, структуру HTTP запросов-ответов, виды связей между таблицами в реляционной БД, чем «БД отличается от СУБД». Как можно работать над решением проблемы заказчика, если не понимаешь то, что разрабатываешь?

Дальше больше.

Ещё пример: как-то один системный аналитик на собеседовании уверенно рассказывал мне про преимущества микросервиса перед монолитом, упоминал «балансировщики» по заученным лекалам, но не смог объяснить а какие вообще виды приложений бывают и чем, например, консольное приложение отличается от десктопного.

Ещё дальше: некоторые рассказывают про виды приложений, но не могут привести пример “из жизни” хотя бы одного десктопного приложения.

Снежный ком накапливается: профессии требуют, чтобы вы умели описывать интеграции через всякие Кафки, чтобы вы умели описывать микросервисы (или тестировать их, или реализовывать), учитывать всякие там “токены безопасности” и писать «простые SQL-запросы». Да, это ваши инструменты для повседневной работы. Если хотите, то, метафорически - эта ваша дрель. Но прежде чем изучать устройство дрелей, нужно сначала понять а зачем она нужна и в каких случаях её использовать.

Вы читаете, учите, заучиваете, что-то пишете, но чёрт. Это всё разрозненно и не собрано в единую картинку.

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

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

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

Чтобы понять эти квадратики-основы, надо усвоить:

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

Надо сказать, что на мой взгляд нужно также иметь представление о:

Но, думаю, пока оставить это за пределами данного диалога.

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

Какой бы сложной система не представлялась, её, как того треклятого слона, можно съесть по кусочкам, рассматривая её как цепное взаимодействие “двух квадратиков” и передаваемых между ними сообщений:

Любая система может быть рассмотрена как комбинация пар её компонентов, общающихся между собой.

В итоге ИТ команде остаётся просто продумать “диалог”: какие квадратики взаимодействуют напрямую и каким способом они общаются? Как эти квадратики устроены?

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