Эндрю Хант - Программист-прагматик. Путь от подмастерья к мастеру

• Название: Программист-прагматик. Путь от подмастерья к мастеру
• Автор: Эндрю Хант
• Издательство: Лори
• Жанр: Программирование
• Год: 2004
• ISBN: 5-85582-213-3, 0-201-61622-X

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

Прочитав эту книгу, вы научитесь:

Бороться с недостатками программного обеспечения;

Избегать ловушек, связанных с дублированием знания;

Создавать гибкие, динамичные и адаптируемые программы;

Избегать программирования в расчете на совпадение;

Защищать вашу программу при помощи контрактов, утверждений и исключений;

Собирать реальные требования;

Осуществлять безжалостное и эффективное тестирование;

Приводить в восторг ваших пользователей;

Формировать команды из программистов-прагматиков и с помощью автоматизации делать ваши разработки более точными.

---

• Приоритет: Высший

• Производительность: 5 минут на оформление заказа, оплата в течение 45 дней

• Частота: 200 заказов в день

• Превосходящий прецедент использования: Управление взаимоотношением с заказчиком (прецедент использования № 2).

• Подчиненные прецеденты использования: Компоновка заказа (прецедент использования № 15)

• Прием оплаты кредитной картой (прецедент использования № 44). Возврат товара покупателем (прецедент использования № 105).

• Канал общения с первичным действующим субъектом: по телефону, факсу или компьютерной сети.

• Вторичные действующие субъекты: компания – оператор платежной системы, банк, экспедиторская фирма.

F. РАСПИСАНИЕ

• Должная дата: Выпуск 1.0

G. ПРОБЛЕМЫ, ЯВЛЯЮЩИЕСЯ ОТКРЫТЫМИ

• Что происходит, если имеется лишь часть заказа?

• Что происходит, если кредитная карта похищена?

Подобного рода организация поддерживает иерархическое структурирование сценариев использования системы – вложение более подробных сценариев в сценарии более высокого уровня. Например, сценарии post debit и post credit дополняют друг друга в сценарии post transaction.

Диаграммы сценариев использования

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

Рис. 7.3. Сценарии использования, выраженные UML, понятны даже ребенку!

Кажется невероятным, что кто-нибудь может всерьез воспринимать документирование информации, используя примитивные символы, подобные изображенным на рисунке 7.3. Не будьте рабом системы обозначений: используйте любой метод общения, с помощью которого можно обмениваться требованиями с вашей аудиторией.

Чрезмерная спецификация

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

Требования не являются архитектурой. Требования – это не конструкция, и не пользовательский интерфейс. Это потребность.

Видеть перспективу

Вина за возникновение "проблемы 2000 года" часто возлагается на близоруких программистов, пытавшихся сэкономить несколько байтов в те дни, когда объем памяти мэйнфреймов был меньше, чем у современных пультов дистанционного управления телевизорами.

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

Двухразрядное обозначение года использовалось в деловой практике задолго до появления компьютеров. Это было обычной практикой. В то время приложения, предназначенные для обработки данных, в основном занимались автоматизацией существующих бизнес-процессов и просто повторили ошибку. Даже в том случае, когда архитектура требовала двухразрядного обозначения при вводе данных, создании отчетов и хранении данных, должна была бы появиться абстракция DATE, которая «знала» о том, что две цифры представляли собой усеченную форму реальной календарной даты.

Подсказка 53: Абстракции живут дольше, чем подробности

Требует ли от вас фраза "Видеть перспективу", чтобы вы занялись предсказанием будущего? Нет. Это означает создание формулировок типа:

Система активно извлекает пользу из абстракции DATE. Система последовательно и универсально осуществит реализацию служб DATE наподобие форматирования, хранения данных и математических операций.

В требованиях указывается лишь то, что даты используются в принципе. Это может навести на мысль, что с датами можно производить некоторые математические действия и что даты будут храниться на различных устройствах внешней памяти. Это и есть истинные требования для модуля или класса DATE.

Еще одна мелочь…

Вина за неудачи многих проектов возлагается на увеличение области их применения – это также называется раздуванием одной их характеристик, мелким улучшательством или размыванием требований. Это аспект синдрома лягушки из раздела "Суп из камней и сварившиеся лягушки" Что можно сделать для того, чтобы требования не поглотили нас?

В литературе описаны многие метрики: количество обнаруженных и устраненных дефектов, плотность дефектов, сцепление, связывание, функциональные точки, строки программы и т. д. Эти метрики могут отслеживаться вручную или с помощью программы.

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

Указание спонсорам на воздействие, оказываемое всяким новым средством на график проекта, помогает сдерживать рост количества требований. Если проект запаздывает на год по сравнению с начальными оценками, а в адрес исполнителей летят обвинения, всегда полезно иметь точную и полную картину того, как и когда происходит рост числа требований.

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

Поддержка глоссария

Как только вы начинаете обсуждать требования, пользователи и специалисты в предметной области будут использовать определенные термины, имеющие для них специфическое значение. Например, они проводят различие между «клиентом» и «заказчиком». Было бы неуместно допустить небрежность, используя в системе то один, то другой термин.

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

Подсказка 54: Используйте глоссарий проекта

Очень сложно создать успешный проект, в котором пользователи и разработчики обращаются к одному и тому же предмету под разными именами или, что еще хуже, обращаются к разным предметам, используя одно и тоже имя.

Прошу слова…

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

Представляя требования в виде гипертекстового документа, мы можем обращаться к нуждам различной аудитории – дать каждому читателю, то что он хочет. Спонсоры проекта могут действовать на высоком уровне абстракции, чтобы удостовериться в том, нет что отклонений от цели бизнеса. Программисты могут использовать гиперссылки, чтобы «врубиться» в возросшие уровни детализации (даже в те, которые ссылаются на соответствующие определения или технические характеристики).

Распространение с помощью сети Интернет также позволит избежать создания толстенных отчетов под названием "Анализ требований", которые никто никогда не прочтет и которые устаревают в тот момент, когда первая капля чернил смачивает лист бумаги.

Если этот материал есть в Сети, то программисты даже могут его прочесть.

Другие разделы, относящиеся к данной теме:

• Суп из камней и сварившиеся лягушки

• Довольно приличные программы

• Круги и стрелки

• Все эти сочинения

• Большие надежды

Вопросы для обсуждения

• Можете ли вы использовать программы, которые сами пишете? Можно ли обладать хорошим чутьем на требования, будучи неспособным использовать программы самостоятельно?