что делать с кодом?

я конечно не супер-мега-хацкер-программист, но скажу свое ошибочное мнение что поддерживать это будет нереально

переписать МОДУЛЬНО, вообще писать софт надо более менее модульно, модули тестировать и затем склеивать

раз говоришь «функции с 20-ю параметрами по тысяче строк» - значит писали балбесы-быдлокодеры-старперы, думаю переписать будет целесообразнее, ведь тебе отвечать за этот код - ты готов?

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

[berserk mode] как отрефакторить 40к строк легаси-кода? - похожий тред

толпа цифровых констант (я видел пятизначные), функции с 20-ю параметрами по тысяче строк

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

тогда яснее ясного - была ориентация на тогдашние стандарты качества, а наилучшее качество(как и опыт программирования) было у фортрана и всё строилось подобно ему. Да и большая часть функций-просто реплики с фортрана.

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

Считаю этот подход правильным - пытаться реинженирить «есть пару миллионов строк кода, написанного несколькими поколениями программистов» при ограниченных ресурсах - утопия

что делать с кодом?

1. Снабжаем систему как можно большим количеством автоматизированных тестов. Счет должен идти на десятки тысяч тестов, с более-менее равномерным покрытием всей существенной функциональности. Организуем еженощный (или даже per-commit) прогон тестов, с рассылкой писем в случае слома доселе работавших тестов.
2. Рефакторим код так, чтобы разбить его на слабо связанные друг с другом модули.
3. По мере необходимости переписываем некоторые из модулей, но так, чтобы их интерфейсы оставались неизменными.

переписать МОДУЛЬНО

за единицу модуля надо брать сразу ~100к строк кода для переписывания, который непонятное где и непонятно кем будет дергаться в неявном виде. т.е. сайдэффекты во все поля. даже один такой модуль переписать, без тестов, за обозримое время не реально ;)

ты даже на первый естественный вопрос «как долго это переписывать» ответить не сможешь ))

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

да.

пытаться реинженирить «есть пару миллионов строк кода, написанного несколькими поколениями программистов» при ограниченных ресурсах - утопия

я тоже света в конце тоннеля не вижу. с другой стороны этот код уже сейчас обрастает феерическим набором костылей «лишь бы не упало».

Рефакторим код так, чтобы разбить его на слабо связанные друг с другом модули

приличный рефактор для дельфей не подскажешь? :)

По мере необходимости переписываем некоторые из модулей, но так, чтобы их интерфейсы оставались неизменными.

я смотрю на модуль в 22к строк. if else if else if else if... 22к. тысячи констант, тысячи обращений [1] [2] ... [333].

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

так этот код еще и на дельфи написан? я правильно понял?

Нужно приводить код в порядок по частям. Сначала чистить легаси, потом постепенно рефакторить остатки, по мере возникновения проблем. Как-то так.

код еще и на дельфи написан?

да.

приличный рефактор для дельфей не подскажешь? :)

но если это делфи, то проще забить и поменять место работы.

и вот вопрос: что с этим делать? оставить как есть? поддерживать прямо скажем сложно. начать переписывать? этот код писался не год и не два, частично он стабилен и хорошо работает, а переписывание --- это пройтись по всем граблям по новой :).

Переписывать потихоньку. Если функции по 1000 строк и с кучей параметров, значит велика вероятность того что там 95% велосипедов, состоящий из duplicated code.

Нужно приводить код в порядок по частям.

дада, вот у меня есть часть кода: if 27005 then return 388;

и такого добра не тысяча и не две строк. и цель бизнеса не в чистоте кода, а в его работоспособности. т.е. «переписать» как цели у бизнеса нет. это время на перепись, время на тесты, время на подгонку «как было» у конечного пользователя, которому новое поведение системы совсем ни к чему, он «привык». в конце концов это все деньги. бизнес деньги как водится жопит. специфика.

и такого добра не тысяча и не две строк. и цель бизнеса не в чистоте кода, а в его работоспособности. т.е. «переписать» как цели у бизнеса нет.

ах, так это ещё не какой-то сраный НИИ, а бизнес? Ужас..

