
Программер на боевом посту
Подходы, методики, языки
Для каждого кусочка кода надо найти отображение между проблемной областью и системной семантикой, которая может решить проблему. Очевидно, чем меньше вариантов отображения, тем легче найти подходящий, особенно если он существует. Как каждая проблемная область, так и каждая проблема в ней характеризуется некоторым уровнем сложности. Редко можно изменить определение проблемы так, чтобы управлять уровнем сложности, хотя это и желательно. Обычно, чтобы найти наиболее эффективный путь сделать работу, можно лишь поиграть с системной семантикой.
На одном конце спектра возможностей готовая система, которую можно просто запустить и получить результат. На другом - набор инструкций процессора, с помощью которых можно осуществить любое физически возможное действие. Между этими крайностями есть несколько уровней, которые облегчают отображение путём ограничения семантики.
В этой терминологии язык является некоторым мешком с семантикой. Например, С или Excel являются такими мешками, которые не содержат однако рецепта для решения проблемы. Специализированные для определённых предметных областей языки позволяют проще найти отображение для проблемы из этой области. Критерием выбора языка может служить простота отображения (наиболее простая программа) для данной проблемы. За исключением тривиальных случаев, выбор требует хорошего знания особенностей всех имеющихся мешков.
Несколько сложнее представить в этих терминах методику. Обычно методика подразумевает некоторый процедурный подход к решению проблем, но мы уже выяснили, что процедуры решения проблем не существует. Однако можно определить что-то немного другое - сам подход.
Подход можно представить как совет одного опытного картографа другому как наилучшим образом браться за решение данного вида проблем. Это лишь приглашение взглянуть на проблему под определённым углом, даже если оно оформлено как перечень процедур. Директива "нарисуйте диаграмму потоков данных для поступлений за неделю" из книги "как построить платёжную систему" означает "ограничьте мир системой ввода пакетных данных и рассмотрите движение всех пакетов данных в мире".
Как и язык, подход становится тем проще, чем больше он привязан к предметной области, и так же сложно его выбрать без понимания особенностей всех доступных подходов и самой проблемы. Возможный путь развития для хороших программистов - изучение сильных, глубоких подходов и создание новых подходов для новых проблем. Всегда будут толпы людей, использующих один и тот же подход как ритуал для написания такой же платёжной системы для очередного клиента. Они даже могут обучаться "самым новейшим методикам", но всегда останутся служителями культа, и разрыв между ними и программистами будет увеличиваться.
Есть языки, привязанные к определённым подходам. Smalltalk требует видения мира как набора объектов, Lisp тесно связан с лямбда-исчислением, что приводит к предложению еды из собаки вместо предложения накормить собаку.
Ещё раз подчеркнём, что языки реальны, подходы реальны, а методики есть вымысел, часть коллективного воображаемого. Непонимание этого и неудачный выбор подхода могут привести к ситуации, когда важные части задачи не рассматриваются, поскольку лежат вне выбранного подхода, а те, кто пытается всё-таки в них разобраться, встречают сопротивление коллег, поскольку действуют не по методике и, значит, непрофессионально. Это ещё один пример барьера между картографами и заготовителями.
Интересные методики состоят сразу из подхода и языка. Структурный дизайн Джексона (JSD) рассматривает задачи с чётко определяемыми свойствами и содержит детальные указания, как с ними обращаться. Если смотреть в оба глаза, JSD может хорошо послужить в своей области. За её пределами он не работает и не является средством решения любых задач.
В JSD есть артефакт того времени - алгоритм преобразования полученных диаграмм в код вручную. Сегодня он написал бы генератор кода, но на самом деле его диаграммы можно рассматривать как язык программирования, то есть он создал язык программирования для специализированного отображения области задач.
То же самое относится и к Бучу с его UML, и к каждой интересной методике. В ранних работах он и Румбаух тоже не использовали кодогенераторы, а показывали, что трансляция диаграмм является рутинной ручной работой, значит, несложной.
Создание языка и подхода, специализированного для области, само по себе большое достижение. Для этого авторы долго изучают задачи под разными углами, создают подход и язык исходя из этого опыта. Однако многие не выделяют то креативное мышление, которое потребовалось для поиска отображения между задачей и языком. Вместо структурированного представления их подхода и предложения эвристик для видения задач в его терминах, они используют процедурный язык и дают указания что и как надо делать.
Если слепо следовать указаниям вместо осознанного создания карты, то результаты зависят от попадания в проблемную область, то есть от везения. Джексон специально объясняет, как определить, попадает ли в его область задача. Буч включил главу о том, как правильно определять объекты, что непосредственно касается вопросов картостроения. Наконец, книга Страуструпа написана картографом, у которого нет внутренних противоречий.