Материал: Инфрам

350
Литература к главе 7
1.
A new method for measuring software functional size http://www.automotive-spin.it/uploads/7/7W_buglione.pdf
2.
Albrecht A. J. Measuring Application Development Productivity
IBM Application
Development Symposium. Monterey, CA, 1979.
3.
Function Point Counting Practices Manual. International Function
Point Users
Group, Westerville, Ohio. Release 4.1. 1999. P. 147.
4.
Manager’s Handbook for Software Development, Revision 1, Sel-
84–101,NASA Soft-ware Engineering Laboratory, Goddar Spase Flight.
Greenbelt, MD, November 1990.
5.
Алиев Х. Р. Эффективная модель оценки разработки про- граммного обеспечения http://zhurnal.ape.relarn.ru/-articles/2008/030.pdf
6.
Арлазаров В. Л., Славин О. А., Шустов А. В. Оценка стоимости информационно-технического комплекса сложной системы. Труды
ИСА РАН, 2007. Т. 29, с. 152 – 182 7.
Боди З., Мертон Р.К. Финансы. М.: Вильямс, 2000. 592 с.
8.
Боэм Б.У. Инженерное проектирование программного обеспе- чения: Пер. с англ. – М.: Радио и связь. 1985. – 512 с.
9.
Гольфанд И. Я., Хлебутин П. С Оценка трудозатрат разработки программной компоненты. Труды ИСА РАН 2005. Т. 15, с. 125 – 134.
10. Котлер Ф. Основы маркетинга М.: Бизнес-книга, 1995. 698 с.
11. Леффингуэлл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению. Унифицированный подход. Пер. с англ.
– М.: Вильямс. 2002 12. Липаев В.В. Технико-экономическое обоснование проектов сложных программных средств. Москва: СИНТЕГ, 2004. – 284 с.
13. Макконел С. Руководство для менеджера программных проек- тов “Остаться в живых”, СПб.: Питер, 2006.
14. Макконелл К. Р., Брю С. Л. Экономикс. Ч. 2. М.: Республика,
1995. 400 с.
15. Метрики кода.
Интересный материал http://anovichkov.msk.ru/?p=1196 16. Михайловский Н. Сравнение методов оценки стоимости проек- тов по разработке информационных систем. PMProfy, 2003.
17. Новичков А. Метрики кода и их практическая реализация в IBM
Rational ClearCase http://anovichkov.msk.ru/?p=13 18. Олве Н. Г., Петри К.-Й., РойЖ ., Рой С. Баланс между стратеги- ей и контролем. СПб.: Питер, 2006.
19. Орлов С. Технологии разработки программного обеспечения.
— СПб.: Питер, 2002. — 464 с.: ил.

351
Глава 8
РЕФАКТОРИНГ ПРОГРАММНЫХ СИСТЕМ
8.1. Что такое рефакторинг
Начиная с последнего десятилетия прошлого века, получили широ- кое распространение эволюционные методологии разработки про- граммного обеспечения, часто называемые адаптивными, такие как экс- тремальное программирование (Extreme Programming - XP), метод
Scrum, унифицированный процесс компании Rational (Rational Unified
Process - RUP), адаптивный унифицированный процесс (Agile Unified
Process - AUP) и др. [37]. Часть этих методологий рассмотрена в третьей главе книги, где отмечалась сущность их методов, которые по своему характеру является и итеративными, и инкрементными, а адаптивный подход является эволюционным и вместе с тем характеризуется высо- кой степенью взаимодействия участников разработки проектов.
В организациях, применяющих подобные технологии, все шире вне- дряются такие адаптивные методики, как рефакторинг, программирова- ние в паре, разработка на основе тестирования (Test-Driven Development
- TDD) и адаптивное проектирование на основе модели (Agile Model
Driven Development – AMDD). Концепция «рефакторинга» (refactoring) возникла в кругах, связанных со Smalltalk, но вскоре нашла себе дорогу и в лагеря приверженцев других языков программирования [3]. Не- сколько позже Мартин Фаулер в своей фундаментальной монографии, выдержавшей в нашей стране несколько изданий [32], дал определение рефакторинга как небольшого изменения в исходном коде, которое спо- собствует улучшению проекта кода без изменения его семантики.
Иными словами, рефакторинг – это улучшение качества сделанной программистом работы без нарушения или добавления чего-либо. В своей книге М. Фаулер говорит также о том, что если возможно под- вергнуть рефакторингу прикладной исходный код, то, видимо, есть воз- можность подвергнуть рефакторингу схему базы данных. Однако он считает, что рефакторинг баз данных – достаточно сложная и отдельная проблема и исключил эту тематику из своей книги. Однако это замеча- ние не осталось незамеченным, и несколько позже появилась еще одна фундаментальная книга, посвященная именно рефакторингу баз данных
[37].
Эволюция сложных программных систем требует от разработчика повышенного внимания к выбору архитектуры [33]. Практически всегда во время разработки, появляются новые требования со стороны заказчи- ка и приходиться пересматривать первоначальную архитектуру, в том числе и структуру базы данных. Возможна и другая ситуация. Часто в фазе поддержки и эволюции приложения появляется желание переде- лать всё "с нуля".
Что же такое рефакторинг? Рефакторинг представляет собой процесс такого изменения программной системы, при котором не меняется

