И хотя это может выглядеть как вечная безысходность (неизбежность) Закона Программиста, здесь появляются люди, разрывающие порочный круг деградации, и мы опишем, как это делать с этой точки зрения на программирование как на творческий процесс.
Фундаментальная трудность в сохранении контроля над унаследованными структурами, будь то артефакты стратегии доставки потребителю, возникшие из спецификаций с фиксированной стоимостью амортизации, либо древняя система индексирования CODASYL, которую требуют воссоздать в объектной базе данных -- это время. Иногда это выражается как "стоимость", но время редко имеет цену. Это крайние сроки (deadlines). Нет другого способа избежать крайних сроков, кроме как крикнуть "Волк!". Это реалии коммерции, которыми мы не управляем. Все в порядке -- мы просто думаем об этом реалистично и скорее учитываем это в своей работе, а не используем для оправдания плохого качества продуктов.
Первая точка приложения усилий против крайних сроков -- осознание того, что работа спорится в чистой среде без странных флагов у функций, без противоречивых соглашений о вызовах, без многочисленных соглашений об именовании и прочего барахла. Дни после чистки весомее дней до нее. Поэтому сделайте чистку в самом начале, когда каждый может видеть перед собой большой проект, это время окупится позднее. Вы почти всегда должны делать чистку -- код, который большинство организаций помещают в репозитарии, обычно первый кандидат. И не важно, что он прошел все этапы тестирования. Делайте чистку, проверку на старость и даже не обсуждайте сроки, пока не увидите порядка.
Следует сделать предупреждение -- будьте реалистами насчет того, сколько времени займет чистка. Чем запутаннее клубок, тем больший эффект даст чистка, но тем больше риск, что у вас не будет времени на его распутывание и выполнение работы. Часто полезно задать вопрос: "Насколько сложно поведение этого предмета как черного ящика?" Если ответ: "Не очень!", то вы знаете, что по мере последовательного вычесывания сложности, он ужмется до чего-то простого, даже если вам вообще не видно, куда идти.
Вторая точка приложения усилий исходит из экспоненциального уменьшения сложности программы. Если у вас более ясный алгоритм, минимальная реализация будет проще. Чем меньше у вас кода, тем легче увидеть структуру кода, и уменьшается шанс появления искажающих концепцию ошибок. В то же время, меньшее количество кода означает и меньше возможностей для синтаксических ошибок, описок в именах переменных и т.д. Меньше ошибок -- меньше затраты времени, меньше затраты времени -- меньше тестирования. Это не займет много времени в любой команде из более полудюжины человек для большей части их работы, чтобы опуститься до нанесения увечий взаимного перепатчения, когда доступ к репозитарию станет узким местом. Позволить пропустить вещи через такой процесс на более поздних стадиях -- заложить бомбу с часовым механизмом, которая рванет тогда, когда уже поздно что-то делать. С другой стороны, безумие отбраковки (выбрасывания лишнего) посреди такой ситуации может восстановить спокойствие в оставшиеся дни.
Третья точка приложения усилий -- " дела скунса" (skunkworks), название пошло от названия местечка Skunkworks, основанного корпорацией Lockheed Martin вдали от корпоративного центра, "потому что скунс". [Насколько я слышал, скунс -- это такая вонючка, что даже кошек выворачивает - С.К.] Эта страшная технология может быть использована исключительно инициативными командами по секрету на рождественской вечеринке, либо спровоцирована просвещенным руководством. Как повелось во всей этой работе, мы проясним, почему "дела скунса" срабатывают.
В такой деятельности индустриальной эры, как строительство, имеются физические объекты (кирпичи), с которыми трудно управляться. Вместо того, чтобы нагромоздить кирпичи стопкой, чтобы увидеть, сколько их понадобится для строительства дома, мы подсчитываем их. Эта абстракция от физического к информационному дает нам сверхъестественные способности в обращении с кирпичами. В конце концов у нас становится так много чисел, говорящих о поставках, транспортировке и потребностях, что мы вынуждены организовать наши числа в структуры, чтобы работать с ними. Мы используем электронные таблицы, а абстракция от информационного к концептуальному вновь дает нам сверхъестественные способности.
Выполняя такую работу над информацией, как программирование, мы не начинаем с физического и получаем явное преимущество, когда переходим к информационному. Мы начинаем с информационных требований, списков по пунктам и т.п., и нам приходится обрабатывать их с помощью информационных инструментов. Нам приходится делать это из хороших соображений, таких как информационные контракты с заказчиками, информационные соглашения на собраниях с включенными в наш процесс коллегами. Иногда также мы делаем это из таких плохих соображений, как слишком подробные инструкции информационных технологий по преобразованию кирпичей в область информации, как измерение производительности с помощью строк кода (KLOCS).
Беда в том, что при нормальной работе у нас нет рычагов. Информационное содержимое нескольких минут совещания может быть больше информационного содержимого требований, которые на нем обсуждаются! Как деятельность, выполняемая людьми, собрания не способствуют достижению цели! Мы выигрываем только потому, что мы можем продать наше новое знание много раз, или потому, что в соединении с другими знаниями оно дает существенно больший вклад в процесс.
Это лишает возможности использовать понимание для увеличения власти над информацией. "Дела скунса" иногда выглядят как отказ от процесса в интересах творчества. Ничто не может быть дальше от истины. Необходима высокая пропорция опытных людей, чтобы исключить этот эффект, поскольку, чтобы что-то завершить, они должны положить в основу высокоинформативные динамические индивидуальные процессы. То, от чего отказываются -- это понимание, содержащееся в изнурительном процессе, ради понимания, которым владеют опытные люди. Отсюда проистекает предусловие для "дел скунса". Отказываясь от детализованного процесса, принимают, что риск неизбежен, а потеря личной безопасности компенсируется простыми хорошо определенными целями. Каждый должен осознать, что "дела скунса" могут потерпеть неудачу, надежды могут не оправдать ожиданий, а могут быть соображения, по которым все вернется к традиционным методам управления. Но когда они срабатывают, то срабатывают великолепно!
Все успешные начинания -- "дела скунса". Поэтому есть неудачные начинания. Усилия "дел скунса" могут сменить большой риск потери управляемости [из-за разбухания проекта - С.К.] на малый риск "пионерства" [в смысле быть первым - С.К.]. В таких ситуациях это может оказаться эффективным средством управления риском.
Глава 3. Программист за работой
На одном конце этого спектра расположены продукты COTS (Commertial Off The Shelf - Коммерческие, взятые с полки). Загрузи его, запусти его, работа сделана. На другом -- набор команд процессора, который позволяет нам выжать из железа все, на что оно физически способно. Между этими крайностями располагаются различные промежуточные семантики, которые упрощают поиск взаимосвязей ограничивая семантику.
В этих терминах, язык -- это произвольный набор (ящик инструментов -- kitbag) семантик. Cи - язык, но также и Excel -- язык, как и средства создания интерфейса пользователя (GUI builders). Эти наборы лежат, но не дают никакого намека, как использовать их содержимое. Языки специализируют по проблемным областям, чтобы достигнуть большой вероятности получения более простых взаимосвязей для любой проблемы из выбранной области. Чтобы решить, какую из двух семантик (языков) выбрать, обычно нужно спросить, какая из них требует более простых взаимосвязей (более простой программы), чтобы выполнить работу. За исключением самых тривиальных случаев, это требует знакомства с обоими наборами семантик на практике.
И хотя мы можем получить ясное понимание того, что из себя представляет язык, методология гораздо труднее поддается рассмотрению в таких терминах. Мы предполагаем, что причина состоит в том, что идея "методологии", как ее обычно рассматривают, включает неявные предположения, что это процедурный подход к решению программных проблем, а мы знаем, что это не так. То, что мы можем описать вместо этого, немного иное -- подход.
Подход заключается в совете, даваемом одним опытным картостроителем другому, о том, как лучше всего решать проблему какого-то типа. Это приглашение посмотреть на мир определенным образом, даже если это выражено как процедурный рецепт. Предписание "Получи диаграмму (Data Flow Diagram) изменения начислений по неделям" в книге "Как построить систему печати платежной ведомости" ( How To Build A Payroll System) на самом деле выглядит так "Ограничь рассмотрение до систем с понедельным начислением, и выведи перечень этих начислений".
Это совет для создателя систем печати платежной ведомости, при условии, что все ситуации можно свести к понедельным начислениям. Как и язык, подход получается тем проще, чем больше он специализирован на заданной предметной области. Кроме того, как и язык, подход трудно выбрать правильно без понимания "цен" имеющихся подходов и проблемы. При большом числе умных разработчиков, каждый год пишущих коммерческие (COTS) продукты, которые автоматизируют подход в виде высоко специализированного языка, с которым сможет работать любой дурак, в будущем наиболее вероятным приложением сил для хороших программистов станет изучение более глубоких, перспективных подходов и выработка новых подходов перед лицом новых проблем. Но, вероятно, всегда будут толпы людей, использующих один и тот же подход для ритуального производства еще одной точно такой же бухгалтерской системы для еще одного клиента. Они могут постоянно "переобучаться новым методологиям". Но они есть и останутся клерками, а разрыв в производительности и отдаче между клерками и программистами будет расширяться. Вот что означает быть игроком в эру информации.
Имеются языки, которые специализируются на определенном подходе. Smalltalk требует от пользователя рассматривать мир в виде объектов. Lisp требует применения неудобоваримых манипуляций с лямбда исчислением, которые приводят к появлению "собаки еды" (dog of food), вместо накормленной собаки.
Следует подчеркнуть, что языки объективны, подходы объективны, но методологии - плод нашего коллективного воображения и не существуют. Пренебрежение этим положением и неудачный выбор подхода может привести к ситуациям, в которых критические составляющие проблемы не учтены, поскольку оказывается, что подход их не рассматривает, в то время как тем, кто пытается разобраться в проблемах, вставляют палки в колеса коллеги, которым кажется, что те действуют "непрофессионально", поскольку не "применяют методологию". Это пример барьера между картостроителями и паковщиками.
Интересные методологии состоят частично из подхода, частично из языка. Структурный дизайн Джексона (Jackson Structured Design -- JSD) ограничивает свою область применения проблемами с ясно идентифицируемыми чертами (свойствами) и поэтому в состоянии предложить очень детальную инструкцию, как решать проблемы такого типа. Держите глаза открытыми, и JSD хорошо послужит в своей области. Однако за пределами этой области он может вызвать проблемы, поскольку если у задач нет нужных Джексону черт, то бесконечное латание дыр (kludging) будет делать хорошую систему из плохого понимания. Это не ошибка Джексона, поскольку он никогда не говорил, что JSD -- это ритуализованная панацея для решения всех компьютерных проблем.
На выходе JSD мы видим нечто совершенно неожиданное, артефакт того времени. Джексон описывает, как перейти от его диаграмм к коду, делая это вручную! Он осознает, что он делает, и поясняет, что автоматизм этой работы позволяет нарушить правила структурного программирования и использовать goto. Сегодня он не стал бы этого делать -- он бы просто направил диаграммы в генератор кода, как это многие и делают. Дело в том, что нотацию диаграмм JSD лучше всего рассматривать как язык программирования! Джексон создал язык, который был ориентирован на некий подход к проблемной области.
То же самое справедливо для подходов и языков Буча (Booch), Румбаха (Rumbaugh) и UML (Unified Modelling Language). В действительности, для каждой интересной методологии. В ранних публикациях Буча и Румбаха они не пропускали диаграммы через генераторы кода, но показали, что трансляция большинства диаграмм в большой степени механична. Не переживайте слишком сильно о реализации этих методов вручную -- в целом это несложно!
Создание языка и подхода, более или менее специализированного к какой-то предметной области -- крупное достижение. Поступая таким образом, авторы должны долгое время продумывать, как лучше всего управляться с проблемами, разделять их, исследовать их, смотреть на них с разных точек зрения и в соответствии с этим разрабатывать свой подход или язык. Но многое оказывается запутанным из-за пресловутого языкового барьера картостроитель/паковщик, и приходится отказываться от акцента на творческое мышление, необходимое для построения карты между проблемой и ее языком. Вместо того, чтобы представлять свой подход как структуру и предлагать некоторые эвристики для рассмотрения проблемы в терминах этой структуры, они вынуждены использовать процедурный язык и описывать действия, которые необходимо предпринять, императивно [строгим командным голосом - С.К.]. Если кто-то не обладает даром думать творчески, то естьконструировать мысленную карту своей проблемы посредством размышления и затем исследовать ее, то им не остается выбора, кроме как следовать этим (вероятно, некорректным) указаниям, а их результаты будут существенно зависеть от везения. Джексон тут хорош. Он специфически ограничивает свою область и говорит читателю, какие свойства искать. Читатель начинает с обследования проблемы в поисках (ключевых) признаков. Буч включает интересный раздел, посвященный поиску объектов, которого, если бы только он был выполнен глубоко и широко, достаточно, чтобы сделать путь императивов ненужным, поскольку он опирается на сугубо картостроительные моменты. Наконец, то, как книга Страуструпа (Stroustrup) описывает объектный подход и язык C++ -- праздник стиля, интуиции, структуры, глубины и творчества. Это тяжелая книга, описывающая сложный язык программирования, но она написана великим картостроителем в действии, у которого нет внутренней неразберихи относительно предмета.
Следует отметить еще два момента. Во-первых, работа не заключается в создании кучи невразумительных бумажек, которые никто даже не будет читать, но которые по виду напоминают "конструкторскую документацию". Те, кто выплескивает технические подробности (все слеши и десятичные точки) в основном тексте, вместо того, чтобы поместить их в приложении, если уж это так нужно, просто издеваются над читателями и дискредитируют наше искусство в целом. Используя простой, нормальный язык (включая где необходимо специальную терминологию, но не злоупотребляя ею) расскажите читателю то, что ему нужно знать.
Второй момент касается формата. На любой стадии процесса программирования люди используют понимание, чтобы находить и предлагать паттерны. Если бы они знали, что они собираются найти, у них не было бы работы, поскольку их мог бы заменить настроенный кем-нибудь коммерческий (COTS) продукт. Раз мы не знаем наверняка, что работнику нужно представить, то как мы можем сказать ему, как он это должен представить? Стандартные форматы в процессах не должны восприниматься как догмы. Все приличные процессы в ISO 9001 содержат стандарты размещения необходимых разделов. Используй их соответственно, и если во время написания возникает структура документа, можно сделать вставку в План Управления Проектом, чтобы описать выбранный формат. Вот и вся суть ISO 9001.
Требования пользователя
Недавно возник большой интерес к "Реинженирингу бизнес-процессов" (`Business Process Re-Engineering' -- BPR). Это практика изучения бизнес-процессов для определения, можно ли их улучшить, и часто это необходимо сделать просто потому, что со временем изменилась природа бизнеса организации. Иногда превозносят точку зрения, что программная инженерия всегда включает значительный компонент BPR, поскольку в противном случае потребитель обнаружит, что компьютерная система автоматизирует бизнес-процесс, не учитывающий появление компонентов, которые руководство реализовало в ответ на потребности бизнеса, и систему ожидает крах. Таким образом, первая обязанность инженера-программиста -- помочь потребителю понять природу их собственных требований. В примере простейшей программы -- это кристаллизация желания из общего ощущения дискомфорта в специфическую потребность в большей освещенности. Инженер-программист руководствуется в этой работе дисциплиной, накладываемой необходимостью писать программу для компьютера. В работающем коде невозможно скрыть неоднозначности, как это можно сделать в текстовом отчете. Полезные ТП, таким образом, составляют настолько ясное понимание потребностей пользователя, насколько это возможно в начале проекта, как это понято пользователем и инженером, на языке пользователя. ТП обязательно потребуют уточнения в дальнейшем, по мере того, как дисциплина программирования выявит неоднозначности, независимо от того, будут ли эти поправки включены в документ или нет.
Причина, которая вызывает большую путаницу -- двоякое назначение ТП. С точки зрения инженера ТП должны быть живым документом, но из соображений коммерческих и правовых он занимает место эталонного документа на все время работы над проектом. Эти две цели совершенно различны. Когда они смешиваются, мы получаем комедию инженеров, не обремененных юридическими знаниями (что на самом деле так), пытающихся написать "Декларацию независимости", в то время как критические моменты бизнес процессов остаются неисследованными.
Иногда единственный способ выйти из этого положения -- написать два документа. Один определяет контрактный минимум и, если придерживаться некоторых методик, может быть с успехом написан полностью пользователем. Другой -- это живой, внутренний документ, который говорит нам, что же "приведет пользователя в восторг". Это то, чем мы стараемся руководствоваться в его интересах. Как удовлетворить пользователя, если единственной подсказкой как это сделать, является нечто, служащее нашим коллегам из коммерческого подразделения на поле закона? Рамки, до которых потребитель видит "настоящие ТП" зависят от коммерческих соображений.
Будьте очень осторожны по отношению к "средствам интегрированного отслеживания свойств", призванных получить ваши ТП и пропустить их положения через проектирование и тестирование, превращая в код. Такие средства часто забывают, что требования можно удовлетворить не делаячто-то, что ряд требований может быть реализован в нескольких сегментах кода, без прямого соответствия между требованиями и сегментами, и что очень трудно протестировать важные общие требования отдельными тестовыми инструментами. Это не значит, что такими инструментами не следует пользоваться -- для задач конфигурирования и ввода данных они подходят прекрасно. Некоторые даже могут отследить свойства отдельных групп классов для GUI. Но для обычных требований черного ящика на "уровне пользователя" они искажают то, что могло быть написано в ТП, или навязать стиль разработки, требующий утомительного ручного кодирования отдельных свойств, вместо использования абстракций везде, где это возможно.
Требования к программному обеспечению
Если ТП описывают требуемую систему на языке пользователя, то ТПО описывают ее на языке инженера. Поэтому в этом документе сначала могут оказаться расчеты размера системы. Что особенно характерно для современных объектных методологий, потребность в ТПО уменьшилась, поскольку архитектура будет состоять из прикладных классов, у которых ясные взаимосвязи с языком ТП. В этой ситуации, ТПО и АП могут быть объединены.
Говорят, скульптор думает о своей законченной работе, как о заключенной внутри глыбы камня или куска дерева, и которую нужно оттуда извлечь, отсекая лишнее. Это помогает. Точно так же, мы можем представить себя глядящими глазами пользователя на наше творение в один из дней в будущем. Если мы смотрим на него используя свойства (черты) системы, мы можем спросить себя: "Как это должно быть реализовано?" Тогда очень легко получить описание потребностей пользователя на языке инженера-программиста.
Архитектурный проект
Если уже приходится делать работу, заключенную в АП, то может показаться, что самая тяжелая работа по проектированию к этому моменту завершена. Есть также большой соблазн вообще уклониться от написания Архитектурного Проекта. В то время как мы умышленно опускаем детали проекта в АП, иногда чтобы удовлетворить требованиям независимости от платформы (portability), иногда просто чтобы развеять туман вокруг большой картины, мы по-прежнему должны быть уверены в том, что наш проект действительно реализуем. Инженер должен знать по крайней мере один приемлемый способ реализации каждого свойства до того, как искать его, и должен подумать о концептуальной целостности кода, требуемого для реализации этих свойств.
Утверждение, что архитектурный проект не должен касаться детального проекта, мы считаем ошибочным. Если мы не можем рассматривать реализацию, мы не можем быть хорошими инженерами, поскольку любой идиот может спроектировать нереализуемое. Только учитывая реализацию мы обнаруживаем ограничения наших проектов и находим разницу между хорошим и плохим. Мы способны увидеть альтернативы, сравнивать их и выбирать лучшее. Если мы не можем учитывать реалии реализации, то один дизайн так же хорош, как и другой, и эта критическая стадия познания становится упражнением в письме, кто быстрее может "написать документ", нимало не задумываясь над написанным!
АП -- это дидактический документ. Он учит читателя тому, как посмотреть на проблему и решение так же, как смотрел автор.
Детальный проект
ДП -- это записка в бутылке. Он говорит читателю о том, как автор планировал реализацию, поэтому код можно понять. Детальность изложения должна прояснить те места, которые остались за кадром в АП, и привести читателя в точку, где уже должен быть сам код. Иногда, это объяснение может быть выражено псевдокодом, но не обязательно. Следует допускать возможность исправления ДП. Во время реализации будут возникать такие детали проекта, как организация кода в модули. Если такие детали не передать с помощью ДП нашим коллегам, то как еще это сделать? Это простое упущение вызывает в дальнейшем слишком много ненужных проблем, поскольку инженеры посчитают составляющие системы хорошо документированными, только в случае, если они знали, с чего начать! Окончательный вариант ДП должен говорить последователям, что они должны знать, чтобы понять систему и изменить ее.
План тестирования
План Тестирования -- наиболее чувствительный к контексту тип документа, но очень полезно руководствоваться следующими наблюдениями в рамках требований ситуации. Стратегическая цель тестирования -- напрячь систему. Не будет никакой пользы, если делать тестирование хаотично, поэтому необходимо найти одну или несколько моделей системы, которые могут дать нам индикатор для типичных и стрессовых ситуаций. Таким образом, полезная структура -- описать модель, выяснить стрессовые условия и затем перечислить их.
Фундаментальная трудность в сохранении контроля над унаследованными структурами, будь то артефакты стратегии доставки потребителю, возникшие из спецификаций с фиксированной стоимостью амортизации, либо древняя система индексирования CODASYL, которую требуют воссоздать в объектной базе данных -- это время. Иногда это выражается как "стоимость", но время редко имеет цену. Это крайние сроки (deadlines). Нет другого способа избежать крайних сроков, кроме как крикнуть "Волк!". Это реалии коммерции, которыми мы не управляем. Все в порядке -- мы просто думаем об этом реалистично и скорее учитываем это в своей работе, а не используем для оправдания плохого качества продуктов.
Первая точка приложения усилий против крайних сроков -- осознание того, что работа спорится в чистой среде без странных флагов у функций, без противоречивых соглашений о вызовах, без многочисленных соглашений об именовании и прочего барахла. Дни после чистки весомее дней до нее. Поэтому сделайте чистку в самом начале, когда каждый может видеть перед собой большой проект, это время окупится позднее. Вы почти всегда должны делать чистку -- код, который большинство организаций помещают в репозитарии, обычно первый кандидат. И не важно, что он прошел все этапы тестирования. Делайте чистку, проверку на старость и даже не обсуждайте сроки, пока не увидите порядка.
Следует сделать предупреждение -- будьте реалистами насчет того, сколько времени займет чистка. Чем запутаннее клубок, тем больший эффект даст чистка, но тем больше риск, что у вас не будет времени на его распутывание и выполнение работы. Часто полезно задать вопрос: "Насколько сложно поведение этого предмета как черного ящика?" Если ответ: "Не очень!", то вы знаете, что по мере последовательного вычесывания сложности, он ужмется до чего-то простого, даже если вам вообще не видно, куда идти.
Вторая точка приложения усилий исходит из экспоненциального уменьшения сложности программы. Если у вас более ясный алгоритм, минимальная реализация будет проще. Чем меньше у вас кода, тем легче увидеть структуру кода, и уменьшается шанс появления искажающих концепцию ошибок. В то же время, меньшее количество кода означает и меньше возможностей для синтаксических ошибок, описок в именах переменных и т.д. Меньше ошибок -- меньше затраты времени, меньше затраты времени -- меньше тестирования. Это не займет много времени в любой команде из более полудюжины человек для большей части их работы, чтобы опуститься до нанесения увечий взаимного перепатчения, когда доступ к репозитарию станет узким местом. Позволить пропустить вещи через такой процесс на более поздних стадиях -- заложить бомбу с часовым механизмом, которая рванет тогда, когда уже поздно что-то делать. С другой стороны, безумие отбраковки (выбрасывания лишнего) посреди такой ситуации может восстановить спокойствие в оставшиеся дни.
Третья точка приложения усилий -- " дела скунса" (skunkworks), название пошло от названия местечка Skunkworks, основанного корпорацией Lockheed Martin вдали от корпоративного центра, "потому что скунс". [Насколько я слышал, скунс -- это такая вонючка, что даже кошек выворачивает - С.К.] Эта страшная технология может быть использована исключительно инициативными командами по секрету на рождественской вечеринке, либо спровоцирована просвещенным руководством. Как повелось во всей этой работе, мы проясним, почему "дела скунса" срабатывают.
В такой деятельности индустриальной эры, как строительство, имеются физические объекты (кирпичи), с которыми трудно управляться. Вместо того, чтобы нагромоздить кирпичи стопкой, чтобы увидеть, сколько их понадобится для строительства дома, мы подсчитываем их. Эта абстракция от физического к информационному дает нам сверхъестественные способности в обращении с кирпичами. В конце концов у нас становится так много чисел, говорящих о поставках, транспортировке и потребностях, что мы вынуждены организовать наши числа в структуры, чтобы работать с ними. Мы используем электронные таблицы, а абстракция от информационного к концептуальному вновь дает нам сверхъестественные способности.
Выполняя такую работу над информацией, как программирование, мы не начинаем с физического и получаем явное преимущество, когда переходим к информационному. Мы начинаем с информационных требований, списков по пунктам и т.п., и нам приходится обрабатывать их с помощью информационных инструментов. Нам приходится делать это из хороших соображений, таких как информационные контракты с заказчиками, информационные соглашения на собраниях с включенными в наш процесс коллегами. Иногда также мы делаем это из таких плохих соображений, как слишком подробные инструкции информационных технологий по преобразованию кирпичей в область информации, как измерение производительности с помощью строк кода (KLOCS).
Беда в том, что при нормальной работе у нас нет рычагов. Информационное содержимое нескольких минут совещания может быть больше информационного содержимого требований, которые на нем обсуждаются! Как деятельность, выполняемая людьми, собрания не способствуют достижению цели! Мы выигрываем только потому, что мы можем продать наше новое знание много раз, или потому, что в соединении с другими знаниями оно дает существенно больший вклад в процесс.
Это лишает возможности использовать понимание для увеличения власти над информацией. "Дела скунса" иногда выглядят как отказ от процесса в интересах творчества. Ничто не может быть дальше от истины. Необходима высокая пропорция опытных людей, чтобы исключить этот эффект, поскольку, чтобы что-то завершить, они должны положить в основу высокоинформативные динамические индивидуальные процессы. То, от чего отказываются -- это понимание, содержащееся в изнурительном процессе, ради понимания, которым владеют опытные люди. Отсюда проистекает предусловие для "дел скунса". Отказываясь от детализованного процесса, принимают, что риск неизбежен, а потеря личной безопасности компенсируется простыми хорошо определенными целями. Каждый должен осознать, что "дела скунса" могут потерпеть неудачу, надежды могут не оправдать ожиданий, а могут быть соображения, по которым все вернется к традиционным методам управления. Но когда они срабатывают, то срабатывают великолепно!
Все успешные начинания -- "дела скунса". Поэтому есть неудачные начинания. Усилия "дел скунса" могут сменить большой риск потери управляемости [из-за разбухания проекта - С.К.] на малый риск "пионерства" [в смысле быть первым - С.К.]. В таких ситуациях это может оказаться эффективным средством управления риском.
Глава 3. Программист за работой
Подходы, методологии, языки
Когда мы рассматривали простейшую программу, мы увидели, что необходимо найти взаимосвязь (карту) между проблемной областью и семантикой системы, которая удовлетворит желание. Очевидно, чем меньше возможный набор взаимосвязей, тем легче найти нужную, если, конечно, она существует. Любая заданная проблемная область будет обладать своей собственной присущей ей сложностью, а каждая проблема внутри нее будет иметь свои уникальные сложности. Когда мы рассматриваем проблему, она - вещь в себе. Мы редко можем изменить ее определение, чтобы управлять ее сложностью (хотя иногда это и можно и нужно делать, и поэтому это хорошо). Поэтому в поисках точки приложения усилий, наиболее эффективного способа сделать работу, все чем мы можем поиграть -- это семантика системы.На одном конце этого спектра расположены продукты COTS (Commertial Off The Shelf - Коммерческие, взятые с полки). Загрузи его, запусти его, работа сделана. На другом -- набор команд процессора, который позволяет нам выжать из железа все, на что оно физически способно. Между этими крайностями располагаются различные промежуточные семантики, которые упрощают поиск взаимосвязей ограничивая семантику.
В этих терминах, язык -- это произвольный набор (ящик инструментов -- kitbag) семантик. Cи - язык, но также и Excel -- язык, как и средства создания интерфейса пользователя (GUI builders). Эти наборы лежат, но не дают никакого намека, как использовать их содержимое. Языки специализируют по проблемным областям, чтобы достигнуть большой вероятности получения более простых взаимосвязей для любой проблемы из выбранной области. Чтобы решить, какую из двух семантик (языков) выбрать, обычно нужно спросить, какая из них требует более простых взаимосвязей (более простой программы), чтобы выполнить работу. За исключением самых тривиальных случаев, это требует знакомства с обоими наборами семантик на практике.
И хотя мы можем получить ясное понимание того, что из себя представляет язык, методология гораздо труднее поддается рассмотрению в таких терминах. Мы предполагаем, что причина состоит в том, что идея "методологии", как ее обычно рассматривают, включает неявные предположения, что это процедурный подход к решению программных проблем, а мы знаем, что это не так. То, что мы можем описать вместо этого, немного иное -- подход.
Подход заключается в совете, даваемом одним опытным картостроителем другому, о том, как лучше всего решать проблему какого-то типа. Это приглашение посмотреть на мир определенным образом, даже если это выражено как процедурный рецепт. Предписание "Получи диаграмму (Data Flow Diagram) изменения начислений по неделям" в книге "Как построить систему печати платежной ведомости" ( How To Build A Payroll System) на самом деле выглядит так "Ограничь рассмотрение до систем с понедельным начислением, и выведи перечень этих начислений".
Это совет для создателя систем печати платежной ведомости, при условии, что все ситуации можно свести к понедельным начислениям. Как и язык, подход получается тем проще, чем больше он специализирован на заданной предметной области. Кроме того, как и язык, подход трудно выбрать правильно без понимания "цен" имеющихся подходов и проблемы. При большом числе умных разработчиков, каждый год пишущих коммерческие (COTS) продукты, которые автоматизируют подход в виде высоко специализированного языка, с которым сможет работать любой дурак, в будущем наиболее вероятным приложением сил для хороших программистов станет изучение более глубоких, перспективных подходов и выработка новых подходов перед лицом новых проблем. Но, вероятно, всегда будут толпы людей, использующих один и тот же подход для ритуального производства еще одной точно такой же бухгалтерской системы для еще одного клиента. Они могут постоянно "переобучаться новым методологиям". Но они есть и останутся клерками, а разрыв в производительности и отдаче между клерками и программистами будет расширяться. Вот что означает быть игроком в эру информации.
Имеются языки, которые специализируются на определенном подходе. Smalltalk требует от пользователя рассматривать мир в виде объектов. Lisp требует применения неудобоваримых манипуляций с лямбда исчислением, которые приводят к появлению "собаки еды" (dog of food), вместо накормленной собаки.
Следует подчеркнуть, что языки объективны, подходы объективны, но методологии - плод нашего коллективного воображения и не существуют. Пренебрежение этим положением и неудачный выбор подхода может привести к ситуациям, в которых критические составляющие проблемы не учтены, поскольку оказывается, что подход их не рассматривает, в то время как тем, кто пытается разобраться в проблемах, вставляют палки в колеса коллеги, которым кажется, что те действуют "непрофессионально", поскольку не "применяют методологию". Это пример барьера между картостроителями и паковщиками.
Интересные методологии состоят частично из подхода, частично из языка. Структурный дизайн Джексона (Jackson Structured Design -- JSD) ограничивает свою область применения проблемами с ясно идентифицируемыми чертами (свойствами) и поэтому в состоянии предложить очень детальную инструкцию, как решать проблемы такого типа. Держите глаза открытыми, и JSD хорошо послужит в своей области. Однако за пределами этой области он может вызвать проблемы, поскольку если у задач нет нужных Джексону черт, то бесконечное латание дыр (kludging) будет делать хорошую систему из плохого понимания. Это не ошибка Джексона, поскольку он никогда не говорил, что JSD -- это ритуализованная панацея для решения всех компьютерных проблем.
На выходе JSD мы видим нечто совершенно неожиданное, артефакт того времени. Джексон описывает, как перейти от его диаграмм к коду, делая это вручную! Он осознает, что он делает, и поясняет, что автоматизм этой работы позволяет нарушить правила структурного программирования и использовать goto. Сегодня он не стал бы этого делать -- он бы просто направил диаграммы в генератор кода, как это многие и делают. Дело в том, что нотацию диаграмм JSD лучше всего рассматривать как язык программирования! Джексон создал язык, который был ориентирован на некий подход к проблемной области.
То же самое справедливо для подходов и языков Буча (Booch), Румбаха (Rumbaugh) и UML (Unified Modelling Language). В действительности, для каждой интересной методологии. В ранних публикациях Буча и Румбаха они не пропускали диаграммы через генераторы кода, но показали, что трансляция большинства диаграмм в большой степени механична. Не переживайте слишком сильно о реализации этих методов вручную -- в целом это несложно!
Создание языка и подхода, более или менее специализированного к какой-то предметной области -- крупное достижение. Поступая таким образом, авторы должны долгое время продумывать, как лучше всего управляться с проблемами, разделять их, исследовать их, смотреть на них с разных точек зрения и в соответствии с этим разрабатывать свой подход или язык. Но многое оказывается запутанным из-за пресловутого языкового барьера картостроитель/паковщик, и приходится отказываться от акцента на творческое мышление, необходимое для построения карты между проблемой и ее языком. Вместо того, чтобы представлять свой подход как структуру и предлагать некоторые эвристики для рассмотрения проблемы в терминах этой структуры, они вынуждены использовать процедурный язык и описывать действия, которые необходимо предпринять, императивно [строгим командным голосом - С.К.]. Если кто-то не обладает даром думать творчески, то естьконструировать мысленную карту своей проблемы посредством размышления и затем исследовать ее, то им не остается выбора, кроме как следовать этим (вероятно, некорректным) указаниям, а их результаты будут существенно зависеть от везения. Джексон тут хорош. Он специфически ограничивает свою область и говорит читателю, какие свойства искать. Читатель начинает с обследования проблемы в поисках (ключевых) признаков. Буч включает интересный раздел, посвященный поиску объектов, которого, если бы только он был выполнен глубоко и широко, достаточно, чтобы сделать путь императивов ненужным, поскольку он опирается на сугубо картостроительные моменты. Наконец, то, как книга Страуструпа (Stroustrup) описывает объектный подход и язык C++ -- праздник стиля, интуиции, структуры, глубины и творчества. Это тяжелая книга, описывающая сложный язык программирования, но она написана великим картостроителем в действии, у которого нет внутренней неразберихи относительно предмета.
Как писать документы
С точки зрения многих инженеров-программистов, большая часть их жизни состоит в написании документов. С точки зрения настоящей работы, мы предпочли бы сказать, что их жизнь состоит в выполнении работы по повышению понимания, которое будет донесено до их коллег в соответствии с протоколом, определенным в их процессе. Следовательно, мы подразумеваем, что работа -- это всегда понимание, а процесс говорит, какое понимание нам нужно передать коллегам. Это определяет приемлемый для каждого документа язык. Эти соображения помогут сформировать описание реальной работы, которую требуется выполнить при работе над каждым из создаваемых инженером документов, как то: Требования Пользователя, Требования к Программному Обеспечению, Архитектурный Проект, Детальный Проект и Спецификация Тестирования (User Requirement, Software Requirement, Architectural Design, Detailed Design and Test Specification).Следует отметить еще два момента. Во-первых, работа не заключается в создании кучи невразумительных бумажек, которые никто даже не будет читать, но которые по виду напоминают "конструкторскую документацию". Те, кто выплескивает технические подробности (все слеши и десятичные точки) в основном тексте, вместо того, чтобы поместить их в приложении, если уж это так нужно, просто издеваются над читателями и дискредитируют наше искусство в целом. Используя простой, нормальный язык (включая где необходимо специальную терминологию, но не злоупотребляя ею) расскажите читателю то, что ему нужно знать.
Второй момент касается формата. На любой стадии процесса программирования люди используют понимание, чтобы находить и предлагать паттерны. Если бы они знали, что они собираются найти, у них не было бы работы, поскольку их мог бы заменить настроенный кем-нибудь коммерческий (COTS) продукт. Раз мы не знаем наверняка, что работнику нужно представить, то как мы можем сказать ему, как он это должен представить? Стандартные форматы в процессах не должны восприниматься как догмы. Все приличные процессы в ISO 9001 содержат стандарты размещения необходимых разделов. Используй их соответственно, и если во время написания возникает структура документа, можно сделать вставку в План Управления Проектом, чтобы описать выбранный формат. Вот и вся суть ISO 9001.
Требования пользователя
Недавно возник большой интерес к "Реинженирингу бизнес-процессов" (`Business Process Re-Engineering' -- BPR). Это практика изучения бизнес-процессов для определения, можно ли их улучшить, и часто это необходимо сделать просто потому, что со временем изменилась природа бизнеса организации. Иногда превозносят точку зрения, что программная инженерия всегда включает значительный компонент BPR, поскольку в противном случае потребитель обнаружит, что компьютерная система автоматизирует бизнес-процесс, не учитывающий появление компонентов, которые руководство реализовало в ответ на потребности бизнеса, и систему ожидает крах. Таким образом, первая обязанность инженера-программиста -- помочь потребителю понять природу их собственных требований. В примере простейшей программы -- это кристаллизация желания из общего ощущения дискомфорта в специфическую потребность в большей освещенности. Инженер-программист руководствуется в этой работе дисциплиной, накладываемой необходимостью писать программу для компьютера. В работающем коде невозможно скрыть неоднозначности, как это можно сделать в текстовом отчете. Полезные ТП, таким образом, составляют настолько ясное понимание потребностей пользователя, насколько это возможно в начале проекта, как это понято пользователем и инженером, на языке пользователя. ТП обязательно потребуют уточнения в дальнейшем, по мере того, как дисциплина программирования выявит неоднозначности, независимо от того, будут ли эти поправки включены в документ или нет.
Причина, которая вызывает большую путаницу -- двоякое назначение ТП. С точки зрения инженера ТП должны быть живым документом, но из соображений коммерческих и правовых он занимает место эталонного документа на все время работы над проектом. Эти две цели совершенно различны. Когда они смешиваются, мы получаем комедию инженеров, не обремененных юридическими знаниями (что на самом деле так), пытающихся написать "Декларацию независимости", в то время как критические моменты бизнес процессов остаются неисследованными.
Иногда единственный способ выйти из этого положения -- написать два документа. Один определяет контрактный минимум и, если придерживаться некоторых методик, может быть с успехом написан полностью пользователем. Другой -- это живой, внутренний документ, который говорит нам, что же "приведет пользователя в восторг". Это то, чем мы стараемся руководствоваться в его интересах. Как удовлетворить пользователя, если единственной подсказкой как это сделать, является нечто, служащее нашим коллегам из коммерческого подразделения на поле закона? Рамки, до которых потребитель видит "настоящие ТП" зависят от коммерческих соображений.
Будьте очень осторожны по отношению к "средствам интегрированного отслеживания свойств", призванных получить ваши ТП и пропустить их положения через проектирование и тестирование, превращая в код. Такие средства часто забывают, что требования можно удовлетворить не делаячто-то, что ряд требований может быть реализован в нескольких сегментах кода, без прямого соответствия между требованиями и сегментами, и что очень трудно протестировать важные общие требования отдельными тестовыми инструментами. Это не значит, что такими инструментами не следует пользоваться -- для задач конфигурирования и ввода данных они подходят прекрасно. Некоторые даже могут отследить свойства отдельных групп классов для GUI. Но для обычных требований черного ящика на "уровне пользователя" они искажают то, что могло быть написано в ТП, или навязать стиль разработки, требующий утомительного ручного кодирования отдельных свойств, вместо использования абстракций везде, где это возможно.
Требования к программному обеспечению
Если ТП описывают требуемую систему на языке пользователя, то ТПО описывают ее на языке инженера. Поэтому в этом документе сначала могут оказаться расчеты размера системы. Что особенно характерно для современных объектных методологий, потребность в ТПО уменьшилась, поскольку архитектура будет состоять из прикладных классов, у которых ясные взаимосвязи с языком ТП. В этой ситуации, ТПО и АП могут быть объединены.
Говорят, скульптор думает о своей законченной работе, как о заключенной внутри глыбы камня или куска дерева, и которую нужно оттуда извлечь, отсекая лишнее. Это помогает. Точно так же, мы можем представить себя глядящими глазами пользователя на наше творение в один из дней в будущем. Если мы смотрим на него используя свойства (черты) системы, мы можем спросить себя: "Как это должно быть реализовано?" Тогда очень легко получить описание потребностей пользователя на языке инженера-программиста.
Архитектурный проект
Если уже приходится делать работу, заключенную в АП, то может показаться, что самая тяжелая работа по проектированию к этому моменту завершена. Есть также большой соблазн вообще уклониться от написания Архитектурного Проекта. В то время как мы умышленно опускаем детали проекта в АП, иногда чтобы удовлетворить требованиям независимости от платформы (portability), иногда просто чтобы развеять туман вокруг большой картины, мы по-прежнему должны быть уверены в том, что наш проект действительно реализуем. Инженер должен знать по крайней мере один приемлемый способ реализации каждого свойства до того, как искать его, и должен подумать о концептуальной целостности кода, требуемого для реализации этих свойств.
Утверждение, что архитектурный проект не должен касаться детального проекта, мы считаем ошибочным. Если мы не можем рассматривать реализацию, мы не можем быть хорошими инженерами, поскольку любой идиот может спроектировать нереализуемое. Только учитывая реализацию мы обнаруживаем ограничения наших проектов и находим разницу между хорошим и плохим. Мы способны увидеть альтернативы, сравнивать их и выбирать лучшее. Если мы не можем учитывать реалии реализации, то один дизайн так же хорош, как и другой, и эта критическая стадия познания становится упражнением в письме, кто быстрее может "написать документ", нимало не задумываясь над написанным!
АП -- это дидактический документ. Он учит читателя тому, как посмотреть на проблему и решение так же, как смотрел автор.
Детальный проект
ДП -- это записка в бутылке. Он говорит читателю о том, как автор планировал реализацию, поэтому код можно понять. Детальность изложения должна прояснить те места, которые остались за кадром в АП, и привести читателя в точку, где уже должен быть сам код. Иногда, это объяснение может быть выражено псевдокодом, но не обязательно. Следует допускать возможность исправления ДП. Во время реализации будут возникать такие детали проекта, как организация кода в модули. Если такие детали не передать с помощью ДП нашим коллегам, то как еще это сделать? Это простое упущение вызывает в дальнейшем слишком много ненужных проблем, поскольку инженеры посчитают составляющие системы хорошо документированными, только в случае, если они знали, с чего начать! Окончательный вариант ДП должен говорить последователям, что они должны знать, чтобы понять систему и изменить ее.
План тестирования
План Тестирования -- наиболее чувствительный к контексту тип документа, но очень полезно руководствоваться следующими наблюдениями в рамках требований ситуации. Стратегическая цель тестирования -- напрячь систему. Не будет никакой пользы, если делать тестирование хаотично, поэтому необходимо найти одну или несколько моделей системы, которые могут дать нам индикатор для типичных и стрессовых ситуаций. Таким образом, полезная структура -- описать модель, выяснить стрессовые условия и затем перечислить их.