Об автоматизации производства
Тут товарищ caurug высказывает мнение, что программисты бесконечно далеки от Настоящей Жызни™, реальный уровень автоматизации - табличка в Excel’е, а если выпустить программиста к пользователям без пулемёта, то его заслуженно порвут на британский флаг.
Естественно, возникает вопрос - как же так получилось? И у меня есть несколько ответов...
Прочитав в посте по ссылке про «спецификацию оборудования», я прикинул в голове модель данных, в которую можно было бы оную спецификацию уложить. Разумеется, я не могу знать всех нюансов, и модель настоящего приложения была бы в два-три раза сложнее, чем мне представляется. Но даже в том куске, который уже сложился, отчётливо видны места, в которых среднестатистический разработчик попытается «срезать углы» со всеми вытекающими.
Когда-то давно Эдгар Кодд придумал реляционную модель данных. Это без преувеличения одно из величайших изобретений в области computer science, позволяющее в достаточно строгих математических терминах описать любую область человеческой деятельности. Что же могло пойти не так? Как ни странно, злую шутку с человечеством сыграла доступность оборудования.
Во времена Кодда предполагалось, что разработка программного обеспечения проходит несколько стадий - обдумывания, проектирования, кодирования, документирования, тестирования. Сегодня эту модель разработки называют «водопадной», потому что как вода не течёт вверх, так и стадия кодирования никогда не предшествует стадии обдумывания. Если уж компания позволила себе купить ЭВМ, она может позволить себе и подумать.
Сегодняшний подход к разработке называется «эджайл». У него тоже есть какие-то правила и манифесты, но вкратце его сущность выражается формулой «хренак, хренак - и в продакшен», то есть в основном разработка состоит из стадии кодирования, а всё остальное - по остаточному принципу. В результате экономии на стадии обдумывания пользователь получает приложение, которое ломается на первой же реальной ситуации.
Второй интересный эффект, вызванный обилием дешёвых компьютеров, - обилие программистов. Реляционная модель хороша тем, что позволяет одни и те же данные представлять в совершенно разных видах: полная спецификация - для руководителя проекта, разбивка по поставщикам - для закупщиков, разбивка по участкам - для монтажников... И в каждом представлении - свой набор полей, своя нумерация, свой порядок перечисления. Большинству же программистов это не очевидно: они научены работать в процедурной парадигме «что вижу, то пою». В результате они безуспешно пытаются придумать какое-то универсальное представление данных, и максимум, что им удаётся, - как-то минимизировать неудовлетворённость клиентов «чтобы хоть как-то работало».
Третья проблема растёт из первых двух: пользователь не заинтересован в автоматизации, так как уже не ждёт ничего хорошего. Поэтому в большинстве случаев максимум обратной связи, на которую может рассчитывать разработчик, - «говно, ничего не работает».
В моей практике были пара случаев, когда руководство было заинтересовано в автоматизации любой ценой, и эта заинтересованность была в убедительной форме донесена до пользователей. Внезапно их отзывы о программах становились содержательными и конструктивными, что позволяло в довольно-таки сложных областях получить вполне удобный программный продукт, которым реально пользовались.
К сожалению, в рамках поста в ЖЖ невозможно ответить на вопрос «что делать?» За этим - к Николаю Гавриловичу Чернышевскому.