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

Меня попросили оценить то, что кажется существенной унаследованной кодовой базой, в качестве предвестника заключения контракта, поддерживающего эту кодовую базу.

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

Структура сайта, как видно изнутри, это бардак. Есть папки с суффиксами "_OLD" и "_DELETE", лежащие повсюду. Многие из папок, кажется, не имеют смысла или имеют очень загадочные имена. Там может быть любое количество старых, неиспользуемых сценариев, лежащих даже в законных папках. Не только это, но, несомненно, есть много несуществующих разделов кода даже в сценариях, которые иначе работают (гораздо менее насущная проблема).

Это передача от действующих сопровождающих обратно первоначальным разработчикам / сопровождающим сайта. Как понятно по типичным сценариям такого рода, действующий президент не хочет иметь ничего общего с передачей, кроме того, что по контракту и по закону требуется от него, чтобы отодвинуть его вновь избранному сопровождающему. Таким образом, извлечение информации о существующей структуре сайта из действующего просто невозможно.

Единственный подход, который приходит на ум, чтобы войти в кодовую базу, - это начинать с корня сайта и медленно, но верно перемещаться по связанным сценариям ... и, вероятно, используются сотни, а сотни - нет. Учитывая, что значительная часть сайта находится во Flash, это еще не так просто, поскольку, особенно в старых приложениях Flash, ссылки на другие сценарии могут быть встроены в двоичные файлы (.FLA), а не в текстовые файлы (.AS / ActionScript).

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

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

• Используйте инструмент паука, чтобы понять, какие страницы есть, а какие входящие. В этом отношении будет полезен даже базовый инструмент проверки ссылок, а не специальный инструмент «паук для целей аудита».
• Составьте базовую таблицу аудита / инвентаризации. Это может быть просто список файлов и время их последнего изменения, упорядоченное по каталогу. Это поможет вам понять сферу действия, и когда вы попадете в каталоги, такие как _OLD и _DELETE, вы можете сделать заметку, что: а) ваша оценка основана на материалах, которых нет в этих каталогах; б) наличии этих каталогов и возможности Крутые / скрытые кошмары свидетельствуют о более глубоких проблемах, которые должны быть учтены в предложении вашего клиента , в некотором роде. Вам не нужно тратить десятки лет, перечисляя возможные проблемы в _OLD или _DELETE; информация будет включена в возможную ставку.
• Учитывая, что вы просматриваете то, что звучит как полностью веб-приложение, даже стандартные инструменты анализа журналов станут вашим другом. Вы сможете добавить в электронную таблицу некоторый смысл «это входит в топ-10 доступных скриптов» или что-то подобное. Даже если сценарии встроены в файлы Flash и, следовательно, не являются «паутинными», существует высокая вероятность того, что они доступны через POST или GET и будут отображаться в журналах сервера. Если вы знаете, что у вас есть 10 сценариев с высоким уровнем доступа, а не 100 (или наоборот), это даст вам хорошее представление о том, как будут проходить работы по обслуживанию.

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

Я настоятельно рекомендую рефакторинг существующего исходного кода (в отличие от переписывания) с использованием шаблонов, приведенных в книге « Эффективная работа с устаревшим кодом ».

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

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

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

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

Читать код труднее, чем писать. ". - http://www.joelonsoftware.com/articles/fog0000000069.html

В типичной базе Java-кода я рассмотрю возможность использования таких инструментов, как PMD, FindBugs или Sonar, а затем попытаюсь понять инструменты отчетности (мертвый код, недокументированный код, дублированный код и т. Д.).

На основе отчетов я попытаюсь найти различные уровни приложения / сайта (бизнес-уровень, БД, SQL и т. Д.)

Если слои связаны (html в сервлете, sql в java-коде), то сначала я начну с развязки, каждый из этих шагов должен рассматриваться как изолированный, и вы можете выполнить коммит в конце каждого (запустив ветвь, затем сделайте слияние) ,

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

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

Сканер может помочь вам определить, какие URL доступны. Особенно, если он достаточно умен, чтобы извлечь ссылки из Flash или JavaScript. Получив список веб-страниц, просмотрите их и перечислите файлы, на которые они ссылаются. Все, что осталось после этого процесса, следует считать мертвым кодом.

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

