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

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

Имеются языки, которые специализируются на определенном подходе. Smalltalk требует от пользователя рассматривать мир в виде объектов. Lisp требует применения неудобоваримых манипуляций с лямбда исчислением, которые приводят к появлению "собаки еды" (dog of food), вместо накормленной собаки.

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

Интересные методологии состоят частично из подхода, частично из языка. Структурный дизайн Джексона (Jackson Structured Design -- JSD) ограничивает свою область применения проблемами с ясно идентифицируемыми чертами (свойствами) и поэтому в состоянии предложить очень детальную инструкцию, как решать проблемы такого типа. Держите глаза открытыми, и JSD хорошо послужит в своей области. Однако за пределами этой области он может вызвать проблемы, поскольку если у задач нет нужных Джексону черт, то бесконечное латание дыр (kludging) будет делать хорошую систему из плохого понимания. Это не ошибка Джексона, поскольку он никогда не говорил, что JSD -- это ритуализованная панацея для решения всех компьютерных проблем.

На выходе JSD мы видим нечто совершенно неожиданное, артефакт того времени. Джексон описывает, как перейти от его диаграмм к коду, делая это вручную! Он осознает, что он делает, и поясняет, что автоматизм этой работы позволяет нарушить правила структурного программирования и использовать goto. Сегодня он не стал бы этого делать -- он бы просто направил диаграммы в генератор кода, как это многие и делают. Дело в том, что нотацию диаграмм JSD лучше всего рассматривать как язык программирования! Джексон создал язык, который был ориентирован на некий подход к проблемной области.

То же самое справедливо для подходов и языков Буча (Booch), Румбаха (Rumbaugh) и UML (Unified Modelling Language). В действительности, для каждой интересной методологии. В ранних публикациях Буча и Румбаха они не пропускали диаграммы через генераторы кода, но показали, что трансляция большинства диаграмм в большой степени механична. Не переживайте слишком сильно о реализации этих методов вручную -- в целом это несложно!