Alan Carter - The Programmers Stone (Программистский камень)

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

Проблема, возникающая вместе с объектными библиотеками, состоит в том, что объекты очень хорошо инкапсулируют (скрывают) свою реализацию. Это позволяет нам использовать иерархии классов на самом деле ничего не зная о их содержимом. Поэтому приходится продираться через несколько слоев классов, каждый из которых (возьмем пример из Географических Информационных Систем — Geographical Information Systems) имеет дело с координатной системой, просто для того, чтобы поставить значок на карте. Никаких проблем не возникает до тех пор, пока мы впервые не попытаемся поставить несколько сот значков, и обнаружим, что «простое присваивание», которым мы так восхищались, требует столько вычислительной мощности, что для перерисовки экрана нужно полчаса.

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

Как всегда, самое лучшее оружие от распухания — это концептуальная целостность, достигаемая сравнением мысленных моделей проекта.

Была команда, которую заказчик попросил создать среду реального времени, которая могла бы поддерживать небольшие процессы, стыкуемые через средства ввода/вывода, что-то типа графической оболочки для управления сложной системой трубопроводов. Если классифицировать эту задачу, это работа по системному программированию. Эта команда решила быть Профессиональной, и стала использовать Надлежащие Методы. Поэтому они пошли и сделали объектно-ориентированную модель этих вещей из Требований Пользователя используя инструменты, автоматизирующие подход Шлера-Меллора (Shlear-Mellor). Но была небольшая трудность, поскольку проблема была из другой области, зато они подогнали ее под Надлежащую Методологию. Они ведь могли использовать генератор кода! Они нажали кнопку и получили целую кучу склеенных классов. Каждый из них просто вызывал процедуру из API из «Программной Архитектуры», слоя, который требовался в подходе, что позволяло приложению работать на определенном типе компьютерной системы. В этом случае Программная Архитектура стала бы системным средством предоставления графического интерфейса для оболочки, работающей со сложной системой трубопроводов!

Как картостроители, мы можем видеть, что произошло с этим образчиком тупого Профессионализма и Следования Процедуре паковщиков. Команда извлекла не тот пакет знаний и использовала хорошо продуманный и замечательно автоматизированный подход и язык в совершенно неправильном контексте. Подход Шлера-Меллора предназначен для задания функционирования прикладных программ, а не для системного программирования. Говоря простым языком, они не смогли увидеть, что классификация проблемы была проведена неправильно, поскольку у них не было здравого смысла, что есть результат недостатка морали или врожденного идиотизма. Мы предпочли бы сказать, что они были принуждены думать, что им нельзя думать непосредственно о работе, но сначала все смести и найти костыль. Потом они могли видеть проблему только через подход, даже если он плохо соответствовал. Затем подход уровня приложений представил их проблему на прикладном языке. Поэтому им в голову не приходило подумать, какого сорта программу они пишут, и заметить, что это системная оболочка, а не прикладная программа. Для паковщиков Профессионализм всегда означает взять зубную щетку и палочки для еды в руку и не замечать, что зубная щетка попала в нос, хотя все в полном соответствии с церемонией!

По мере того, как все становилось все более абсурдным, росло напряжение и команда все настойчивее обороняла свой Профессионализм. Один раз на встрече некто, ожидая хотя бы немного прагматизма, представился как «программист компьютеров» (computer programmer). Результат был замечательный. Вся команда глядя в пол бубнила под нос «Программный Инженер… Компьютерный Ученый…» (Software Engineer… Computer Scientist…), как будто тот совершил значительную социальную ошибку. Два члена команды позднее объясняли, что они не нашли создание «просто кода» интересным, и их Профессиональный Интерес заключался в Применении Процесса.

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

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

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