Рефакторинг как механизм обратной связи
| November 15, 2006 | Posted by Denis under Практики, Статьи |
Рефакторинг — изменение существующего кода без изменения функциональности. Цель рефакторинга — улучшение внутренней структуры проекта. Не каждый из классических процессов уделяет достаточное место фазе рефакторинга, так как его нельзя предугадать и жестко определить в плане. В отличии от плановых процессов, гибкие методологи позволяют адаптироваться к меняющейся структуре проекта в большой мере.
В методологии Agile рефакторинг считается нормальной практикой и является средством гибкого проектирования архитектуры. В статье обсуждается место рефакторинга как отдельного процесса на этапах разработки.
В ходе развития проекта и решения текущих задач первоначальная архитектура проекта начинает меняться. Этот процесс динамический и не поддаётся контролю в полном объёме, а тем более планированию. Сложности добавляют постоянно меняющиеся требования к системе. Для борьбы со сложностью проект разбивают на ряд уровней (от концептуального до уровня реализации). Преимущественно поток знания о проекте направлен от уровня концепции к реализации, а обратная связь не проявляется. Её сложно использовать, так как разрозненные «заплатки» кода не дают общей картины для проведения этих изменений на концептуальный уровень.
Проблемы обнаружения и решения переносится на плечи разработчика. Архитектор и аналитик, выполняя проектирование, руководствуются общими принципами, своим опытом и имещимеся знаниями. Но такой подход не может обнаружить потенциальные проблемы пока не наступит фаза реализации. Другая дилемма – многие проблемы осознаются только разработчиками, во время кодирования или модификации существующего кода. Во время написания кода разработчик рассуждает “что-то здесь не так, но у меня нет времени сейчас разбираться”, его беспокоит какое-то внутреннее чувство. Но через день это чувство забывается, так как уже работает над другой частью кода, а там аналогичное желание вытесняет из головы вчерашнюю озабоченность. Этот процесс повторяется из-за дня в день, из недели в неделю. Появляются заплатки на заплатки, разработчикам требуется дополнительное усилие для введения новой функциональности или исправления ошибок. Проектное время увеличивается бесконтрольно и без возможности как-то оценить. И самое плохое, никто не может назвать, почему так случается. Архитектор в точки зрения концепции не видит проблем кода, программист из-за «срочности» дел откладывает и не озвучивает свои мысли. А долги проектирования накапливаются.
Как такую ситуацию можно исправить. Известно, что процесс разработки программного обеспечения постоянно развивается. Этап непосредственного программирования состоит из следующих шагов: постановка задачи – программирование – сборка – тестовая прогонка – отладка – внесение изменения – сборка и так далее до достижения приемлемого результата. Выделим две составляющие – программирование (плюс отладка) и внесение структурных изменений. Эта активность планируется в бюджете проекта, как единая часть – программирование. Программирование как процесс активного добавление нового функционала. Но внутри этого процесса происходит постоянная переделка в рамкам каждой задачи. А теперь подумайте, как происходит добавление нового, когда это новое добавляется в момент хаотической, незапланированной и бессистемной переделки.
Разделяем процессы
Наша задача выделить процесс переделки отдельный этапом. Процесс внедрения новой практики представляется в схеме: оценка – анализ – синтез. Этап оценки мы прошли – мы осознали, что процесс создания новой функциональности и адаптация (изменения) существующего кода – это два важных и разных процесса. Их нужно делать раздельно. Здесь сомнений нет.
Анализ
Второй шаг – «анализ». Цель которого – выделить отдельно часть переделки, и сделать её задачей, которая должна решаться отдельно. Сами посудите, как можно качественно решить задачу, когда вместо неё целых две! Выделенный процесс ограничим строгим условием – во время переделки никаких изменений функциональности. Такой процесс называется рефакторинг.
Теперь наша схема работы будет выглядеть как цепь с устойчивой обратной связью. А мы знаем, что обратная связь только повышает устойчивость системы. Вспомните из курса физики: что будет, если система без цепи обратной связи? Он развивает случайно и в какой-то момент достигает порога прочности и рушится. В программировании рефакторинг, как механизм обратной связи, внесёт не только устойчивость системы, но добавит и другие положительные качества – понимаемость кода, повторного использования, расширяемости и самого главного гибкости. Не те ли это принципы, о которых говорится во всех учебниках программирования?
Какую продолжительность занимает процесс внедрения рефакторинга в команде? Необходимо время на обучения механизмам рефакторинга, а это ряд курсов в течении 1-2 недели, либо чтение книг (что менее эффективно, так как отсутствует возможность внешней мотивации, да и обсудить не с кем). В дальнейшем в течение квартала выделять на рефакторинг в зависимости от нагрузки от 15-50% от кодирования, чтобы закрепить практики, чтобы закрепить осознание раздельности программиорвания и проведения рефакторинга. Первый месяц проводить рефакторинг низкого уровня, продолжительностью до часа. А затем возможна разработка более крупномасштабного рефакторинга. Который может длится до нескольких дней. Здесь важен план проведения рефакторинга, влияния изменение должно быть оценено и проведено исследование возможности проведения.
Синтез
После качественного усвоения принципов рефакторинга, закрепление его в течение 3 месяцев в качестве отдельного этапа разработки команда может принять решение интегрировать в этап разработки рефакторинг. Так рефакторинг уровня кода внедряется в стадию кодирования и становится неотъемлимой частью. А высокоуровневый рефакторинг применяется при необходимости в качестве отдельного процесса.
Еще одна проблема – smell на более высоких уровнях. Разработчик, обученный рефакторингу, легко выделит проблемный код той части программы, с которой он сейчас непосредственно работает. Но как быть с уровнем архитектора? Уже давно известны принципы: модульности, минимальной связанности и т.п. Но как может архитектор оценить – в каком состоянии сейчас находиться система. Эта задача выходит за рамки практической разработки, сейчас введётся большое количество научных исследований в сфере оценки проблемности кода, целесообразности автоматического преобразования и оценки безопасности преобразований. До нас лишь доходят результаты в качестве различных приложений, для примера можно привести: SAJ4, Dr.Freud, Sotograph.
Часть Процесса
Фаза рефакторинга является частью процесса ориентированного на качество программного продукта. Agile практики, ориентированные на вовлечение заказчика в процесс разработки, как члена команды, позволяют материализовать проблемы нижнего уровня. И если в проект добавляются новые требования, требующие значительного изменения архитектуры, то теперь клиент будет более трезво оценивать риск и бюджет проведение такого преобразования.
Рефакторинг является эффективным механизмом обратной связи, если архитектура начинает попахивать (smell – потенциально проблемный код). Отдавать по долгам нужно вовремя. Подумайте, к чему приведёт невыплоченный вовремя долг в банк?
-
Leo Maddy
