"Повторное использование в DFDM - это естественно. Технология DFDM не имеет себе равных в повторном использования по сравнению с другими в настоящее время" (из оценки DFDM, выполненной сайтом IBM I / S в США в 1988 году).
До сих пор мы говорили, что компоненты создаются "из воздуха" для решения конкретной проблемы. Вы могли подозревать, что я выбрал свои компоненты для иллюстрации определенных концепций, не беспокоясь о том, будут ли они полезны в реальном приложении. Что ж, хорошая новость, что типы компонентов, с которыми мы столкнулись, на самом деле являются теми, которые, как показывает опыт, очень полезны для создания реальных приложений. Плохая, что для создания полезных компонентов требуется большой опыт программирования и определенное творческое чутье. Это не должно удивлять, когда вы думаете о полезных инструментах, которые привыкли использовать в реальной жизни. Где и когда был изобретен первый молоток? Представьте себе целую серию "прото-молотов", например, оленьи рога, камни, прикрепленные к палкам и т.д. Которые постепенно превращаются в то, к чему мы привыкли сегодня... Возможно, мы должны уточнить, сказав "на Западе". В разных культурах появятся разные инструменты или разные формы одного и того же инструмента. На уроках антропологии я, кажется, помню, что у австралийских аборигенов есть замечательный инструмент, который представляет собой комбинацию всего, что они считают наиболее полезным в повседневной жизни, и при этом очень портативен. Это комбинация копья, щита, тарелки и зажигалки. Такие инструменты не изобретаются в одночасье - они требуют времени и опыта, требуя от многих творческих людей постепенного совершенствования. Лучшие инструменты всегда будут развиваться таким образом. Инструменты также могут выйти из употребления, поскольку потребность в них уменьшается, или их заменяют чем-то более эффективным - классическим примером являются глючные кнуты, но обычно это происходит незаметно для нас! Когда перестали ставить подножки на автомобили? Нет, не надо сразу звонить! Очевидно, что культура и инструменты, которые мы используем, тесно взаимосвязаны - у нас есть четкие представления о том, какой инструмент является правильным для данной работы, но в другой культуре на самом деле может быть другое определение того, что это за работа... На Западе мы считаем использование ножа и вилки "правильным" способом употребления пищи - несколько веков назад мы протыкали ее острием кинжала. Ножи и вилки, в свою очередь, означают, что приемлемая западная еда может включать в себя несколько очень больших кусков мяса или даже половину птицы. На Востоке, с другой стороны, люди очень давно используют палочки для отбивки, для чего необходимо, чтобы еда подавалась небольшими кусками. Обратите внимание, что выбор инструментов также помогает определить, какая часть сервировки выполняется посетителем, а какая - поваром за кулисами.
Еще одна вещь, которую мы должны учитывать, - это необходимость иметь возможность использовать инструмент в непредвиденных ситуациях. Полезный инструмент не должен быть слишком ограничивающим в способах его использования - люди всегда будут думать о большем количестве способов использования инструмента, чем когда-либо мог представить его первоначальный дизайнер. Уэйн Стивенс (1991) рассказывает историю о бортпроводнике, который использовал слуховой аппарат (тот маленький пластиковый стетоскоп, который вы подключаете к подлокотнику кресла), чтобы завязать занавески. Элегантный? Нет. Эффективно? Да! Мы не хотим делать молоток настолько умным, чтобы его можно было использовать только для гвоздей... Другой пример: почему некоторые функции UNIX (tm) имеют неочевидные имена? Известны случаи, когда инструмент изначально разрабатывался для одной работы, но люди обнаружили, что он даже более полезен для выполнения некоторых функций, которые первоначальный дизайнер не предвидел. Фактически это свидетельство надежности этих инструментов. Мы столкнемся с подобными примерами в FBP.
Подобно тому, как в приготовлении и потреблении еды есть две роли: повар и обедающий, в разработке приложений FBP есть две различные роли: создатель компонентов и пользователь компонента или разработчик приложения. Конструктор компонентов определяет спецификацию компонента, которая также должна включать ограничения на формат IP входящих данных (включая IP опций) и формат выходных IP. Спецификация не должна описывать внутреннюю логику компонента, хотя атрибуты иногда "просачиваются" из внутреннего во внешнее (ограничения на использование обычно бывают этого типа). Разработчик приложения создает приложения, используя уже существующие компоненты, или, если нужных нет, укажет новый компонент, а затем позаботится о его создании.
Разработчики компонентов и пользователи, конечно, могут быть одними и теми же людьми, но здесь задействованы два очень разных типа навыков. Это чем-то похоже на дизайнера недавно появившейся популярной игры, который признал, что не очень быстро ее решал - его умение заключалось в разработке игр, а не в том, чтобы играть в них. Разделение между производителями и пользователями настолько широко распространено в реальной жизни, что мы не обращаем на него никакого внимания, пока оно не исчезнет. В промышленности, как указывает Уэйн Стивенс, мы считаем само собой разумеющимся идею о том, что авиастроители не строят свои собственные стулья - они передают их в субподряд производителям стульев, которые, в свою очередь, передают ткань в субподряд производителям текстиля и так далее. Напротив, мир обычного программирования таков, как если бы каждый строитель проектировал свои собственные гвозди, пиломатериалы и гипсокартон с нуля. Поговорим о "изобретении колеса" - при разработке обычных приложений мы изобретаем резину, гайки и болты и даже форму колеса!
Хочу немного поговорить о том, как разрабатываются полезные компоненты. Маловероятно, что они возникнут из чистого подхода "сверху вниз" или из чистого подхода "снизу вверх". В первом случае вы не обнаружите гипсокартон, постепенно разбирая архитектурный чертеж дома. Во втором люди, которые придумывают полезные компоненты, должны быть готовы подвергнуть их тщательному тестированию в реальных жизненных ситуациях. Даже после того, как это будет сделано, ничего может и не выйти. Никто в отрасли не стал бы делать ставку на какой-нибудь непроверенный инструмент, который никогда не тестировался в полевых условиях (ну, как правило), и тем не менее мы часто делаем это при разработке приложений. Еще одна рекомендация Уэйна Стивенса - не создавать универсальный инструмент, пока вы не обнаружите, что делаете одно и то же три или четыре раза. В противном случае вы можете потратить много времени и усилий на функции, которые никто никогда не будет использовать, и можете оказаться не в состоянии отвечать на запросы клиентов о функциях, которые им действительно нужны.
В FBP многие базовые компоненты имеют аналоги в области, которая уже малоизвестна, но в течение ряда лет была очень продуктивной по сравнению с обобщенными компонентами, а именно, в машинах Unit Record. В то время у нас были специализированные машины: сортировщики, табуляторы, подборщики и т.д. И люди научились связывать их (параметризовать) и очень эффективно создавать приложения. И вам не нужно было иметь высшее образование, чтобы приложения работали. Фактически, однажды я придумал, как решить проблему с коммутационной панелью табулирующей машины, прямо в ванне, по телефону, мокрый, даже без заметок или схемы, на которую можно было бы взглянуть!
Подобно тому, как Unit Record машины работали с потоками перфокарт, соответствующие компоненты FBP работают с потоками IP. Назовем эти компоненты "потоковыми". Примеры таких компонентов:
- sort
- collate
- split
- replicate
- count
- concatenate
- compare
Все они обладают тем свойством, что обрабатывают потоки данных и требуют очень мало информации о формате входящих потоков данных. Обычно они имеют четко определенные независимые от приложения функции.
Мы могли бы расширить список некоторыми компонентами общего назначения, которые доходят до уровня полей данных, но все еще не "понимают" бизнес-логику. Одним из таких компонентов может быть компонент обобщенного преобразования. Я считаю, что такой компонент, правильно параметризованный, на самом деле мог бы выполнять большую часть обработки в бизнес-приложении. Нан Шу из IBM в Лос-Анджелесе много писала о языке, который она называет ФОРМАЛЬНЫМ (Shu 1985) - его функция состоит в том, чтобы принимать описания файлов и преобразований между ними и использовать их для автоматического преобразования. Она обнаружила, что большая часть бизнес-обработки состоит из перемещения данных, изменения их кодирования и выполнения поиска в таблицах, например одно приложение может использовать номер для каждого штата США, а другое - двухсимвольное сокращение. Это говорит о том, что другим типом функций в этом же классе является обобщённая функция поиска по таблице, и на самом деле мы создали несколько таких для DFDM.
Существует еще один общий класс компонентов, известный как "технологически зависимые". Для создания этих компонентов обычно требуются специальные знания, но после создания их могут использовать люди, не обладающие такими техническими навыками. Таким образом, они заключают в себе специализированные знания. Обычно они пишутся на языке более низкого уровня. Несколько лет назад у нас был интересный пример этого: у нас был человек, который был экспертом по бумажной ленте. Бумажная лента была носителем информации со своими причудами. У неё есть специальные коды для различных целей и, в частности, есть соглашение об исправлении данных (вы пробиваете все дыры в специальном символе, который затем обрабатывается так, как будто никакого символа там вообще не было). Этот человек смог написать некоторые компоненты, которые генерировали обычные IP, так что никакому другому компоненту в приложении не нужно было знать, что вход был бумажной лентой. Вы можете создать и отладить приложение, используя обычный ввод-вывод, а затем, после того, как оно заработает, вы можете отключить модуль чтения и заменить его устройством чтения с бумажной ленты. Это, в свою очередь, означало, что тестирование могло проводиться без необходимости тестировщику монополизировать дефицитное (и медленное) оборудование.
Двумя наиболее широко используемыми технологически зависимыми компонентами являются "Последовательное чтение" и "Последовательная запись". Как и следовало ожидать из названий, они преобразуют записи файлов в IP и IP в записи файлов соответственно. Соответствующая пара компонентов чтения / записи может использоваться для кодирования и декодирования любого желаемого формата файла. Например, вы можете решить, что используемый вами носитель настолько дорог, что вы хотите сжимать данные по мере их хранения и расширять их по мере извлечения. Другой полезной парой функций может быть шифрование / дешифрование. Фактически, любая пара компонентов чтения / записи может рассматриваться как воплощение организации данных. Обобщая эту мысль, пара компонентов последовательного чтения / записи обеспечивает преобразование между форматом, подходящим для обработки, и линейным форматом на некотором носителе. Например, мы создали пару чтения / записи, которая была специализирована для выгрузки древовидных структур на линейный носитель и последующего их восстановления.
Возможно, вы уже заметили, что компоненты очень часто входят в согласованные пары, например разделение/объединение, чтение/запись, сжатие/расширение, шифрование/дешифрование и т.д. Это характерно для многих компонентов FBP - то, что один компонент делает, другой отменяет. Фактически, комбинация компонента и его инверсии в должна приводить к потоку, идентичному исходному входному потоку, точно так же, как в математике умножение числа на его обратные результаты в единицу или составление функции с ее обратными результатами в функции идентичности.
Использование отдельных процессов чтения и записи не только дает разделение между логикой и вводом-выводом, что рекомендуется большинством методологий разработки приложений, но и фактически сокращает затраченное время. Причина этого удивительного результата в том, что в FBP процесс ввода-вывода, который должен ждать ввода-вывода, приостанавливает только себя - другие процессы продолжаются. Это означает, что приложения FBP обычно используют столько процессорного времени, сколько им позволяет операционная система. О производительности мы поговорим позже.
Еще одна интересная группа компонентов, созданная на основе Unit Record, - это компоненты, связанные с генерацией отчетов. К ним относятся такие функции, как разбиение на страницы и создание заголовков и оснований страниц, а также подсчет и подведение итогов, перекрестное основание и другие функции создания отчетов. Отчеты очень часто являются основным средством связи между приложением и людьми, которые его используют, и важность этих средств для среднего бизнеса подтверждается замечательной долговечностью RPG от IBM, которая, хотя и часто считается устаревшей, все еще удовлетворяет реальную потребность на рынке. Позже в этой книге я опишу компонент создания отчетов, который широко использовался в нашем магазине.
Хорошим ориентиром для функциональности компонента является то, что его спецификация не должна превышать около страницы. Некоторые эксперты FBP зашли так далеко, что заявили, что краткое изложение функции компонента не должно превышать одного абзаца и не должно содержать в себе слова "и". Еще одна рекомендация, которую мы сочли полезной, заключается в том, что обобщенные компоненты не должны иметь более 4 портов (порта-массивы считаются за один порт). Конечно, эти рекомендации не являются взаимоисключающими, и они всего лишь принципы - некоторые компоненты объединяют настолько много функций, что их параметры по сути являются мини-языками, но их полезность может перевесить любое неудобство параметризации.
Последняя категория компонентов - это "бизнес-компоненты". Они воплощают бизнес-правила и должны быть относительно простыми, особенно если вы использовали другие категории компонентов, насколько это возможно. Мы можем представить бизнес-компоненты для разных сфер бизнеса - банковского дела, нефти и газа и так далее. Некоторые будут более математическими, другие - менее. Во всех случаях они представляют собой знания какого-либо бизнес-эксперта.
После функциональности одним из основных факторов, которые необходимо учитывать при проектировании бизнес-компонентов, является вероятность изменений. Есть разновидности бизнес-логики, которые практически никогда не меняются, а есть те что меняются каждый раз при запуске. Примером последнего может быть логика создания отчета о налогооблагаемой прибыли работника в конце года. Его меняют каждый год и запускают один раз в год. Было бы очень хорошо, если бы наши правительства могли отправлять один компонент многократного использования каждый год, который затем компании могли бы просто включить в свои собственные программы расчета заработной платы. Это также возвращает нас к вопросу о ролях: кто устанавливает новый модуль? Персонал, занимающийся разработкой приложений или операционный персонал? В первом случае у вас есть постоянная потребность в разработчиках приложений на неопределенный срок; Если второе, можете ли вы быть уверены, что новый компонент будет должным образом протестирован? С другой стороны, учитывая отставание в работе, с которым обычно сталкивается разработка приложений, то, что может быть просто загружено и запущено оперативным персоналом, безусловно, является привлекательным.
Было бы полезно, если бы такой компонент выполнял как можно больше проверки своих входных данных, чтобы убедиться, что он используется в правильном контексте. В идеале компонент никогда не должен давать сбой - на практике, конечно, почти невозможно предотвратить разрушение одним компонентом данных другого, но, безусловно, можно добавить логику проверки для защиты от (скажем) ошибок формата данных. Многоразовый модуль также может потребовать, чтобы входящие данные были помечены определенным дескриптором. Затем, если требуемый формат данных изменится, вам просто нужно изменить имя дескриптора. Имена дескрипторов обычно являются частью спецификации повторно используемого компонента, так что это очень хорошо подходит.
Вышеупомянутое обсуждение на самом деле является еще одной формой старых дебатов о сравнении времени компиляции и времени выполнения. В FBP время компиляции бывает двух видов: на уровне компонентов и на уровне сети. Фактически параметры могут быть указаны внутри составного компонента и при этом оставаться вне элементарного компонента, которым они управляют! Я предсказываю, что в конечном итоге большая часть бизнес-логики будет воплощена в правилах, содержащихся в базах данных правил. Такие правила, написанные на подходящем языке, затем могут быть изменены людьми, не входящими в обычную группу разработчиков приложений. Эти правила могут даже не быть выражены в том, что программист распознал бы как язык программирования. Предшественником этого является IBM Patient Care System, в которой удивительное количество системной логики (включая макеты экранов) было представлено в виде таблиц, предназначенных для обновления старшим клерком или медперсоналом. Это было очень эффективно, поскольку обычно это были люди, которые должны были использовать систему и имели наибольший опыт работы с ней. Снова мы видим отдельные роли разработчика приложения и пользователя приложения. Если вас смущает такой контроль в руках конечных пользователей, либо внедрите системы авторизации, чтобы убедиться, что только нужные люди могут изменять ключевые данные, либо укажите правила в виде таблиц, жестко закодированных в определении приложения, но вне компонентов, которые относятся к ним. Таким образом, контроль остается за группой разработки приложений, но системы становится намного проще изменять и отлаживать. Однако нам действительно следует отказаться от требования, чтобы отдел DP выполнял всё обслуживание системы.
Если я прав в, что в конечном итоге мы увидим, что всё больше и больше бизнес-логики либо будет встроено в повторно используемые компоненты, либо зафиксируется в виде явных правил на диске, тогда роль текущих языков "более высокого уровня" в будущем должна уменьшиться. По нашему опыту мы обнаружили, что при наличии мощного набора повторно используемых компонентов люди будут делать все возможное, чтобы избежать написания кода HLL. В большинстве случаев более низкая производительность не имеет значения - в отчете Кендалла (1977) время выполнения средней программы сравнивается с человеко-месяцами, необходимыми для ее разработки. Программы, на разработку которых уходило 6 человеко-месяцев, могли выполняться в течение нескольких минут на протяжении всей своей жизни. Таким образом, в большинстве случаев незначительное увеличение машинного времени не имеет значения. Только в случае регулярного выполнения длительных заданий имеет смысл выполнять настройку производительности, и, как мы увидим в следующей главе, гораздо лучше настроить приложение FBP, чтобы выяснить, где ваши настоящие узкие места, чем пытаться угадать заранее и тратить время на оптимизацию кода, который не сильно влияет на производительность системы. На самом деле существует несколько способов тюнинга производительности в FBP-средах, выясним только сперва, в чем реальное преимущество.
Человеческое время гораздо важнее процессорного, и фундаментальный вопрос - на самом деле, как лучше всего тратить ценное человеческое время. Принимая решение о разработке нового компонента, вы должны принять во внимание ожидаемую отдачу от ваших инвестиций (сокращенно "ROI"). Каждый новый компонент должен быть задокументирован, протестирован, поддерживаться, рекламироваться и включаться в учебные материалы (ну, в идеале). Неудивительно, что наш опыт работы с FBP показывает, что разработчики приложений, использующие FBP, избегают написания нового кода - будучи ответственными людьми, они осознают бремя, которое они берут на себя, когда начинают кодировать новый компонент. Однако этого осознания недостаточно - мы должны изменить экономику ситуации. Код - это статья затрат, как указали Дейкстра и другие, и тот, кто увеличивает общий объем кода, когда это не оправдано, будет стоить вашей компании денег сейчас и в будущем. Я начал предлагать, только наполовину в шутку, что программистов следует "наказывать" за каждую строку кода, которую они пишут! На самом деле некоторые улучшения программы предполагают удаление кода - отрицательная производительность?! Неоднократно отмечалось, что люди будут изменять свое поведение в соответствии с тем, как вы их измеряете - и компании, которые все еще измеряют производительность с помощью "Kloc" (тысячи строк кода), получают то, что заслуживают! И наоборот, тот, кто производит полезный компонент многократного использования, повышает продуктивность всех своих пользователей и заслуживает вознаграждения - некоторые компании уже начали это пробовать - ключевое слово, конечно же, "полезный". Н.П. Эдвардс, о котором я упоминал в предыдущей главе, сыграл ключевую роль в том, что IBM перешла на детали многократного использования в области аппаратного обеспечения, и он сказал мне, что ключевой прорыв в этой области также заключался в изменении экономики разработки аппаратного обеспечения.
А вот кто много говорил и писал о важности повторного использования - так это Т. Каперс Джонс (например, Jones 1992) - он также был осведомлен о моей работе в течение нескольких лет и поддерживал ее. Он активно продвигал использование независимых от кода метрик, таких как теперь хорошо известные функциональные точки Аллана Альбрехта, для измерения производительности и проделал большую работу по возможности повторного использования для снижения затрат на разработку приложений.
Как мы узнаем, полезен ли инструмент? Единственный способ - измерить его использование. Будут ли люди использовать это? Они сделают это, если он умещается в руке, и если вы окажете поддержку. Это, в свою очередь, означает, что у вас должна быть инфраструктура, позволяющая вашей компании использовать преимущества этой новой технологии, а также меры и стимулы, чтобы побудить людей двигаться в правильном направлении.
Возникает и обратный вопрос: а что, если инструмент "не идеален"? Как и в случае с настоящими инструментами, нет идеального инструмента - есть только инструменты, которые более или менее удобно подходят для вашей руки. Как и многие программисты, склонные к перфекционизму, у вас может возникнуть соблазн отложить выпуск чего-то на рынок, потому что вы чувствуете, что это еще не закончено. Возникает вопрос: а насколько это полезно? Вы всегда можете улучшить его с течением времени, при условии, что вы сохраните стабильные интерфейсы (или предоставите "порты расширения", но сохраните восходящую совместимость). Фактически, по прошествии некоторого времени вы можете обнаружить, что расширения, которые действительно нужны людям, совсем не то, что вы ожидали. Поскольку мы надеемся, что к этому времени ваш многоразовый компонент будет широко использоваться, важно, чтобы вы разрешили расширение, сохраняя при этом восходящую совместимость. В FBP в этом помогает то, что порты названы; также параметры (описанные в следующей главе) должны быть разработаны с возможностью расширения. Параметры могут быть в строковом формате с разделителями или, если форма фиксирована, рекомендуется вставить несколько нулевых битов - их всегда можно изменить на единицы, чтобы указать, что существует часть расширения.
Другой вид модификации, которая время от времени будет происходить с вашими модулями, - это исправление ошибок. Безусловно, приятно знать, что вы улучшили компонент, который многие люди используют или будут использовать, и вы можете подумать, что ваши пользователи будут приветствовать это изменение с распростертыми объятиями. К сожалению, некоторые из ваших пользователей, возможно, приспособились к ошибке, и их нужно будет убедить в том, что вы лучше знаете, что для них подходит. Еще пользователи могут воспользоваться недокументированными фичами. Я говорил об инструменте, который подходит для руки - он может поместиться в руке, даже если в нем есть ошибка. Одна команда обнаружила ошибку в одном из компонентов DFDM, но нам не сообщили. Когда мы исправили её, их программы перестали работать! Думаю, какое-то время они были возмущены, пока не осознали, что произошло. Нам пришлось потратить некоторое время, чтоб объяснить, что всем будет намного лучше, если мы исправим ошибку, а не оставим все как есть! Есть очень важное правило, которое вы должны внушить своим пользователям: если что-то не задокументировано, не доверяйте этому. IBM узнала ценность этого на горьком опыте и приняла эту мудрость с того дня, как какой-то умный пользователь обнаружил недокументированную инструкцию на одной из машин серии 700. Когда IBM начала делать недопустимые инструкции, приводящие к возникновению исключений, мне сказали, что довольно много программ в университетах и других местах перестали работать!
Следующий вопрос: как люди узнают об этих компонентах? Существует распространенное заблуждение, что повторно используемые компоненты не работают, если у вас нет тщательно продуманного каталога, который люди могут опросить, чтобы найти нужный инструмент. С другой стороны, Уэйн Стивенс указал, что большинство примеров повторного использования в повседневной жизни происходит очень естественно, без какого-либо каталога. Мы знаем наизусть большинство вещей, которыми обычно пользуемся. Допустим, вы зашли в строительный магазин, потому что хотите прикрепить деревянную основу к керамическому горшку - вы будете знакомы с полдюжиной видов крепежа: клей, гвозди, шурупы, заклепки и т.д. В большинстве случаев вы будете знать какой именно клей использовать. В этом случае, допустим, вы не совсем уверены, что лучше. Вам по-прежнему не нужно сканировать весь магазин - в большинстве случаев вы можете подойти прямо к полке и начать читать этикетки. Что делать, если вы не знаете, куда идти в магазине? Вы спрашиваете продавца в магазине, который, в свою очередь, может передать вас кому-то, кто является экспертом в определенной области. Если ваши требования действительно необычны, клерку, возможно, придется обратиться к каталогу, но это, скорее всего, редкий случай. Дело в том, что для эффективного повторного использования каталоги не нужны, хотя они, безусловно, могут помочь.
Чтобы попытаться измерить прирост производительности, который мы получили от DFDM в IBM Canada, мы вели статистику по количеству повторного использования по ряду проектов. Цифры для трех проектов показаны на следующей диаграмме (числа относятся к компонентам):
| ПРОЕКТ | Тип | Уникальный | Вхождения | Фактор переиспользования | 1 / Показатель заслуг |
|---|---|---|---|---|---|
| A | Проект | 133 | 184 | 1.4 | 3.7 |
| Общее назначение | 21 | 305 | 14.5 | ||
| Total | 154 | 489 | 3.2 | ||
| GP/T | 0.14 | 0.62 | |||
| B | Проект | 46 | 48 | 1.0 | 7.7 |
| Общее назначение | 17 | 306 | 18.0 | ||
| Total | 63 | 354 | 5.6 | ||
| GP/T | 0.27 | 0.86 | |||
| C | Проект | 2 | 54 | 27.0 | 135.0 |
| Общее назначение | 8 | 216 | 27.0 | ||
| Total | 10 | 270 | 27.0 | ||
| GP/T | 0.80 | 0.80 |
В этой таблице "проект" означает компоненты, закодированные специально для рассматриваемого проекта, а "общее назначение" означает готовые компоненты (уже доступные и официально поддерживаемые). "Уникальный" означает отдельные компоненты (отдельные фрагменты кода), а "вхождения" означает общее количество процессов (экземпляров компонентов или сетевых узлов). Таким образом, в проекте A использовалось 154 отдельных компонента, из которых 21 был выпущен с полки, но на него приходилось 305 из 489 процессов (около 3/5). GP / T означает общее назначение как долю от общего количества, и интересно сравнить GP / T для уникальных компонентов с GP / T для вхождений компонентов.
"Показатель заслуг", если использовать фразу Боба Кендалла (Kendall 1988), рассчитывается следующим образом: количество закодированных в проекте компонентов, деленное на общее количество процессов. Поскольку первая цифра представляет объем работы, которую должен выполнить программист (помимо объединения сети), а вторая цифра представляет объем работы, которую выполняет программа, мы посчитали, что показатель качества является довольно хорошей мерой. объем реального повторного использования. DFDM использовался в этом магазине около 2-3 лет, и у нас было около 40 готовых компонентов, так что довольно много общих задач можно было выполнять без необходимости кодирования каких-либо новых компонентов. Однако, когда программисту приходилось кодировать компоненты, вы заметите, что довольно часто этот код также можно было повторно использовать, давая коэффициент повторного использования больше 1 (в Project C был коэффициент 27,0). В третьем примере на приведенной выше диаграмме программисту нужно было написать только 2 компонента, хотя в его программе было 270 отдельных процессов. (Вы, наверное, догадались, что этот проект включал запуск 27 разных файлов через одни и те же 10 процессов - так что он проделал большую работу с очень небольшими затратами усилий).
(*В "Figure of Merit" Боба Кендалла - чем меньше, тем лучше. В этой версии я показал обратное, поскольку кажется более интуитивным, когда большее число указывает на лучшее повторное использование.)
Хотя сначала мы думали, что этот последний случай был всего лишь причудой, мы нашли довольно много приложений, которые не сильно отличались (например, письмо Реджа, цитируемое во введении).
Вот некоторые цифры из оценки DFDM, приведенные в начале этой главы:
- Все функции пилотного приложения DFDM выполняются 30 уникальными сопрограммами (это количество сопрограмм, с которыми необходимо ознакомиться человеку, чтобы понять функцию приложения).
- В общей сложности 95 экземпляров этих 30 сопрограмм составляют приложение, что обеспечивает коэффициент повторного использования 3:1.
- Эти 95 сопрограмм используются за счет использования подсетей и сетей CNS [Compiled Network Specification] для выполнения эквивалентной работы 225 "сопрограмм без использования заемных средств" (unleveraged coroutines).
Некоторые компании пытались побудить людей писать обобщенный код, предлагая им деньги или похвалу. Я хотел бы дать им один совет: вам нужно отслеживать не количество написанных кем-то компонентов, а то, как часто они используются. Уместная аналогия - система гонораров в издательском деле. Каждый раз, когда используется модуль, автор должен получать какой-то жетон, будь то деньги или признание. Это гарантирует, что ваша компания не накопит коллекцию замечательных гаджетов Руба Голдберга, которые будут лежать на полке и пылиться.
Допустим, вы все убеждены в том, что код многократного использования - это правильный путь - как мы можем внедрить его в фирме? Вы обнаружите (если только все ваши люди не суперальтруисты), что самый большой враг повторного использования - это не технологии, а человеческая психология. В то время как многие люди с энтузиазмом примут новые идеи, другие будут им сопротивляться, и по разным причинам. Люди, которые научились доставлять приложения в сжатые сроки, очень часто чувствуют, что они должны любой ценой сохранять контроль над всем, что они используют, и на самом деле весь их опыт научил их, что этот подход работает. Компоненты, разработанные другими, будут на своем критическом пути, и они будут находиться между желанием уменьшить свои собственные усилия за счет использования предварительно протестированных компонентов и опасением, что компоненты, на которые они полагаются, не будут готовы вовремя или сломаются. Не будут не поддерживаться при изменении окружающей среды. Они должны убедиться, что кто-то поддержит эти компоненты - при необходимости, круглосуточно. Это может быть необязательно технически, но может быть очень необходимо психологически!
Другой источник сопротивления состоит в том, что некоторые программисты любят биты и байты и не хотят становиться простыми объединителями предварительно закодированных компонентов! У этих людей есть своя роль - писать компоненты для спецификаций. Как мы уже говорили выше, появляются две разные роли: разработчики компонентов и пользователи компонентов. На мой взгляд, последним нужны навыки, очень похожие на те, которые требуются аналитикам. Им необходимо иметь возможность разговаривать с пользователями, собирать требования и даже создавать системы или прототипы систем. Для более сложных деталей или деталей, которые должны работать лучше, они могут передать детали производителям компонентов. Это область, в которой могут проявить себя программисты ("Мерлины", как их называет мой друг). В некотором смысле компонент становится воплощением их конкретных навыков или знаний. Я обнаружил, что имеет смысл "строже" относиться к внешним спецификациям и "слабее" к тому, как код построен внутри. Это позволяет им выражать свои творческие способности, продолжая при этом служить потребностям организации в целом. Конечно, это не должно быть написано настолько плохо, чтобы оно не работало хорошо! И компонент обязательно должен выполнять функции в соответствии со спецификациями! Как только это будет подтверждено, ваша единственная забота - ремонтопригодность. Обобщенный код должен быть поддерживаемым, но вам, вероятно, не нужно контролировать формат каждой внутренней мелочи!
Однажды программист сказал мне: "Мне не нравится DFDM, потому что я не получаю дампов"! В то время я понял, что это означает, что, поскольку программы, созданные с использованием FBP, не дают сбоев, программистам трудно понять, как они работают. Незнание, как работает двигатель вашего автомобиля, заставляет вас нервничать? Вероятно, это действительно так влияет на некоторых людей, но большинству из нас все равно. Позже я понял, что это также поднимает очень фундаментальный вопрос о доверии - если пользователи пакета не доверяют пакету или его поставщику (на самом деле то же самое), они не будут счастливы... Доверие хрупко: трудно наращивать и легко повредить.
Предположим, ваша компания убедилась в том, что разработчики не должны продолжать "изобретать велосипед", но, как и большинство компаний, вы достигли только стадии, когда вы поддерживаете библиотеку общих подпрограмм. Как добиться формализованного совместного использования компонентов? Предположим, я узнал, что Джулия работает над модулем, который довольно близок к тому, что я хочу, но требует некоторой доработки в соответствии с моими потребностями. В большинстве магазинов мы даже не знаем, как это назвать. Компании, которые только начали бороться со стандартами именования, часто думают, что имена модулей должны начинаться с кода проекта. Например, если я управляю проектом ABC, то я могу назвать все свои модули ABC-something. Таким образом, мне не нужно беспокоиться о конфликте имен моих модулей с именами других проектов. Даже в имена библиотек часто встроена буква ABC! Итак, даже для того, чтобы найти код, мы обычно должны иметь какое-то соглашение об именах в масштабе всего предприятия. Следующий вопрос: кто занимается модификацией кода и кто за это платит? Что, если расписание Джулии соскользнет и начнет влиять на мое расписание? Даже если все будет хорошо, кто будет поддерживать, документировать и поддерживать?
Многие авторы о повторном использовании соглашаются, что единственное решение - создать независимый отдел для написания и поддержки компонентов. У этого отдела должно быть достаточно ресурсов, чтобы выполнять свою работу должным образом, что также включает рекламу и продажу своего продукта. Одна из тенденций, которой необходимо противостоять, заключается в том, что такие отделы часто занимаются производством сложных, универсальных инструментов для нескольких пользователей или даже ни для кого - они просто думают, что компонент будет аккуратным, и будут беспокоиться о том, чтобы продать их впоследствии. Помните принцип рентабельности инвестиций: компания в целом получит больше прибыли от множества простых инструментов, особенно если они хорошо взаимодействуют друг с другом, а не от нескольких очень сложных. Поскольку хорошие инструменты часто начинаются как модули специального назначения, которые некоторые другие группы сочли полезными, должен быть путь для продвижения таких специальных компонентов в место, где другие люди могут их найти и положиться на них. У нашего централизованного отдела поддержки программного обеспечения должны быть способы избавиться от новых и интересных компонентов, а затем должны быть способы оценить, заинтересованы ли потенциальные клиенты (иначе зачем тратить столько хлопот?). Он также не должен увлекаться написанием или обновлением сложных инструментов, рынок которых ограничен. Это сервисная организация, поэтому она должна быть ориентирована на качество обслуживания, а не просто группа самозваных экспертов, которые знают, что лучше для всех. Он должен стать предпринимательским, но не исключительно ориентированным на прибыль. Короче говоря, он должен следовать хорошей финансовой и инженерной практике. Если это требует серьезных изменений в структуре вашей организации, вам действительно стоит начать как можно скорее!
Я считаю, что, если компании не начнут привносить инженерные дисциплины в разработку приложений, они не только не смогут в полной мере использовать потенциал компьютеров, но и станут все более и более загруженными бременем обслуживания старых систем. Вы не можете много сделать со старыми системами - я знаю, я видел много из них - но новые системы могут быть построены таким образом, чтобы их можно было поддерживать. Также должна появиться возможность постепенно преобразовывать старые программы в частичную технологию FBP, а не переписывать с нуля. Один мой начальник назвал это "превращением айсберга в кубики льда"!
Я считаю, что все настоящие дисциплины следуют своего рода циклу во времени, который можно представить с помощью следующей диаграммы:
Фрагмент 4.1
Инновации могут быть основаны только на твердом знании того, что было раньше - в противном случае мы обречены заново открывать для себя одни и те же старые концепции. С другой стороны, традиция без инноваций не может привести к прогрессу, а инновации бесполезны, если слово не передано людям, которые могут их использовать. Как я уже отмечал выше, разработка бизнес-приложений практически не изменилась с тех пор, как я начал работать в этом бизнесе в 1959 году, но я действительно верю, что теперь, наконец, мы можем начать видеть перспективы разработки приложений, которые станут настоящей инженерной дисциплиной.