Запуск согласованной архитектуры в унаследованном приложении

Я несу ответственность за большой сайт на базе Asp.Net. В настоящее время это веб-сайт (не веб-приложение), некоторые службы Windows и ряд библиотек классов.

Уровень данных использует смесь LLBLGEN и Linq To LLBGen, а также ряд экземпляров устаревшего встроенного SQL, которые не подвергались рефакторингу.

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

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

У меня вопрос с чего начать? У нас есть 10-летний код (некоторые из них все еще действительно перенесены в ASP Classic), много разных подходов и стилей.

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

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

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

1. Вам нужно уменьшить технический долг . Теперь. Зачем? Потому что технический долг похож на финансовый долг. Вы будете платить проценты за это.
2. Поскольку рефакторинг всей кодовой базы невозможен, спросите себя: что мешает этому? Это просто слишком много работы? Зачем?
3. Создать план по сокращению технического долга во времени. Например, устанавливая правила как « каждый бит кода, который затрагивается командой, должен быть исправлен / изменен в соответствии с новым стандартом ». Как правило: модульные тесты должны быть написаны, код должен быть перемещен в правильные слои и т. Д. Это позволяет исправлять большую часть кода, не прибегая к смехотворно дорогостоящим проектам «рефакторинга» с низкой стоимостью.
4. Заверните это дерьмо. Разделение является ключом к рефакторингу и хорошей архитектуре. Если вы можете каким-то образом разделить кодовую базу, вы можете изменить рефакторинг на меньшие биты.
5. Не увеличивайте технический долг дальше. Не увеличивайте технический долг дальше. Не увеличивайте технический долг дальше. Не делайте...

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

Несколько советов в дополнение к тому, что говорит Sklivvz:

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

2. Узнайте, какова ваша цель рефакторинга. Хотите облегчить размещение контента на сайте? У вас много ошибок и вы хотите улучшить воспринимаемое пользователем качество? Вместо этого вы хотите сократить время разработки функции? Или вы в основном хотите лучший UX? Ваша архитектура должна облегчить рефакторинг кода для достижения поставленных целей. Никогда не забывайте, что основным бенефициаром вашего рефакторинга должен быть ваш пользователь / клиент / бизнес. Чистый код - это не самоцель, а метод для достижения цели, а цель - это пользователь.

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

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

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

Существует действительно хорошая бесплатная книга / pdf по реинжинирингу устаревшего программного обеспечения: http://scg.unibe.ch/download/oorp/

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

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

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

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

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