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

;)

учитывая зашкаливающее количество говнокодеров на рынке...

... любой проект, проживший лет 5, находится приблизительно в таком же состоянии.

Как делать? А никак. Лепить новые костыли поверх старых. Год-полтора протянешь, потом получишь вполне ожидаемый пинок под зад.

В такие проекты есть смысл идти только после крупных факапов.

Бнпе

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

тряпка

Тряпка как раз остаётся в такой конуре

А сколько строк кода-то и сколько времени собираетесь заниматься поддержкой?

Рефакторинг надо делать потихоньку, постепенно. Руководство об этом информировать только при необходимости.

Люто утраиваю этого товарища. Иначе - никак.

Тряпка как раз остаётся в такой конуре

Случаи в этой жизни бывают самые различные, я бы не обобщал.

Валить, ИМХО, нужно, когда твой труд, как специалиста, затаптывается.

Главное включать его в сроки при оценке.

У меня был опыт, немного из другой оперы. Пообещал выдать на-гора продукт и завяз, там были свои нюансы. И стали меня дёргать: «ну когда?» Нервов сожрали массу. Начальство ж иногда думает, что всё делается со скоростью мысли.

У нас основному поддерживаемому продукту уже больше 15 лет. Всё как описано. Дикая помесь DOS-программ, BAT-ников, Delphi 3 и .NET. База данных разрослась и не всегда понятно где и в каком месте, что-нибудь сломается. Сейчас это всё пытаются переместить в Azure. Класика жанра в общем.

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

Одному будет в разы сложнее всё это делать. Не проще ли найти новое более интересное место для приложения своих усилий?

Интересный вопрос. Чем дольше существует наша отрасль, тем актуальнее будет становиться этот вопрос.

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

Причём, процесс документирования должен быть многоуровневый, нужно иметь и руководство пользователя, и руководство администратора, и руководство разработчика. Не имея знания об объекте, ты, конечно же, не можешь толком рефакторить. И даже тесты создать без знаний о системе невозможно, т.к. понятие «правильного поведения» должно быть определено.

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

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

Вероятно, понадобится глоссарий, словарь синонимов, граф связей «см. также».

В целом это будет скорее «база знаний о системе», чем документация.

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

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

От копипаста может помочь такая методика: разработай систему тегов и пометь ими скопипастенные куски. Чтобы глядя на любой кусок кода, ты мог знать, что у этого куска имеются близнецы, и чтобы ты мог контекстным поиском их найти. Например, это может быть комментарий в начале каждой строчки дублирующегося куска, типа такого: «/*копипаст 345435*/». Тогда поддержка кода с копипастами становится легче.

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

Вопрос - как делать это с наименьшей попа-болью?

записать в отчёт, что всё ок

пойти на повышение

скинуть это на кого-то, хотя постойте...

юнит-тесты на всё.
ну и помаленьку рефакторить. или параллельно писать новую версию, с нуля.

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

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

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

А чем это все индексируется?

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

Физерс «Эффективная работа с унаследованным кодом» - есть библия послебыдлокодеров. Наверное уже советовали. Если коротко: пиши на все тесты, как интеграционные так и юнит, когда вносишь новую функциональность рефакторингом смежных модулей занимайся.

"ты не думаешь, а просто тупо повторяешь за этими дядьками"

они же абсолютно правы :)

Самое удивительное, что в 95% случаев начальство право, а ты ничего не понимающий школьник.

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

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

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

Интересный вопрос. Чем дольше существует наша отрасль, тем актуальнее будет становиться этот вопрос.

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

Причём, процесс документирования должен быть многоуровневый, нужно иметь и руководство пользователя, и руководство администратора, и руководство разработчика. Не имея знания об объекте, ты, конечно же, не можешь толком рефакторить. И даже тесты создать без знаний о системе невозможно, т.к. понятие «правильного поведения» должно быть определено.

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

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

Вероятно, понадобится глоссарий, словарь синонимов, граф связей «см. также».

В целом это будет скорее «база знаний о системе», чем документация.

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

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

От копипаста может помочь такая методика: разработай систему тегов и пометь ими скопипастенные куски. Чтобы глядя на любой кусок кода, ты мог знать, что у этого куска имеются близнецы, и чтобы ты мог контекстным поиском их найти. Например, это может быть комментарий в начале каждой строчки дублирующегося куска, типа такого: «/*копипаст 345435*/». Тогда поддержка кода с копипастами становится легче.

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

комментарий уровня ПРО. Спасибо.

Даже в говне лора можно отыскать что-то полезное.

Интересный вопрос. Чем дольше существует наша отрасль, тем актуальнее будет становиться этот вопрос.

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

Причём, процесс документирования должен быть многоуровневый, нужно иметь и руководство пользователя, и руководство администратора, и руководство разработчика. Не имея знания об объекте, ты, конечно же, не можешь толком рефакторить. И даже тесты создать без знаний о системе невозможно, т.к. понятие «правильного поведения» должно быть определено.

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

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

Вероятно, понадобится глоссарий, словарь синонимов, граф связей «см. также».

В целом это будет скорее «база знаний о системе», чем документация.

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

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

От копипаста может помочь такая методика: разработай систему тегов и пометь ими скопипастенные куски. Чтобы глядя на любой кусок кода, ты мог знать, что у этого куска имеются близнецы, и чтобы ты мог контекстным поиском их найти. Например, это может быть комментарий в начале каждой строчки дублирующегося куска, типа такого: «/*копипаст 345435*/». Тогда поддержка кода с копипастами становится легче.

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

комментарий уровня ПРО. Спасибо.

Даже в говне лора можно отыскать что-то полезное.

+1

А сколько там строк кода? Код хоть на модули разбивали или совсем безумцы его писали?