Опрос - рефакторинг

← →
КаПиБаРа © (2005-02-03 15:11) [0]

Сколько примерно % кода вы пишете сразу на чистовую (т.е. код не нуждается в рефакторинге)?
Сколько в среднем/максимум стадий рефакторинга приходится на функцию/модуль?

← →
Ega23 © (2005-02-03 15:14) [1]

Если глобально смотреть - то ~ 20%. ТЗ больно часто меняются... :-(

← →
TUser © (2005-02-03 15:15) [2]

0% - в рефакторинге нуждается все. Но не всегда руки доходят.

← →
Юрий Зотов © (2005-02-03 15:16) [3]

> КаПиБаРа © (03.02.05 15:11)

1. Примерно сто.
2. Примерно ноль.

При условии, что проектировал тоже сам.

← →
Игорь Шевченко © (2005-02-03 15:19) [4]

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

← →
Ega23 © (2005-02-03 15:21) [5]

При условии, что проектировал тоже сам.

Счастливый человек... Есть возможность проектировать самому...

← →
Sergey_Masloff (2005-02-03 15:27) [6]

Когда пишу 100% начистую.
Когда пройдет года три - думаешь какой рефакторинг переписать все на фик ;-)

← →
Юрий Зотов © (2005-02-03 15:27) [7]

> Игорь Шевченко © (03.02.05 15:19) [4]

> Любой код пишется начистовую...
... и при этом в него заранее закладывается возможность рефакторинга...
:о)

← →
КаПиБаРа © (2005-02-03 15:28) [8]

Игорь Шевченко © (03.02.05 15:19) [4]
почти любой код нуждается хоть в каком-нибудь, но рефакторинге

Вопрос в том делаете вы его (рефакторинк кода, который в этом нуждается) или нет? А если не делаете, то почему?

← →
Игорь Шевченко © (2005-02-03 15:43) [9]

КаПиБаРа © (03.02.05 15:28) [8]

Делаю, разумеется, если нужно.
А почему делаю - жизнь на месте не стоит.

Юрий Зотов © (03.02.05 15:27) [7]

А что, можно писать иначе ?

С уважением,

← →
Prohodil Mimo © (2005-02-03 15:45) [10]

Если заказчик не отклонится от первоначального задания, то никакого рефакторинга и не требуется, но такое довольно редко, обычно некоторые вещи приходится пересматривать.
ЗЫ. ТЗ сам составляю, другим не доверяю.

← →
wicked © (2005-02-03 15:53) [11]

> Юрий Зотов © (03.02.05 15:27) [7]

> ... и при этом в него заранее закладывается возможность
> рефакторинга...

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

← →
msguns © (2005-02-03 16:18) [12]

В зависимости от проекта.
Если работа чисто на заказ, то, как правило, правок очень мало. Только если существенно меняется ТЗ (например, структура БД), но это редко, да и сам виноват, на ТЗ "лоханулся"
Если проект "на витрину", в смысле под массовую продажу, то код лижется постоянно, даже когда прога уже "на ходу". Причем не редко, когда переписывается нафиг бОльшая часть кода.

Постановку и ТЗ делаю, как правило, сам.

← →
pasha_golub © (2005-02-03 16:26) [13]

msguns © (03.02.05 16:18) [12]
Согласен, про заказ и витрину.

← →
han_malign © (2005-02-03 16:51) [14]

>обычно некоторые вещи приходится пересматривать.
- "некоторые вещи" нужно предусматривать... Код нужно планировать гибким и масштабируемым - специально для этого придумывались всякие хитрые декомпозиции(например - модульная, функциональная и ОО). А в Delphi, со ссылками на классы, и С++, с шаблонами - сам Страуструп велел...