Вы уже частично ответили на свой вопрос в последнем абзаце: посмотрите, к чему обращаются во время работы приложения.

1. Возможно, вы захотите профилировать базу данных и попросить профилировщика записать все запросы за день. Это даст вам обзор наиболее часто используемых объектов базы данных, но не скажет, какие из них никогда не используются. Кроме того, вы все равно должны быть осторожны с результатами: например, таблица может использоваться исключительно через хранимые процедуры, но когда вы посмотрите на запросы из профилировщика, будет выглядеть так, как будто таблица вообще не используется.

2. Просмотр исходного кода, поиск запросов более полезен, и после сбора всех запросов вы можете иметь хорошее представление об использовании базы данных не с точки зрения частоты (здесь удобен профилировщик), а с точки зрения использованного / нет используемые таблицы. К сожалению, для плохо написанного / не поддерживаемого годами кода, он может быть чрезвычайно сложным и подверженным ошибкам , особенно если запросы строятся динамически (представьте метод, который в a selectиспользует параметр в качестве имени таблицы; как вы можете возможно знать, каковы возможные значения параметра, просто посмотрев на исходный код?).

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

4. Анализ самих данных или метаданных базы данных может выявить некоторую интересную информацию. Например, было бы легко утверждать , что таблица LogonAudit(uniqueidentifier LogonAuditId, datetime LogonEvent, ...)не используется больше , если она содержит 10 000 записей в день за годы 2006 по 2009 год, и никаких записей с сентября, 18 - ^го , 2009. То же самое не верно для таблица, содержащая данные с отступом, чтобы быть в основном только для чтения.

Эти четыре пункта вместе дадут вам список используемых таблиц. Остальные либо используются, либо нет. Вы можете делать утверждения и тестировать их, но без хорошего охвата модульных тестов это будет нелегко. Любой «легкий» путь тоже потерпит неудачу. Например, если у вас есть products_delme_not_usedтаблица, вы можете утверждать, что таблица вообще не используется, и проверять наличие «products_delme_not_used» в своем коде. Это оптимистично: нет ничего необычного в том, чтобы найти кандидата DailyWTF, подобного этому, в старой кодовой базе:

// Warning: WTF code below. Read with caution, never reuse it, and don't trust
// the comments.

private IEnumerable<Product> GetProducts()
{
    // Get all the products.
    return this.GetEntities<Product>("PRODUCT");
}

private IEnumerable<T> GetEntities<T>(string tableName)
{
    // Everyone knows that SQL is case sensitive.
    tableName = tableName.ToLower();

    if (tableName == "user" || tableName == "product")
    {
        // Those tables were renamed recently in the database. Don't have time
        // to refactor the code to change the names everywhere.
        // TODO: refactor the code and remove this `if` block.
        tableName += "s";
    }

    if (this.IsDelme(tableName))
    {
        // We have some tables which are marked for deletion but are still
        // used, so we adjust their name.
        tableName = this.Delme(tableName);
    }

    return this.DoSelectQuery<T>("select top 200 * from " + tableName);
}

private bool IsDelme(string name)
{
    // Find if the table is among candidates for removal.
    List<string> names = this.Query<string>("select Names from DelmeTables");
    return names.Contains(name);
}

private string Delme(string name)
{
    // Return the new name for a table renamed for deletion.
    return string.Join("_", new [] { name, "delme", "not", "used" });
}

Можете ли вы понять, что этот код на самом деле использует products_delme_not_usedтаблицу?

На вашем месте я бы:

1. Держите все объекты базы данных на месте,
2. Рефакторинг всего приложения (если оно того стоит),
3. Документирование (при рефакторинге) приложения и, в частности, использования базы данных.

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

Мне кажется, вам нужно получить достаточно информации для составления цитаты, поэтому я сосредоточусь на этих усилиях.

Я бы попытался определить, сколько вариантов использования задействовано на этом сайте. Обычно это дает вам представление о том, насколько велик и сложен сайт, и сколько времени потребуется для повторного создания или обслуживания сайта / приложения.

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

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

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

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