Как стать автором
Обновить

Комментарии 47

Увидеть удачные примеры refucktoring'a лично мне интересно
Мне тоже :) *не удержался*
Знаете, я несколько раз предлагал рефакторинг клиентам с самописными ЦМС — объяснял, что их система обросла заплатками и масса их приближается к критической…

Ни разу никто не согласился оплатить эти работы — «нннет… вы знаете… просто посчитайте сколько у вас займет добавление вот тех фич, что я вам скинул… а это у нас конечно в планах, но не сейчас»…

И так говорят люди у которых я в коде находил комментарии типа «//платят, ну и хуй с ним..» и тому подобное, от предидущих фрилансеров… ))
По идее, клиенты правы — им не холодно и не жарко от качества кода. Другое дело, что если им объяснить, что после рефакторинга стоимость поддержания и изменения системы резко уменьшится, тогда может они бы и задумались.
Вы забыли об одном из способов рассказать о рефакторинге заказчику/менеджеру: Don't tell. Это ваша ошибка.
пипц. я как то раз взялся за такой код. там всего то надо было чуть функционалу подкинуть в вап чат. денег было немного. потом пописал-пописАл и взял и переписал =)
Думаю стоило положить перед заказчиком два проектных плана- с рефакторингом и с использованием текущего кода, в каждом расписать временные затраты, цену и преимущества/недостатки способа. И пусть клиент сам решает, что для него важнее.
Расписать технические(например) преимущества заказчику в доступной для него форме (предполагается по-умолчанию что он не сведущ в IT) бывает довольна сложно.
Но вот цену и время в конце документа он сразу увидит, на неё он скорей всего и будет ориентировать в первую очередь.
Интересно. — Давай продолжение
Даешь полную статью!
А я думал, что только у меня на работе такие проблемы :) Жду продолжения. P. S. В нашей конторе мы приняли решение все начать с чистого листа.
Правильными являются два варианта: или все заново или рефакторинг, все зависит от конкретных условий.
НЛО прилетело и опубликовало эту надпись здесь
Ну я думаю подразумеваются реальные недостатки или нехватка функционала.
НЛО прилетело и опубликовало эту надпись здесь
Третий путь — сделать рефакторинг частью процесса. В общем-то, только так он и имеет право называться рефакторингом, если по сути. Ибо ситуация мол «вот мы два года писали да наслаивали — давайте теперь полгода рефакторить» не влезет ни в какой бюджет. Только постепенно. В идеале — с самого начала.
Историческая драма? :)
Задолго до интерфейсов и ООП, перед появлением модулей, когда трава была по-настоящему зеленой, а в овощах не было нитратов — жили-были монолитные системы.
Они были маленькими и безобидными на вид. Ничто не предвещало беды.

