М. Фаулер, К. Скотт - UML. Основы - 2002 (1158629), страница 10
Текст из файла (страница 10)
На каждой итерации некоторая часть существующего кода переписывается заново с целью сделать его более гибким. Построение Самотестируемое программное обеспечение С возрастом я все серьезнее отношусь к тестированию. Тестирование должно быть непрерывным процессом. Не следует писать программный код до тех пор, пока вы не знаете, как его тестировать.
Написав программный код, сразу же пишите для него тесты. Пока не будет выполнено тестирование, нельзя утверждать, что вы завершили написание кода. Однажды написанный тестовый код должен храниться вечно. Разрабатывайте тестовый код таким образом, чтобы вы смогли запускать каждый тест с помощью простой командной строки или нажатия кнопки на графическом интерфейсе пользователя (О(П).
Результатом выполнения теста должно быть сообщение «ОК» или список ошибок. Кроме того, все тесты должны проверять свои собственные результаты. Ничто не приводит к более неоправданной трате времени, как получение на выходе теста числового значения, понимание смысла которого требует дополнительных усилий. Я выполняю как модульное, так и функциональное тестирование. Модульные тесты следует писать самим разработчикам. После чего они организуются на пакетной основе и кодируются с целью тестирования интерфейсов всех классов.
По моему мнению, написание модульных тестов, как это ни удивительно, увеличивает мою скорость программирования. Функциональные или системные тесты должны разрабатываться отдельной небольшой командой, работа которой состоит только в тестировании. Такая команда должна рассматривать всю систему как черный ящик, а нахождение ошибок должно доставлять ее участникам особое удовольствие.
(Зловещие усы и нахальные усмешки не обязательны, но желательны.) Для модульного тестирования существует простая, но довольно мощная основа с открытым кодом: семейство хУп($. Более подробную информацию по етой теме можно найти на моей домашней странице в Интернете. В последнем случае очень полезным может оказаться метод реорганизации (см.
врезку). Хорошо бы обратить внимание на то, какой объем кода оказывается ненужным после каждой итерации. Если каждый раз выбрасывается менее 10% предыдущего кода, то это должно вызывать подозрение. Интеграция должна представлять собой непрерывный процесс. Для участников проекта каждая итерация должна заканчиваться полной интеграцией соответствующих результатов.
Однако интеграция может 46 Глава 2. Основы процесса разработки Реорганизация Можете ли вы интерпретировать принцип энтропии применительно к программному обеспечению? Этот принцип предполагает, что программы в самом начале являются хорошо спроектированными, но по мере добавления в них какой-либо новой функциональности постепенно утрачивают свою структуру, превращаясь в конечном счете в бесформенную массу спагетти. Отчасти это происходит по причине масштаба. Предположим, вы написали небольшую программу, которая хорошо выполняет конкретную работу. Пользователи просят вас расширить функциональность программы, в результате чего она становится все более сложной.
Как бы тщательно ни отслеживался проект, подобная ситуация все равно может произойти. Одной из причин возрастания энтропии является следующее обстоятельство. Когда вы добавляете в программу новую функцию, то, как правило, дописываете новый код поверх существующего и совсем не заботитесь о том, как это может повлиять на прежнюю программу. В такой ситуации можно было бы либо перепроектировать существующую программу, чтобы внести изменения наилучшим образом, либо попытаться учесть возможность внесения изменений в выполняемом проекте.
Хотя теоретически программу лучше перепроектировать, обычно это приводит к большой дополнительной работе, поскольку любое переписывание существующей программы порождает новые ошибки и проблемы. Вспомните старую инженерную поговорку: «Пока не сломалось — не отлаживай».
Однако если вы не будете перепроектировать свою программу, внесение дополнений может оказаться более сложным, чем могло бы быть в случае перепроектирования. Со временем такая сверхсложность приведет к чрезмерным дополнительным затратам. Поэтому приходится идти на компромисс: хотя перепроектирование и сопряжено с серьезными трудностями в краткосрочном плане, зато приносит выгоду в долгосрочной перспективе. Находясь под давлением жестких плановых сроков, большинство разработчиков предпочитает откладывать эти трудности на будущее. Реорганизация представляет собой термин, используемый для описания методов, которые позволяют уменьшить краткосрочные трудности, связанные с перепроектированием. В процессе реорганизации вы изменяете не функциональность своей программы, а лишь ее внутреннюю структуру, для того чтобы сделать ее более понятной и приспособленной к изменениям. 47 Построение Реорганизационные изменения обычно касаются небольших действий: переименование метода, перемещение атрибута из одного класса в другой, объединение двух подобных методов в суперклассе.
Каждое такое действие очень мало, однако даже пары часов, затраченных на внесение таких небольших изменений, может оказаться достаточно для существенного улучшения программы. Реорганизацию можно упростить, если следовать следующим принципам: ° Не следует одновременно заниматься реорганизацией программы и расширением ее функциональности. Необходимо проводить четкую грань между этими действиями. В процессе работы можно на короткое время переключаться от выполнения одного действия к другому — например, в течение получаса заниматься реорганизацией, затем в течение часа работать над добавлением новой функции и снова полчаса потратить на реорганизацию только что добавленного кода.
° До начала реорганизации убедитесь в том, что у вас имеются хорошие тесты. ° Выполняйте только небольшие и тщательно продуманные действия. Переместите некоторый атрибут из одного класса в другой. Объедините два подобных метода в один суперкласс. Протестируйте программу после каждого такого действия. Хотя вы не получите сразу впечатляющих результатов, подобные действия позволят избежать дополнительной отладки и, следовательно, сократят общее время разработки. Реорганизацию следует выполнять всякий раз при добавлении новой функции или обнаружении ошибки.
Не следует выделять на реорганизацию специальное временя; лучше делать это понемногу, но каждый день. Дополнительную информацию по реорганизации можно найти в книге Фаулера (Рою)ег),1999 [19). и должна выполняться еще чаще. Хорошим правилом является ежедневное выполнение полной сборки и интеграции. Если это делать каждый день, не потребуются дополнительные усилия для последующей синхронизации компонентов. А вот если интеграция отложена на поздние сроки, могут возникнуть серьезные проблемы.
Разработчику следует выполнять интеграцию всякий раз после завершения каждого значительного объема работы. Кроме того, для гарантии требуемого уровня тестирования на каждой итерации следует запускать полный набор тестов для всех модулей. Глава 2. Основы процесса разработки Когда план заканчивается неудачей Чтобы быть уверенным в выполнении плана, вам необходимо знать только одну вещь, а именно — все что происходит, происходит в соответствии с планом. Управление планом состоит главным образом в эффективном отслеживании происходящих изменений.
Важной чертой итеративной разработки является фиксация временных сроков — вам не позволят пропустить ту или иную дату. Тем не менее, в результате обсуждения и по соглашению с клиентом реализация вариантов использования может быть перенесена на более позднюю итерацию. Главное здесь в том, чтобы приобрести привычку регулярно отслеживать даты и избавиться от плохой привычки их забывать.
Если вы сами обнаружили задержку в реализации большого количества вариантов использования, то самое время пересмотреть план, включая переоценку уровня трудоемкости вариантов использования. На этой стадии разработчики должны предложить более конструктивные идеи относительно продолжительности отдельных этапов. Вам следует преднамеренно вносить изменения в план через каждые две или три итерации.
Использование языка ЦМЕ на фазе построения На этой стадии могут оказаться полезными все методы языка ()М1.. Поскольку я собираюсь говорить о методах, рассмотреть которые у меня еще не было возможности, можете спокойно пропустить этот раздел и вернуться к нему позже. Если вы намерены добавить очередной вариант использования, то в первую очередь применяйте его для уточнения сферы вашей деятельности. Для предварительного описания некоторых понятий варианта использования и определения того, как эти понятия согласуются с уже разработанным программным обеспечением, может оказаться полезной концептуальная диаграмма классов (см. главу 4).
Преимущество этих методов на данной стадии заключается в том, что они могут быть использованы в сотрудничестве с экспертом предметной области. Как говорит Брэд Кайн (Вгат) Ка)п): «Анализ возможен только тогда, когда рядом находится эксперт предметной области (в противном случае это не анализ, а псевдоанализ)». В ходе выполнения проекта постарайтесь понять, как будут кооперироваться классы с целью обеспечения функциональности, требуемой каждым вариантом использования. Я полагаю, что для представления подобных взаимосвязей могут оказаться весьма полезными СВС-карточки и диаграммы взаимодействия. При этом будут выявлены ответственности и операции, которые могут быть представлены на диаграмме классов. Построение Я9 Рассматривайте эти результаты как предварительный набросок и как средство для обсуждения с вашими коллегами различных подходов к проектированию.
Только достигнув согласия в этих вопросах, можно приступать к написанию кода. Не прощающий ничего программный код неизбежно вскроет все недостатки проекта. Не бойтесь вносить изменения в проект в процессе его изучения. Если подобные изменения серьезны, то следует использовать специальные обозначения для последующего обсуждения идей со своими коллегами. После того как вы разработали программное обеспечение, для подготовки документации о проделанной работе может быть использован язык ПМ1 . Я пришел к выводу, что диаграммы языка ()МАЙ.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