352 внешнее поведение кода, но улучшается его внутренняя структура. При проведении рефакторинга разработчик улучшает дизайн кода уже после того, как он написан [8, 16, 32].
Что дает рефакторинг? Вот некоторые преимущества:
1. Рефакторинг улучшает композицию программной системы (ПС).
По мере развития программы то и дело приходится вносить изменения, которые обусловлены текущей необходимостью. Часто изменения вно- сят программисты, которые не до конца понимают архитектуру ПС в целом. Поэтому постепенно код становится менее структурированным и разбираться в нем все труднее.
2. Рефакторинг облегчает понимание ПС. Проведение рефакторинга обычно приводит к более глубокому пониманию того, как работает про- грамма. Такое понимание существенно ускоряет процесс программиро- вания.
3. Рефакторинг помогает найти ошибки. Поскольку рефакторинг увеличивает понимание кода, то он и позволяет быстрее находить ошибки.
4. Рефакторинг позволяет быстрее писать программы. Все вышепе- речисленные пункты сводятся к тому, что рефакторинг позволяет быст- рее разрабатывать код.
Рефакторинг является одной из основных практик экстремального программирования (XP) и, по сути дела, позволяет создавать хорошую архитектуру программы, но несколько непривычным путем. В традици- онном подходе архитектура программы создается еще до того, как на- писана первая строчка кода. Архитекторы на основе требований к ПС создают диаграммы классов, взаимодействий и все то, что необходимо кодировщикам для написания кода. Конечно, обычно архитекторы – опытные разработчики, тем не менее очень сложно сразу создать хоро- шую архитектуру.
Если полагаться на рефакторинг, то вначале можно сделать лишь предварительный набросок будущей системы, а детали выяснять в про- цессе разработки. Чем больше разработчики знают о системе, тем боль- ше возникает мыслей по ее улучшению. Мелкие и средние изменения в коде наподобие переименования поля или метода, выделения метода, замены массива объектом, выделения подкласса, выделения иерархии классов и т.п. сами по себе не оказывают огромного влияния на систе- му, но суммарный эффект часто превосходит все ожидания. Спустя не- сколько итераций архитектура системы становится стабильной и краси- вой. Когда программист чувствует целостность и внутреннюю красоту системы, он испытывает удовлетворение от работы.
Может показаться, что такой подход ненадежен. Действительно, для того чтобы смело полагаться на рефакторинг, необходимо наличие сле- дующих условий:
1. Наличие автоматических тестов. Если таковые отсутствуют, то крайне сложно контролировать изменения. Предположим, программист изменил название метода. Теперь ему надо узнать, где он вызывается.
При наличии автоматических тестов это делается элементарно. Если же