Извините, не удержался…
:)
Вот так и надо начинать в школьных учебниках по биологии и эволюции :)
НЛО прилетело и опубликовало эту надпись здесь
Поддерживаю — не понятно, что в продолжении ожидается.
Да, было бы здорово!
Нагло жду плюсов!
Неизвестно еще что сложнее: чистый лист или рефакторинг проекта, состоящего преимущественно из «Я не знаю как это работает, но если удалить то все падает — НЕ УДАЛЯТЬ!!!».
С чистого листа однозначно лучше и проще, притом всегда: использование новых технологий и оптимизация никому во вред не пойдет.
Но всегда есть такой фактор, как цена вопроса, и он в большинстве случаев убивает все надежды=\
Вы издеваетесь? Конечно продолжайте)
Продолжайте. Как раз сейчас занимаемся переписыванием такого наследия.
Решились-таки на практически «с чистого листа».
Очень интересная тема. Хотелось бы узнать про методики, ну например пишут ли в таких случаях тесты, если да то как убедиться в их правильности, после конечно рефакторинг.
Есть отличная книга Фаулера, называется Refactoring (http://www.amazon.com/Refactoring-Improving-Existing-Addison-Wesley-Technology/dp/0201485672)
А также несколько книг про паттерны рефакторинга.
А также хорошая книга про старый код: www.amazon.com/Working-Effectively-Legacy-Robert-Martin/dp/0131177052/ref=pd_bbs_sr_1? ie=UTF8&s=books&qid=1219346607&sr=1-1

Вы сможете написать про рефакторинг и переделку старых систем что-нибудь, чего еще нет в этих книгах?
О за последнюю спасибо, не знал.
Присоединяюсь к мнению bishop3000, с единственной разницей: на первое место я бы поставил Working Effectively with Legacy Code
Ну, это от задачи зависит.
Если задача — тотальный рефакторинг, то Фаулер рулит.
Если просто поддержка легаси кода, то последняя книга, т.к. оказывается, что и рефакторить его не всегда надо :).
Интересным примером может служить перевод мощнейшей ERP системы на свеженькую платформу. Имею ввиду SAP Netweaver 7.0 и ECC 6.0, бОльшая часть самой ERP (ABAP код) не потерпела изменения с тех самых 90-х.
Сразу извиняюсь, что не удержался. Про легаси значит. какое-то время назад (5 лет) я жил и работал в Кремниевой Долине. И вот один мой американский друг пригласил меня на некое семейное торжество в доме своих бабушки (75 лет) и дедушки (80). В маленьком и очень уютном домике в городке Palo Alto. И вот когда мы выпили по 3-4 бокала калифорнийского вина, выяснилось, что бабушка проработала 40+ лет программисткой в NASA. Вместе с дедушкой. И все. Остаток вечера мне пришлось отбиваться от многочисленных претензий по поводу «новомодного языка FORTRAN», отдуваться по поводу отмены ввода кода через перфокарты и прочее.
Добил меня конечно аргумент дедушки про то, что раньше у программиста не было права на ошибку, но зато можно было покататься на лодке по озеру, пока твой код стоит в очереди на обсчет…
К чему я это? Ну, типа, take it easy, buddy, конечно, пиши дальше. Когда возникают проблемы легаси кода, я (лично) глубоко вдыхаю-выдыхаю и просто пытаюсь поставить себя на место тех самых бабушки-дедушки. Помогает :)
В последнем абзаце s/Харба/Хабра
done, думаю давно пора в словари вносить Хабр-словоформы ;)
НЛО прилетело и опубликовало эту надпись здесь
блииин, ну лучше б сразу все написали, а то заинтересовали и бросили на полпути
Приложение(схемы) которое опубликовал с утреца, публике оказалось недостаточным для отдельного материала, так, что придется подождать продолжения чуть подольше. Идея небольших-эпизодических статей не прокатила ;)
НЛО прилетело и опубликовало эту надпись здесь
«правильный вариант — это написание системы с нуля» — это ясно понятно, но сложнасть в том что у данного решения слишком большая «цена вопроса» хотя весь отдель IT в один голос только об этом и говорит но начальство на текущей работе не выделяет под это достаточно ресурсов — с чем сталкиваюсь не в первый раз, о чем собственно и цикл статей.

«Рефакторинг же это изменение кода до правильного» — да, и о нем будет чуть позже сейчас о нем речи не идёт.
Вообще тема интересная. По крайней мере мне. Тем более у меня есть один успешный (на мой взгляд) опыт поэтапного рефакторинга проекта, начиная с ядра и заканчивая представлением. Сам статью написать не могу, так хоть в комментах своим опытом поделюсь.
Интересно, пишите.
Похоже на перевод с английского. Люди редко самостоятельно пишут фразы вроде «внести изменений в ядро». В любом случае — нехорошо.

done.
Пишут, пишут-после сдачи проектов до ночи — ага ;) Проглядел совсем, по мере возможности вношу правки, спасибо за наводку.
ИМХО, переписывать нельзя пока продукт не уперся в тупик. Тупик может быть разным: от «на уровне разработки: чтобы вовт тут добавить текст мне нужно 2 недели», до «на уровне клиента: вы это говно продуктом назваете оно же тормозит и глючит, а более отстойного интерфейса я еще не видел». Пока меньшей кровью можно расширять функционал уже рабочего продукта — так и надо делать. Все эстетические соображения не совсем уместны в данном случае, в конце концов — это бизнес.
Переписать оно всегда кажется проще пока не начинаешь переписывать и разбирать функционал наработаный за те самые долгие годы припараций, вживлений и пришиваний. Встречаются случае когда «переписывание» глохло из-за того что разработчик (группа) был не готов к реалиям продукта и не расчитал сил, или еще хуже получался монстр еще страшнее.
Но как не крути рано или поздно наступает момент когда заявленый функционал не реализуем без значительных изменений в коде и структурах данных. Вот когда наступает такой момент, и не раньше, есть смысл переписывать, ИМХО.
Интересно.

Только надо в sandbox`е обсудить статью, чтобы получилось слитно, красиво и эффективно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации