Продолжаем батл по рефакторингу 
Вчера начался первый батл по рефакторингу, но с предложениями пока как-то куцо, точнее их совсем нет. Чтобы немного оживить процесс я сделал рефакторинг своего собственного варианта. В этом посте хочу поделиться рецептом приготовления нового кода.
Когда речь заходит о рефакторинге многие впадают в ступор, искренне не понимая как изменить код в лучшую сторону. Я сам сталкивался с такой проблемой. Смотришь на код, видишь, что он делает, видишь, что он выглядит как-то не очень, но все равно не понимаешь как сделать так, чтобы он стал выглядеть лучше. Что-ж, раз полезное сделать не получается, то предлагаю потренироваться делать бесполезные рефакторинги. Об одном из них речь пойдет дальше.
Итак, постом ранее я представил на рассмотрение свой код http://www.pastie.org/1264003. По поводу которого получил вполне справедливое замечание - а нафига в этом коде класс FileGenerator? Очевидно, что реализация всей поставленной задачи может уместиться в одну рекурсивную функцию. В настоящем, серьезном проекте я возможно так и сделал бы, но так как батл по рефакторингу - это не совсем серьезная вещь, а скорее разминка для мозгов, то я решил использовать ООП для дальнейшего усовершенствования кода.
И вот что из этого получилось - http://www.pastie.org/1266613.
Для приготовления рефакторинга я использовал понятие полиморфизма - смысл которого сводистя к тому, что для одной и той же функции сделано две разные реализации. Далее я создал небольшую фабрику, которая в зависимости от типа объекта (файл или каталог) генерирует нужный объект. В итоге получилось, то что получилось.
Интересно услышать ваши замечания, предложения и просто откровенный стеб :-).
подписаться на блог
Евгений
Гость
Ладно. Напишу то, как я понимаю рефакторинг.
Главная аналогия это почва (имеющееся приложение) и цветы, овощи и прочая флора (фактически новый функционал), которые нужно вырастить (интегрировать) на имеющейся почве. Иногда это трудно, так как почва не готова. Вот её рекультивация, удобрение и прочее улучшения есть рефакторинг. Другими словами, рефакторинг - это улучшение кода для возможности внесения в него изменений добавляющих новый функционал. Рефакторинг не используется для выяснения ошибок, рефакторинг не используется для изменения функционала. Он нужен только для облегчения работы с кодом. Если с кодом никаких работ не предполагается, то о рефакторинге можно забыть.
Исходя из своих соображений я делаю вывод, что батл по рефакторингу - занятие пустое. Заранее то не определено, какие новые функциональные требования нужно внести. А если их нет, то и рефакторинг не нужен.
Обычно считается, что рефакторинг нужен после прохождения всех тестов. Я думаю иначе. Рефакторинг - это подготовка кода к внесению изменений. Только в таком случае он осознан, контролируем как в затратах времени, так и частей кода.
Evgeny Sergeev
Веб-разработчик, автор блога codeart.ru
Евгений, если мы говорим про agile development, то там рекомендован следующий цикл - тест, красная полоса, зеленая полоса, рефакторинг. Рефакторинг должен выполняться регулярно или не выполняться вообще.
Цель рефакторинга в том, чтобы упорядочить мысли программиста. Первый вариант кода нужен только для того, чтобы построить тесты и осознать детали проблемы. Если сразу не сделать рефакторинг, то спустя время будет сложно вспомнить все нюансы.
Да и сделать рефакторинг не так просто как кажется. У большинства рефакторинг - это разбиения кода на функции и замена имен переменных. Т.е. фактически размазали все по функциям и типа сделали рефакторинг. Поэтому выражать свои мысли и рефакторить код нужно учиться. Другого пути я не знаю.
Еще очень интересно увидеть примеры вашего кода.
Евгений
Гость
Evgeny, вы в плену стереотипов.
Конец - это чьё-то начало. Если его нет, то и рефакторинг не нужен. Если последует новая итерация с внесением нового функционала, то рефакторинг - это граница между прошлым и будущим. Не важно отнесёте вы рефакторинг к концу прошлой итерации или новой.
Рефакторинг не упорядочивает мысли, он упорядочивает совесть программиста. Его можно сделать в голове и без изменения кода. Это позволит в следующий раз писать простой работающий код затрагивающий только некоторое соответствие требованиям.
Кстати, рефакторинг позволяет избавится от построения круглого коня в вакууме. Это застолбление функциронала минимальным кодом. Именно с таким простым и выполняющим лишь определённую задачу кодом можно строить дальше приложение, добавляя на него функционал.
Первый вариант кода для построения тестов не нужен. Тесты должны быть раньше кода или иначе мы начинаем подгонять тесты под код. Мало того, можно вообще обойтись ручным тестом, если требование определено уже. Если требования нет, то значит мы не знаем что делаем.
Насчёт постоянного рефакторинга я согласен, но опять же с точки зрения очистки совести программиста. Хороший код можно писать только делая работу над ошибками. Но есть и другая грань - перфекционизм/мазохизм. Так вот, нет хорошего кода. Есть работающий.
Ну и возможно как-нибудь я дам ссылку на свой код. Пока не вижу смысла.
Evgeny Sergeev
Веб-разработчик, автор блога codeart.ru
Евгений, не вижу смысла что-то обсуждать, если Вы прячете свой код.
Leave a Reply