Вопрос всё равно за тобой - нужно ли бизнесу дальше как-то развивать этот код или нет. Если нужно, то, очевидно, без ничегонеделанья сложность поддержки будет расти лавинно, т.е. будете тратить больше денег для внедрения каждой новой фичи и когда-нибудь настанет пц

А если развивать не нужно, а тупо фиксить баги, то логично просто забить.

о, ты попал

я бы за такую систему не взялся

и такого добра не тысяча и не две строк. и цель бизнеса не в чистоте кода, а в его работоспособности. т.е. «переписать» как цели у бизнеса нет. это время на перепись, время на тесты, время на подгонку «как было» у конечного пользователя, которому новое поведение системы совсем ни к чему, он «привык». в конце концов это все деньги. бизнес деньги как водится жопит. специфика.

судя по треду, решение как быть с кодом, вольно-невольно уже есть. Возможно нет 100% уверенности в его правильности, и поэтому заведён топик. В ожидании что кто-то подскажет дополнительные аргументы, что Вы поступаете правильно.

Ну так вот: вы приняли правильное решение. Но как бы вы не поступили, в будущем Вы поймёте, что это ошибка.

Да ты жжошь, как я посмотрю... =)

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

На 2 миллиона строк? Скорее всего какая-то Ъ-ынтерпрайз система по автоматизации какого-то процесса. Я когда-то давно тоже в такой шараге работал. ~2 миллиона строк, писавшихся с 90х. Это был беспощаднейший быдлокод, который по большей частью лежал мертвым грузом, но выкидывать какие-то куски или переписывать что-либо начальство боялось, ибо Ъ-ынтерпрайз. А это всего лишь была система по продаже сраных билетов :)

и вот вопрос: что с этим делать?

Зависит от того кем ты там работаешь и что за это тебе будет.

Тред не читал, но на хабре в комментариях видел вот что.

Сам пост

Я бы уволился.

Дельфи морально устарел, через пару лет и поддерживать ваш проект возможно будет некому.

Можно новую функциональность разрабатывать как новые приложения. Для коммуникации со старым кодом организовать какие-то сервисы. И постепенно переносить функциональность.

Зависит от ситуации. Если простым смертным работаешь, то выход один — увольняться.

и такого добра не тысяча и не две строк. и цель бизнеса не в чистоте кода, а в его работоспособности. т.е. «переписать» как цели у бизнеса нет. это время на перепись, время на тесты, время на подгонку «как было» у конечного пользователя, которому новое поведение системы совсем ни к чему, он «привык». в конце концов это все деньги. бизнес деньги как водится жопит. специфика.

такой бизнес должен страдать :)

бизнес деньги как водится жопит. специфика.

А тогда зачем вы тратите своё время и талант на такое? Скупой платит дважды. Они двадцать лет экономили даже на doxygen-комментариях, ну так пусть теперь расплачиваются. Тратить свою жизнь, чтобы оттянуть момент расплаты ССЗБ, бессмысленно.

Если вы там что-то решаете, но сами не можете решиться дать отказ, установите им тариф так, чтобы можно было 1 месяц писать и 5 месяцев тестировать/разбираться.

А тогда зачем вы тратите своё время и талант на такое? Скупой платит дважды. Они двадцать лет экономили даже на doxygen-комментариях, ну так пусть теперь расплачиваются. Тратить свою жизнь, чтобы оттянуть момент расплаты ССЗБ, бессмысленно.

согласен, если они считали что писать так по-школярски это нормально - пусть расплачиваются за легкомыслие

знали же что спецы уйдут и надо будет это поддерживать - не удержали их, не заставили хотя бы прокомментировать

Я бы уволился.

вполне разумное решение, поддреживаю

Тред не читал, но на хабре в комментариях видел вот что. Сам пост

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

Чищу так проект в 100 тыщ строк уже год в фоновом режиме. Кажется, только недавно подошёл к пониманию, как оно всё работает, но и то не ручаюсь. И это при том, что код не такой уж и ужасный. А если у тебя правда такая лапша, как описываешь, да ещё и много, то беги оттуда. У тебя жизнь одна, а в такое болото можно утопить тысячи!

приличный рефактор для дельфей не подскажешь? :)

Голова и руки. Это основной инструмент для любого ЯП.