353 изменения менее очевидные, то ценность автоматических тестов много- кратно возрастает.
2. Система контроля исходного кода. Управление исходным кодом является одной из главных практик разработки ПС. Если имеется рабо- тающая версия системы, то можно без опасений вносить изменения, потому что всегда есть возможность вернуться к стабильной версии.
Контроль кода дает свободу. Вряд ли кто-то захочет осуществлять ре- факторинг, если есть риск потерять пару дней, восстанавливая все как было в случае неудачных изменений.
3. Итерационная разработка. Конечно, рефакторинг можно прово- дить и при обычном водопадном процессе, но его ценность в таком слу- чае несколько уменьшается. Итерации позволяют лучше организовать процесс рефакторинга и сделать его последовательным.
4. Регулярность осуществления рефакторинга. Эпизодический ре- факторинг – достаточно бесполезное занятие. Только методичное при- менение может принести ощутимую пользу. Эпизодический рефакто- ринг может быть даже опасным в случае отсутствия контроля исходного кода.
Есть одна опасность, которая подстерегает тех, кто начинает исполь- зовать рефакторинг. Надо четко разделять процесс разработки нового кода от процесса изменения уже существующего. Например, разработ- чик нашел в программе метод, который можно изменить (улучшить). Он начинает его изменять, не доводит изменения до конца, и вдруг вспоми- нает, что надо добавить в этот метод немного новой функциональности.
Программист начинаете ее добавлять, увлекается и забывает завершить рефакторинг. В результате придется тратить лишнее время на то, чтобы все заработало, как надо. Поэтому, когда выполняется рефакторинг, на- до обязательно доводить его до конца или вернуться к начальному со- стоянию и только после этого начинать писать новый код.
Проблема выбора при добавлении в систему новой возможности возникает при разработке достаточно сложной ПС практически всегда.
Самым сложным при выборе того или иного решения является доведе- ние разработчиком своего выбора непосредственному руководителю, чтобы он смог принять взвешенное решение. С точки зрения многих руководителей «взвешивание» заканчивается сразу же после того, как он услышит предполагаемые сроки реализации. Не удивительно, что программисты и архитекторы, понимающие, что им самим придется работать с проблемами «близоруких» решений, с таким подходом не согласны. С подобной ситуацией сталкивались известные специалисты, которые придумали типовые «паттерны», описывающие такую ситуа- цию. Одним из таких паттернов, является метафора технического долга, впервые описанная Вардом Каннингемом примерно двадцать лет назад
[31].
Под техническим долгом понимается осознанное компромиссное решение, когда заказчик и ключевые разработчики четко понимают все преимущества от быстрого, пусть и не идеального технического реше- ния, за которое придется расплатиться позднее. И хотя с точки зрения

354 многих разработчиков ситуация, когда плохое решение может быть хо- рошим, может показаться нереальной, на самом деле, это вполне воз- можно. Если краткосрочное решение позволит компании получить ви- димые преимущества, выпустить продукт раньше конкурентов, удовле- творить ключевого заказчика или получить какие-то преимущества пе- ред конкурентами, тогда такое решение совершенно оправданно. Ино- гда это может быть единственным способом, чтобы долгосрочная пер- спектива вообще существовала.
Можно провести параллель между техническим и финансовым дол- гом. Финансовый долг означает, что вы получаете дополнительные средства сейчас, однако вам придется выплачивать фиксированную процентную ставку, и в конце срока вернуть весь долг кредитору. Ана- логичная ситуация происходит и в случае принятия неоптимального технического решения: вы получили готовую систему или новую воз- можность уже сегодня, однако при добавлении новой возможности вам придется платить «проценты», либо погасить ваш долг путем рефакто- ринга системы или части системы.
Как признается в ряде публикаций [28, 31, 38], именно такой подход к построению приложений является оптимальным с архитектурной точ- ки зрения. Если принимая архитектурное решение, разработчик не чув- ствует компромисса между краткосрочными и долгосрочными выгода- ми, то в любом случае не стоит считать его окончательным. Вполне возможно, что неправильное решение принято неосознанно, из-за не- понимания предметной области, или из-за будущего изменения требо- ваний заказчиком. Значительно проще снизить стоимость будущих из- менений путем инкапсуляции важных решений в наименьшее число модулей, чем стараться продумать архитектуру до мельчайших подроб- ностей, в надежде учесть все возможные и невозможные сценарии. Для определенного круга задач идеальная продуманная архитектура воз- можна, а иногда просто необходима, но в большинстве случаев – это не так; рано или поздно придет момент, когда видение системы разработ- чиком или заказчиком изменится, что потребует внесения в нее сущест- венных изменений.
Однако даже при разумном накоплении технического долга сущест- вует вероятность того, что команда (или заказчики) пойдут по старому принципу – работает – не трогай, и никогда не вернутся к этому реше- нию снова, чтобы расплатиться за свой технический долг. Кроме того, существует множество случаев, когда технический долг накапливается постепенно и неосознанно, и если разработчики не будут об этом заду- мываться, то придут к ситуации, когда стоимость добавления новой возможности становится очень дорогой. В этом случае команда усилен- но работает, исполнители устают, злятся друг на друга, не получив при этом никаких преимуществ перед конкурентами. Результатом является
“грязный код” – второй источник технического долга [31].
Технический долг в классическом понимании является преднаме- ренным и в основном касается стратегических решений, поэтому и от- ветственность за него лежит на заказчиках и архитекторах, но все, что