>то код лижется постоянно
>Причем не редко, когда переписывается нафиг
- это лечится - по методу ЮЗ и рекомендациям Страуструпа - накоплением базовых библиотек, хорошо структурированного, раз и навсегда вылизанного, с "возможностью повторного использования" кода.("reusable code"(c)Б.Страуструп - с первой до последней редакции, практически через страницу)

← →
Danilka © (2005-02-03 16:57) [15]

Серверная часть: вьюхи, процедуры, пакеты и т.д., по мере наполнения данными и добавления новых фич долго живут очень редко. Только самые простые.

← →
Сергей Суровцев © (2005-02-03 17:14) [16]

>msguns © (03.02.05 16:18) [12]

Так и есть.

>han_malign © (03.02.05 16:51) [14]
>это лечится - по методу ЮЗ и рекомендациям Страуструпа -

Это все замечательно, если есть МНОГО времени на предварительную подготовку и продумывание проекта и его реализацию, обычно же все упирается в очень жесткие сроки. Но все равно если он для широких масс, возникнет и масса непредвиденных требований. Но по большей части это касается не переписыванием кода как такогого, а заменой блока целиком в момент расширения функционала на вариант более настраиваемый и универсальный.

← →
Antonn © (2005-02-03 17:44) [17]

> Сколько примерно % кода вы пишете сразу на чистовую
> (т.е. код не нуждается в рефакторинге)?

5-10%

> Сколько в среднем/максимум стадий рефакторинга
> приходится на функцию/модуль?

1-3 / максимум не достижим :)

← →
Юрий Зотов © (2005-02-03 18:06) [18]

> wicked © (03.02.05 15:53) [11]

Основная идея - структура продукта и его движок должны быть спроектированы универсальными. Так, чтобы их можно было легко наращивать, но никогда не нужно было менять (по крайней мере, менять в принципе).

Как это делается - трудно сказать конкретно, во многом зависит от самого продукта. Основные инструменты - опыт и чутье. Плюс, конечно, структурирование, идеология наследования и полиморфизма (даже если речь не идет об ООП в его чистом виде, то идеи ООП вссе равно могут быть использованы). И т.п.

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

← →
wicked © (2005-02-03 18:09) [19]

> Юрий Зотов © (03.02.05 18:06) [18]
спасибо...

← →
msguns © (2005-02-03 18:18) [20]

>han_malign © (03.02.05 16:51) [14]
>- "некоторые вещи" нужно предусматривать... Код нужно планировать гибким и масштабируемым - специально для этого придумывались всякие хитрые декомпозиции(например - модульная, функциональная и ОО). А в Delphi, со ссылками на классы, и С++, с шаблонами - сам Страуструп велел...

Вашими б устами (или Страуструповскими)

Вы писали что-нибудь из области экономики или бухгалтерии, где было б активно заюзано действующее законодательство ? Если да, то тогда Вы должны себе представлять насколько эта самая деятельность у законодательства может измениться. Причем резко ! Особенно это касается зарплаты и всевозможных отчетов налоговой, пенсионному, ФЗ, соцстраху и хрен еще знает кому (список тоже меняется периодически). Вам знакомы, к примеру, понятия "льготы", "категории льгот", "диффререцированные шкалы" и т.д. ? Вы знаете, что все это может враз поменяться. И фиксированное отчисление стать по шкале, а "шкальные" диффрененцированы по категориям льгот ?

Как ЭТО можно предусмотреть ? Можно, конечно, как в свисте, забомбить формальное описание алгоритмов и переложить свои траблы на плечи (мозги, руки) будных бухгалтеров, но тогда и цена Вашему продукту, ИМХО, невысока.

← →
han_malign © (2005-02-03 18:34) [21]

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

← →
Юрий Зотов © (2005-02-03 18:52) [22]

> msguns © (03.02.05 18:18) [20]

> Как ЭТО можно предусмотреть?

А давайте рассмотрим три программы, построенные по таким схемам:
1. код - данные
2. код - описание_данных - данные
3. код - описание_алгоритма - описание_данных - данные

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

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

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

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

