Означает ли такое смерть проекта?

> Вопрос. Когда вы видите истую авгиеву конюшню, из которой надо
> сделать куколку -- что вы делаете?

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

выполнив (1) и (2) приходишь к понимаю системы, одновременно
сделав полезную работу.

После этого и только после этого следует приступать к рефакторингу,
потому что без понимания системы ничего хорошего не сделаешь,
только ерунду типа
ThisMethod -> this_method
и
i = i + 1; -> i++;

ну и конечно можно после 1 и 2 понять, что проще переписать

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

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

То есть. (i) Берешь код и изучаешь принцип работы, (ii) решаешь задачу, (iii) рефакторишь и оптимизируешь потихонечку.

на ум приходит Битрикс :)

Оно в известной степени работает. :) Иначе говоря, задача решена, хоть и на 3 с плюсом.

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

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

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

> Ну и на потихонечку времени нет, до начала осени надо справиться.

Кинь в public domain

>Только как оно должно работать, и являются некоторые странности в поведении фичами или багами -- трудно понять. Никто над этим не задумывался, и тем более, не описывал нигде.

Если это возможно, то фичи, баги лучше подправить у себя (мне трудно понять, о чем идет речь), ну а потом в закомитить в осн. ветку, предварительно обсудив с пиплом. Но этолучше делать уже потом, если вообще кому-то понадобиться.

>Ну и на потихонечку времени нет, до начала осени надо справиться.

Я так рассуждаю. Задачу надо выполнить. Есть два варианта: все писать с нуля либо взять что-то (готовый проект + костыли всякие (временные)) и сделать рабочий вариант, но не полурабочий (на 3 с плюсом), а рабочий. На первый вариант времени точно не хватит до осени. Завязнешь, если проект большой. Программисты всегда страдают гипероптимизмом перед любым проектом. Тебе просто ничего не остается: либо брать и осваивать чужое, либо бросать проект, как нереализуемый до указанных сроков.

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

> Если это возможно, то фичи, баги лучше подправить у себя (мне трудно понять, о чем идет речь)

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

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

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

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

>1)внешние тестирование, одновременно с постижением функциональности пишутся автоматические тесты для него, если это еще не сделано это позволит когда вы что-нибудь "порефакторите" ничего не сломать

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

Я бы, в силу своего скромного опыта, посоветовал бы начать с документации. Начать с описания требований, благо какой никакой проект есть. Потом описываешь, что и как должно работать. После этой подготовительной работы станет ясно, что будет быстрее писань с нуля или править существующее. ЗЫ. Еще лучше втолковать начальнику, что поставленные сроки далеки от реальности.

>i = i + 1; -> i++;

Ну если на то пошло, то...
i=i+1; -> i++ -> ++i
:-)

Ы-ы-ы... Я оттуда свалить сам побыстрее хочу :) Только не хочу сваливать последней свиньей, потому и согласился на эти полтора месяца...

> Только как оно должно работать, и являются некоторые странности в поведении фичами или багами -- трудно понять. Никто над этим не задумывался, и тем более, не описывал нигде.

Ну ответ вроде очевиден - начать с описания требований. Методологию "после чего все это дело документировать" оставить быдлокодерам, пишущим сферический код в вакууме.