Всем привет

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

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

Итак, большинство из нас училось в школе и ходило на уроки информатики, где людей пугали битами, байтами, Адой Лавлейс и паскалем, рассказывали страшные истории про ХАТЭМЭЛЭ и инторнэт. Самые прошаренные именно там научились писать циклы, функции и даже изредка - пощупать кое-какие объектики. Вот оттуда мы и начнём.

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

Так и появились перфоркарты - не дискретные, те, которые применялись в прошлом веке, а аналоговые. Дощечка с дырками, куда проваливается стерженёк. Тогда основная парадигма алгоритмов была в том, что нужно ПОВТОРИТЬ последовательность действий. Потом туда подъехало ветвление. Узнаёте? Да это же идейные предки for и if!Да-да, ваш первый шаг в мире программирования был заложен тогда, когда на фабрике могло не быть электричества вовсе.

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

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

Теперь рассмотрим парадигму императивную. Расчёты - это конечно, хорошо, но зачем мы всё это считали? Не для того же чтобы просто показать результат на экране. Нам надо чтобы исходя из рассчётов, машина "приняла" то или иное решение. И кавычки тут не зря - дело в том, что решение принимает программист, а машина просто осуществляет ветвление при условии. И математика тут не очень помогает - она писана для универсальных паттернов, а не для местечковых решений. А значит, в дело вступает императивная парадигма - строго упорядоченная и не являющаяся паттерном сама по себе.

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

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

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

Но стоп. Если мы описали машину отдельно - мы ведь можем для нашего алгоритма перемещения её просто... заместить! Какая разница, что перемещать, если нам не нужно описывать детали! Давайте просто на место "машины" подставим что угодно, имеющее схожие свойства. А для дополнительного удобства, давайте мы договоримся, какие команды можно давать "передвигаемому объекту" и забудем вообще про машину - теперь можно двигать вообще что угодно, лишь бы это "что-то" поддерживало такие команды!

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

И вот тут вылезает сервисная логика. Если мы можем описать "машину", которая реальная и существует - почему мы не можем описать таким же образом какой нибудь воображаемый объект, который нужен для упрощения дальнейшего написания алгоритма? Ну, к примеру, машину теперь будет двигать не алгоритм, а специальный, невидимый никому, объект "Перемещатель".

Теперь, если вам захочется увеличить функционал и докинуть, к примеру, возможность заправки машины и погрузки туда пассажиров - вы можете сделать невидимый "заправщик" и "погрузчик", и сжать свой алгоритм до "погрузчик, помести пассажира. Заправщик, налей топлива. Перемещатель, перемести в точку Б".

Йоу, бро, мы слышали, ты любишь механизмы. Так вот, мы сделали возможность тебе делать механизмы внутри механизмов, чтобы ты делал механизмы внутри механизмов, пока делаешь механизмы. Да-да, вот сюда нас заводит следующая итерация развития программирования. Мы уже сделали невидимые объекты, которые что-то там делают. Так, может... сделать их тоже программируемыми?

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

Но, раз у нас есть целый "перемещатель" - может, он ещё и путь за нас проложит? Давайте просто дадим ему точки назначения - и пусть он сам решит! Такой вот список - это декларация того, что надо сделать, с расчётом что всю нужную работу проделают внутренние механизмы. Собственно, на этом строятся декларативные языки программирования и разметочные языки, типа XML или того самого HTML.

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

Что делать? Правильно, переводить всё это на следующий уровень абстракции и мыслить системно. Теперь крыса должна для начала, построить систему из сервисных механизмов, и распланировать, кто, зачем, откуда и почему берёт данные. Для заправщика должен быть сделан поставщик, для погрузчика заготовитель должен найти людей, для перемещателя прокладыватель путей сделает путь, и все они должны друг с другом взаимодействовать, чтобы машина переехала из точки А в точку Б.

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

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

Что я упустил? Да вообще всё, что не касается работы программиста - тестирование, контроль качества, администрацию готовых продуктов и так далее, и тому подобное. Огромная масса айтишечки не пишет код в принципе. Но, надеюсь, я достаточно просто объяснил, в чём суть работы современного программиста.

Источник: vk.com

Комментарии: