Об автоматизации производства

hardsign — 14.12.2023

Тут товарищ caurug высказывает мнение, что программисты бесконечно далеки от Настоящей Жызни™, реальный уровень автоматизации — табличка в Excel’е, а если выпустить программиста к пользователям без пулемёта, то его заслуженно порвут на британский флаг.

Естественно, возникает вопрос — как же так получилось? И у меня есть несколько ответов...

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

Когда-то давно Эдгар Кодд придумал реляционную модель данных. Это без преувеличения одно из величайших изобретений в области computer science, позволяющее в достаточно строгих математических терминах описать любую область человеческой деятельности. Что же могло пойти не так? Как ни странно, злую шутку с человечеством сыграла доступность оборудования.

Во времена Кодда предполагалось, что разработка программного обеспечения проходит несколько стадий — обдумывания, проектирования, кодирования, документирования, тестирования. Сегодня эту модель разработки называют «водопадной», потому что как вода не течёт вверх, так и стадия кодирования никогда не предшествует стадии обдумывания. Если уж компания позволила себе купить ЭВМ, она может позволить себе и подумать.

Сегодняшний подход к разработке называется «эджайл». У него тоже есть какие-то правила и манифесты, но вкратце его сущность выражается формулой «хренак, хренак — и в продакшен», то есть в основном разработка состоит из стадии кодирования, а всё остальное — по остаточному принципу. В результате экономии на стадии обдумывания пользователь получает приложение, которое ломается на первой же реальной ситуации.

Второй интересный эффект, вызванный обилием дешёвых компьютеров, — обилие программистов. Реляционная модель хороша тем, что позволяет одни и те же данные представлять в совершенно разных видах: полная спецификация — для руководителя проекта, разбивка по поставщикам — для закупщиков, разбивка по участкам — для монтажников... И в каждом представлении — свой набор полей, своя нумерация, свой порядок перечисления. Большинству же программистов это не очевидно: они научены работать в процедурной парадигме «что вижу, то пою». В результате они безуспешно пытаются придумать какое-то универсальное представление данных, и максимум, что им удаётся, — как-то минимизировать неудовлетворённость клиентов «чтобы хоть как-то работало».

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

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

К сожалению, в рамках поста в ЖЖ невозможно ответить на вопрос «что делать?» За этим — к Николаю Гавриловичу Чернышевскому.

Оставить комментарий

Популярные посты:

traianus

Как справиться с болью при ношении брекетов

veronika_stef

Про Сортавалу в двух словах

val000

Суфизм о гадании и знаках

padolski

Безлюдье

e_kaspersky

Туристов нет, хотя как же здесь красиво! – Камбальный хребет.

nefer

Почему памятник князю Сергею Романову и его супруге установили именно на

sveta_ki

Люди злы и порочны по природе

philologist

Кузьмичев И.С. Судьба обретает рисунок. Эпистолярная хроника. Литературные

aniskin1968

«Закуски от дяди Гиляя». (dejur.)

• Ранее
• Архив