я смотрю на модуль в 22к строк. if else if else if else if... 22к. тысячи констант, тысячи обращений [1] [2] ... [333].

В период активного кодинга я высираю по 500 строк в день. В твоем модуле два человекомесяца рьяного быдлокодинга. Четыре человекомесяца активного разбирательства и переписывания. С учетом усталости, человекомесяцев на самом деле - восемь.

без проверки на баги той же функциональности

Я же расписал шаги. Пока первый не завершен, об остальных лучше даже не думать: переломаешь всё к чертям собачьим.

код уже сейчас обрастает феерическим набором костылей «лишь бы не упало».

Бизнес уведомлен о том, что процесс разработки перестал быть управляемым?

цель бизнеса не в чистоте кода, а в его работоспособности

С твоих слов получается, что эта цель очень скоро станет недосягаема.

в конце концов это все деньги. бизнес деньги как водится жопит. специфика.

Бизнес наверняка озабочен не только краткосрочной, но и среднесрочной перспективой тоже. Может быть, проблема в том, что он от вас слишком оторван, витает в розовых мечтах?

за единицу модуля надо брать сразу ~100к строк кода для переписывания, который непонятное где и непонятно кем будет дергаться в неявном виде.

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

Может быть проще оставить этот код как есть, обеспечить лишь среду для его выполнения, а необходимый функционал прикручивать снаружи?

Без рефакторинга не обойтись. Конечно, в условиях уже написанного кода такого объёма рефакторить можно бесконечно. Поэтому занимайтесь этим по мере необходимости, когда нужно влезть в тот или иной кусок кода. При этом перед рефакторингом нужно обязательно написать тесты на всё то, что будете затрагивать, и внедрить эти тесты в вашу автоматическую запускалку тестов.

необходимый функционал прикручивать снаружи?

снаружи уже есть целый компилятор из своего языка в байткод под самописную же VM :)

и дальше --- больше.

это как раз про меня. только у меня уже второй идёт. хотя я в последнее время как-то подзабросил это дело… в общем мысль плюсую.

подозреваю ты не представляешь необходимый объём работ. я бы за такое не брался.

Если есть острая необходимость в реинжиниринге и куча денег — отдать код на растерзание компетентной конторе через тендер и т.п. формальности.

отдать код на растерзание компетентной конторе

открыть рядом ИП и попилить... я думал об этом ;)

Написать тесты и отрефакторить.

Оставить как есть. Даже если перепишешь, то что ты за это получишь? Миллион зеленых? По-моему есть в жизни более интересные вещи. А еще представь себе, что кто-то похожий на тебя захочет переписать код после того, как ты все перепишешь. Вот радость будет.

для начала прочитатъ Working effectively with legacy code.

дада, вот у меня есть часть кода: if 27005 then return 388;

Не знаю, как это в дельфи, но на плюсах можно попробовать заменить это на:

typedef std::map<unsigned, unsigned> OhGod;
typedef OhGod::const_iterator OhGodIc;
OhGod m_shit;

// тут заполняем мапку вашей магией
// можно из внешнего файла, для удобства

OhGodIc it = m_shit.find(27005);
if(it != m_shit.end())
{
   return (*it).second;
}

return 0; // нет такого в мапке

Лучше всего рефакторить вместе с разработкой. Т.е при добавлении новой функциональности или исправлении ошибок рефакторишь ту часть кода над которой работаешь.

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

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

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

как переписывать - это другой вопрос

как переписывать - это другой вопрос

так это самый интересный вопрос :)

«шевелим тут, падает там» --- типичная ситуация.

Manhunt описал вполне себе работающий алгоритм. выбивай под него ресурсы и вперед

Manhunt описал вполне себе работающий алгоритм

Да?

Manhunt> Снабжаем систему как можно большим количеством автоматизированных тестов. Счет должен идти на десятки тысяч тестов, с более-менее равномерным покрытием всей существенной функциональности

Это уже работа на несколько месяцев целому коллективу, так что алгоритм работоспособен чисто теоретически.

Первым пунктом _практического_ алгоритма должно быть «разъяснить начальству необходимость рефакторинга». Если этот пункт выполнить невозможно, вся задача неразрешима.

Напиши заново на высокоуровневом ЯП.