LINUX.ORG.RU

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

anonymous
()
Ответ на: комментарий от anonymous

afaik, рефакторинг -- это когда если тебе не нравится имя класса/функции/переменной, то можно его легко поменять на новое. С одной стороны это удобно, с другой -- провоцирует плохо думать при проектировании.

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

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

anonymous
()

Лучше взять самому и почитать книжку которая так и называется.
Вопрос-то сводится не к не подумал, а потом трахается,
а вообще к возможности быстро модифицировать что-то по запросам
пользователей. А как за них (как кажется дураков) не думай,
но так как они думают не придумаешь.
Всегда им надо добавить что-то дабы испоганить пару красивых идей,
которые как казалось обеспечат любой вид расширения.
Как говорилось в одной книге после 5 лет потраченных на составление
ТЗ (не у нас) через полгода тестирования результата выяснилось
что 80% заложенного - фигня.
Аналогичные проекты (месяцы на ТЗ) с аналогичными оценками после
получения результата обнаруживал и в нашем королевстве.
А стоит ли шибко напрягаться в начале при планировании
если в ваших руках средство с помощью которого можно быстро
вносить сотни изменений? Т.е. столько сколько реально просят
пользователи.
Иногда стоит, но вот сколько времени стоит?
Стоит ли это делать всегда?

io ★★
()
Ответ на: комментарий от io

Биип. Неправильный ответ.

Рефакторинг, по определению, есть правка кода *без изменения функциональности*. От ручного редактирования отличается
1. применением стандартных красиво названными приемами
2. применением редакторов, поддерживающих эти приемы

Ни пользователи, ни расширения, ни ТЗ здесь ни при чем.

vnp
()
Ответ на: комментарий от vnp

Надо думать что оные красивые приемы только для красоты применяются :-)
И цели иной не имеют :-)
И пишут по этому поводу толстенные книги, маньяки :-(
Странно получается.

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

Если таки собраться книги почитать, то:
1. Названия методов названы не особо красиво. Так сразу и не скажешь
по названию о чем.
2. Хорошо бы, конечно, чтобы редакторы путно поддерживали изменения.
Да где такие взять. Те что якобы поддерживают после каждого
изменения заставляют с бубном прыгать.

А по поводу пользователей, ТЗ и расширений - это же каждый в любом
средстве свое находит. Впрочем и в книгах в первую очередь ставят
целью не сам рефактринг (как метод который и правда не должен
трогать функциональность), а средство для получения именно тех самых
бонусов в виде удовлетворения пользователей, ТЗ и организации
расширений.

Поэтому и примеры все приводятся в стиле:
1. Предположим вы выполняли ТЗ и код был следующим ...
2. Предположим пришел запрос на расширение следующего вида ...
3. Если вы осел, то решение может быть следующим ...
4. Если овса вы уже наелись, то попробуем слегка подправить код так,
чтобы расширения данного вида легко агрегировались бы в него.
5. Проверим что мы не испортили функциональность в терминах
старой жизни.
6. Добавим новую функциональность изменением пары-другой строк.
7. Посмотрим что еще позволят добавить/изменить данный код
без существенных изменений классов.

И какова же после этого цель книги?


io ★★
()
Ответ на: комментарий от vnp

> Рефакторинг, по определению, есть правка кода *без изменения функциональности*.

без изменения функциональности это code sweep..

anonymous
()
Ответ на: комментарий от io

> А по поводу пользователей, ТЗ и расширений - это же каждый в любом средстве свое находит. Впрочем и в книгах в первую очередь ставят целью не сам рефактринг (как метод который и правда не должен трогать функциональность),

Отлично, в одном мы сошлись. Теперь давайте сойдемся в другом:

> а средство для получения именно тех самых бонусов в виде удовлетворения пользователей, ТЗ и организации расширений.

Разумеется, рефакторизуют не от любви к искусству (хотя я и это проделывал, грешен), а под давлением сторонних сил. Действительно, все книги -- в примерах -- смешивают *преобразование* кода с его *развитием*. На мое имхо, так поступают исключительно для наглядности: чтобы убедиться, как легко стало добавлять функциональность, ее нужно-таки добавить. Что не меняет сушества дела.

Peace.

vnp
()
Ответ на: комментарий от vnp

Вот блин, была война, а я и не заметил.
Надоело шаркание в окне пошел в курилку примус починить, языком
почесать и вдруг трах-бах. И главное без повода, ружом не махал,
rm -rf /* (как местные lor-террористы) не предлагал.
Предупреждать же надо "иду на вас". Чай не 41-ый год.
Хотя что 41-ый, что 2004 - блин :-(

А по поводу нагладности правильно. Чисто методически неправильно
в нашем случае разделять цели и методы. Цель-то какая - научить
использовать методы, а смысл их в достижении определенных целей.

Что есть рефакторинг для большинства - модное слово. Даже деньги,
если суметь, под слово можно получить. А ведь по сути меняли код
и меняем, но теперь круче меняем, а главное после обобщения и правда
могут автоматизиролванные средства появляться, хотя весь спектр
никогда и не покроют.

Если попробовать студентам тот же рафакторинг в стиле групп излагать,
что будет?

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

... Греет? Студенты от холода замерзнут.

В данном случе ответ ЗАЧЕМ НУЖЕН значительно более разумен чем ШО
ЭТО БЕРЕМОР.

Ну а так в курилке мир. При мне не стреляли.



io ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.