← →
Сергей Суровцев © (2005-02-03 19:04) [23]

>Юрий Зотов © (03.02.05 18:06) [18]
>han_malign © (03.02.05 18:34) [21]

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

← →
Сергей Суровцев © (2005-02-03 19:23) [24]

>Юрий Зотов © (03.02.05 18:52) [22]

Юрий, я охотно верю, что именно Ваша часть кода в рефакторинге практически не нуждается. Но спросите свой отдел внедрения, какая ситуация у них, и могут ли они себе позволить долго создавать универсальные решения в тот момент, когда нужны пусть жесткие, но быстрые.

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

Здесь Вы опять говорите о своей части работы. Описательная часть - это скрипты, реализованные внедренцами и обрабатываемые с помощью ядра. Ядро менять не придется, но скрипты обязательно и часто. А ведь программа - это все вместе, отдельно одно от другого никому не нужно.

← →
Сергей Суровцев © (2005-02-03 19:38) [25]

>han_malign © (03.02.05 18:34) [21]
>И если, при, довольно регулярном, изменении "действующего
>законодательства", Вам приходится делать рефакторинг, и
>выпускать новую версию - то получается, что за предыдущую
>версию Вашей программы заплатили зря? Или, все таки, методы
>внешних (без перекомпиляции ядра) настроек/расширений
>формальных алгоритмов, имеют право на жизнь?

Очевидно Win XP из Win 3.11 Вы получили без перекомпиляции ядра, а путем установки внешних настроек? Или же зря платили за все промежуточные версии.

← →
Jeer © (2005-02-03 19:47) [26]

Мда..
Который раз вспоминаю ту нимфу, которая уберегла меня от коллективной работы, после того как последняя мне надоела навзничь:)
Рефакторинг закладывается на этапе проектирования и складывается из вполне разделимых составляющих.
Ю.З тут не одинок:)))
Системная идея - Алгоритмы - Данные - Визуализация - Инструментарий
Не буду уточнять подчиненность(разветвленность) приведенного спуска.

← →
Marser © (2005-02-03 20:26) [27]

> Игорь Шевченко © (03.02.05 15:19) [4]
> Вопрос некорректный. Рефакторинг - не самоцель. Любой код
> пишется начистовую, и, почти любой код нуждается хоть в
> каком-нибудь, но рефакторинге. Особенно - чужой :)

Amen

← →
Юрий Зотов © (2005-02-03 20:35) [28]

> Сергей Суровцев © (03.02.05 19:23) [24]

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

Я в курсе, так что можно и не спрашивать...
:о)

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

Зато на следующее внедрение уже требуется меньшее время, потому что используются прежние наработки. А если еще учесть, что "следующих" внедрений много, то в итоге получаем снижение, а не увеличение сроков, трудозатрат, да и стоимости тоже.

Конкретно - в августе 93-го я вернулся в софтверную контору, из которой уходил за два года до этого. Вернулся на должность технического директора - то есть, человека, который рулит и проектом, и производством, и его технологией.

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

Сразу же начал, как мог, бороться с этой фигней. В том числе, используя то, о чем мы говорим. Результат - сейчас мы имеем ОДНУ программу и не особо большие отличия в БД для ВСЕХ клиентов, за счет этого сократили внедрение и поддержку, несмотря на это набрали несколько новых клиентов, внедрили в проект несколько новых фич и повысили его качество. Через годик планирую выпустить версию с новой цифрой в мажоре - и по сравнению с тем, что было, это будет уже СОВСЕМ другой продукт.

Вот что имею сообщить по поводу наших внедренцев. Им стало лучше. И не только им.
:о)

Для меня рефакторинг это стиль программирования. Стараюсь двигаться вперед небольшими, но закончеными версиями. Иногда принимаются ошибочные решения, что приводит к рефакторингу.

> ...в августе 93-го...

