Набрел вот случайно на эту тему.....

За эти годы кое-чего произошло таки. Решил поделиться своими (уже сегодняшними соображениями) про то, какова таки судьба Программирования вообще, и HiAsm в частности.
Ну, скажем, моя сегодняшняя работа.
Меня взяли на работу для создания/организации процесса создания новых изделий на неком предприятии.
Грубо говоря – начальник отдела разработки. Который, несмотря ни на что, не потерял знаний прошлого тысячелетия о том, что такое профессия Инженера.
Это и конструирование, и электроника, и программирование...

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

1) Сделанный код должен не только отвечать показателям назначения (грубо говоря - работать). Это всего лишь первое требование.
2) Он должен быть понятен любому – мне, моим работодателям, коллегам программистам. Время вхождения нового человека должно быть разумным (не более недели - для проведения грамотных и безошибочных модификаций/расширений функционала). Увы, но сегодня это не меньше чем полгода. Если автор перед этим год работал.
3) Результирующий код должен быть эффективен. Хотите верьте, хотите - нет: но реальный малопотребляющий Cortex-M3 - это всего лишь 72МГц и 64К встроенного ОЗУ. Есть, конечно, и гигагерцовые камни, и камни с внешним ОЗУ, но нам нужны камни, на которых можно решать real-time задачи. Да и с энергетикой проблемы - не могу себе позволить роскошь, типа 1Вт на камень.
Тут я не виноват - наш потребитель находится в шахте, искробезопасная цепь, длинные расстояния. Просто – именно такова жизнь, даже если это кому-то не нравится.
4) Даже если ты использовал чужой код (например - операционная система, speex-кодек звука, и т.п.), то отвечать деньгами будешь именно ты. А не авторы некого стороннего софта – то, что ты купил этот софт (к примеру), никакого значения иметь не будет.
5) Некоторые real-time характеристики должны быть "доказаны". Бог с ней с "абсолютной математикой" (типа – не все сразу), но должны быть экспериментальные данные значительно более убедительные, чем "я проверил - оно работает".
6) Оно должно работать ВСЕГДА. Добавление этого коротенького слова увеличивает трудозатраты от 3-х до 10 раз. Собственно, это обычное дело в инженерной практике. Сделать нечто, и даже пользоваться потом самому - это одна история. А вот сделать так, чтобы и изготавливали другие, и пользовались другие, а ты про это напрочь забыл – совершенно другая история... Ну не совсем другая – так, всего лишь в те самые 3-10 раз сложнее, не более того.
7) Почти то же самое, что и предыдущий пункт: скорость создания кода не приоритетна. Качество – во много, много раз важнее.

В качестве короткого резюме для этой вводной части: работой Инженера вовсе не является создание некого изделия, но создание некого технологического процесса, который потом самостоятельно будет изготавливать эти изделия. Ну типа: не сделать детальку, а сделать станок, изготавливающий такие детальки. Эдакий метапереход
Собственно говоря, софт становится автоматически деталькой этого «станочка», если он сделан с выполнением вышеозначенных пунктов. А моя лично работа: создать технологический процесс производства таковых «станочков». Типа: метапереход уже второго порядка


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

А дальше начинается самое интересное
Ну то, что почти все это вызвало некоторый шок у моих коллег-подчиненных - это пропустим
К тому, что «работает же!» - вообще никаким аргументом не является, коллеги уже привыкать начинают. Электроников я уже научил рисовать схемы так, чтобы вхождение нового коллеги в тему – не более дня.
((принципы то простые и знакомые: структурирование по объектам, чтобы минимизировать количество взаимосвязей. На одной схеме – 10-20 объектов, не более. Узнаете «брата Колю»? ))

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

Опять же, хотите верьте, хотите – нет: самый убежденный Плюшник начинает рисовать после этого квадратики, и соединять их стрелочками и линиями.
Ничего не напоминает
Все это настолько же прекрасно, как и в HiAsm. За исключением семантики нарисованного.

Про семантику квадратиков – понятно. Это также как и у нас: семантика мультика – она определяется вложенной схемой.
А вот с семантикой линий – полный беспредел. Спросишь – получишь длинный разговор с активной жестикуляцией руками. Причем, разные люди, глядя на одну и ту же взаимосвязь, будут говорить совершенно разные слова. Тут HiAsm далеко впереди – никакой неоднозначности.

Активно (хех ) обсудивши все это дело, даю следующее задание коллегам: давайте проведем эксперимент – нарисуем то же самое, но чтобы семантика связей была такой же, как и в HiAsm.
Грубо говоря, чтобы это и была схема в HiAsm. Состоящая из уникальных элементов, коды которых – это и есть задача для программиста, на порядок более простая, чем полная задача. А применяемость в исходной схеме – техническое задание для программиста.

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