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

Это заняло 30 летОбласть применимости очень ограниченаЭто требует большой вычислительной мощности процессоров

SQL не прост. Это в точности то, что мы описали -- управление известными вещами с помощью идиом -- каждый понимает ужасы внешних связей таблиц (outer joins).

И вновь здесь возникает "ход конем". Что лучше: разработать действительно сложный код, послать его, и затем получить короткий ответ, или послать простой код и получить длинное сообщение. Каковы предположения о квалификации и опыте администратора базы данных? Насколько мы можем расширить их понимание в документации, чтобы мы могли использовать более "сложные" идиомы? Огромный switch()- обычно довольно ужасный способ управлять процессом, если только вы не пишете цикл обработки событий GUI, где мы все его предполагаем и ищем его.

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

Фундаментальный элемент взгляда паковщика на работу -- управление посредством угрозы. Выполни действие так и так, и не иначе. Чтобы сделать угрозу эффективной, исполнение правил должно контролироваться (полицейскими методами), поэтому мы должны следить, гарантируя этим следование правилу. Тогда ленивые и ненадежные работники будут знать, что их уволят, и будут выполнять действия как предписано из страха наказания. Действительно, важное соображение, из-за которого отвергают стиль работы картостроителя, поддерживается заблуждением, что работа картостроителя может быть специфицирована по шагам (microspecified), а единственная причина, почему это необходимо делать -- то, что правила должны быть специфицированы. Только для записанных на бумаге правил можно выявить их нарушение программистами, и возможность этого выявления поставлена в центре всей модели!

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

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

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

Инспектирование кода составляет важную часть процесса многих организаций. Изначальная причина, почему его делают -- удовлетворить здравый смысл. TQM требует: "Если вы сделали работу, посмотрите на то, что вы сделали, и убедитесь, что с этим пунктом все в порядке". Но в инспектировании кода появляется нечто забавное, часто искажающее его назначение. Это вызвано тем, что инспектирование кода похоже на Рождество. Это старое действо, которое старше структур, с которыми оно имеет дело. И, как и Рождество, содержит множество мишуры, происходящей из Старой Религии.