Блин, 2003-го, конечно. За 12 лет эти результаты можно было бы считать пренебрежимо малыми, а за 1.5 года - вполне неплохо.
:о)

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

Насчет того, какая часть кода пишется сразу "начисто" - где-то 95% (оставшиеся 5% - шлифовка и вылизывание мелких деталей, но это уже скорее черта характера :) )

> esu © (03.02.05 22:20) [31]

ERP. Писал уже, повторяться не стоит, а то сочтут за рекламу.
Подробности тут: http://www.elprise.ru

> All
Это правда не реклама, чес-слово. Просто использую те примеры, с которыми хорошо знаком.

/**КаПиБаРа © (03.02.05 15:11)
Сколько примерно % кода вы пишете сразу на чистовую (т.е. код не нуждается в рефакторинге)?
Сколько в среднем/максимум стадий рефакторинга приходится на функцию/модуль?
*/
1. Нисколько. Весь код "грязный".
2. Зависит от достижимости целей. Цель достигнута на данном этапе - код оставляется в "покое", цель меняется - меняется код.

P.S. А что Вы лично понимаете под "рефакторингом"? У меня создаётся смутное ощущение, что немного не то Вы понимате, говоря о "стадиях". От стадии к стадии обычно функциональность кода не меняется, но меняются характеристики: повторное использование и надёжность. Защита улучшается, а прямая ыункциональность - нет. Всё остальное делается на этапах анализа ТЗ и проектирования.

/**КаПиБаРа © (03.02.05 15:11)
Сколько примерно % кода вы пишете сразу на чистовую (т.е. код не нуждается в рефакторинге)?
Сколько в среднем/максимум стадий рефакторинга приходится на функцию/модуль?
*/
1. Нисколько. Весь код "грязный".
2. Зависит от достижимости целей. Цель достигнута на данном этапе - код оставляется в "покое", цель меняется - меняется код.

P.S. А что Вы лично понимаете под "рефакторингом"? У меня создаётся смутное ощущение, что немного не то Вы понимате, говоря о "стадиях". От стадии к стадии обычно функциональность кода не меняется, но меняются характеристики: повторное использование и надёжность. Защита улучшается, а прямая функциональность - нет. Всё остальное делается на этапах анализа ТЗ и проектирования.

опс. прошу прощения за дубль.

>Юрий Зотов © (03.02.05 20:35) [28]
>Вот что имею сообщить по поводу наших внедренцев. Им стало
>лучше. И не только им.

Да я и не сомневаюсь, что стало лучше. Сам через многое из описанного проходил. И насчет напинания общих моделей тоже согласен. Но как не старайся, но у внедренцев никогда не будет Вашего соотношения ~100/~0. А в самом лучшем случае 80/20 на однотипных объектах.
И зря стесняетесь рекламы. Всегда интересно, что делают коллеги, особенно когда есть на что посмотреть.

> Сергей Суровцев © (03.02.05 23:23) [37]

> в самом лучшем случае 80/20 на однотипных объектах.

Видимо, да. Работа у них такая, у внедренцев - все нужно вчера.

Но движок надо стараться делать 100/0. Иначе внедренцы и поддержка совсем загнутся. А с ними и продукт и, вполне возможно, сама контора.

> Юрий Зотов ©
> Но движок надо стараться делать 100/0

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

[22] Юрий Зотов © (03.02.05 18:52)
> А давайте рассмотрим три программы, построенные по таким
> схемам:
> 1. код - данные
> 2. код - описание_данных - данные
> 3. код - описание_алгоритма - описание_данных - данные

Ну, вообще-то во всех трех схемах придется затрачивать время на доработку. :)
Хотя, конечно, доработка серверной части, намного легче и проще для установки клиентам, чем каждый раз в паскале ковыряться и рассылать бпл-ки.
Правда, все это как-бы и не рефакторинг, а развитие..

Опрос - рефакторинг Найти похожие ветки