Распутывая программный беспорядок, время для Big Rewrite?

Ответ 1

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

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

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

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

Ответ 2

Лучшая статья, которую я видел по этой теме, взята из Joel, и она здесь.

Если вы помните браузер netscape, это был один из самых популярных браузеров еще в конце 1990-х годов, но, как Джоэл указывает на падение netscape:

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

Они решили переписать код из царапина.

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

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

Таким образом, повторите фактор, улучшите, консолидируйте, обновите до новых технологий, таких как ASP.NET, устраните мертвый код и т.д., но обязательно помните, чтобы учиться на уроках разработчиков netscape, а именно не выполнять выбросить существующий код.

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

Удачи!

Ответ 3

Канальная лента работает, и нелегко перестроить 7-этажное здание. IMO, я бы продолжал хлопать по ленте, планируя новую систему на стороне, если босс готов заплатить вам за огромное количество часов, которые потребуются. Зачастую я нахожу, что менеджмент хочет видеть "прогресс" больше всего на свете, в том смысле, что коротко закодированная, но яркая новая функция будет собирать гораздо больше реквизитов, чем полная перестройка системы, которая в итоге выглядит одинаково. Босс, вероятно, не очень заботится о тележке OO против тележки, отличной от OO. Это нечестно, я знаю, и на идеальном рабочем месте это было бы не так. Только мои 2 цента. Однако не сложно настроить репозиторий git или svn, и это шаг в правильном направлении. RT или Trac могут быть полезны для отслеживания ошибок и запросов функций.

Ответ 4

Я настоятельно рекомендую вам прочитать " Эффективно работать с устаревшим кодом

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

http://ecx.images-amazon.com/images/I/51TG9F1B8AL._SL500_AA300_.jpg http://ecx.images-amazon.com/images/I/51TG9F1B8AL._SL500_AA300_.jpg

Ответ 5

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

Ответ 6

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

Серьезно, у меня был клиент с 25+ приложениями в подобном беспорядке - через два года около 1/2 из них были просмотрены, а пятерка немного почистила.

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

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

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

Если вы приближаетесь к этому с точки зрения сверху вниз, вам нужно начать с очистки элементов пользовательского интерфейса: вырезать все встроенные CSS, очистить и рационализировать его. Инвентаризация страниц, зависимостей и т.д. (Это может занять некоторое время, особенно с классическим ASP). Определите повторяющиеся кодовые блоки и подумайте о переносе их в общие пользовательские элементы управления. Посмотрите, можете ли вы сопоставить компоненты пользовательского интерфейса с элементами базы данных.

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

Создайте набор небольших, чистых CSS файлов и создайте несколько основных страниц, которые вы можете использовать для стандартизации внешнего вида. Вам придется переписать страницы asp, но вы можете обновить страницы веб-форм, чтобы легче использовать новые мастер-страницы.

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

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

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

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

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

Удачи, и не забудьте обновить резюме!

Ответ 7

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

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

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

Ответ 8

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

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

надеюсь, что это поможет

джим

Ответ 9

Решая только эту часть базы данных, вот книга, которая поможет вам: http://www.amazon.com/Refactoring-Databases-Evolutionary-Database-Design/dp/0321293533/ref=sr_1_1?ie=UTF8&s= книги & QID = 1268158669 & ср = 8-1

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

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

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

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

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

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