Запуск цілісної архітектури у застарілому додатку

Я несу відповідальність за великий веб-сайт на базі Asp.Net. Зараз це веб-сайт (не веб-додаток), деякі сервіси Windows та ряд бібліотек класів.

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

Існує кілька реалізацій типу менеджера, але у багатьох випадках додаток демонструє антидіаграму Smart UI (тобто занадто багато ділової логіки в коді поза класами)

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

Моє питання - з чого почати? У нас є 10 років коду (деякі з них все-таки просто перенесли речі ASP Classic), багато різних підходів та стилів.

Рефакторинг всієї бази коду не є реалістичним і, мабуть, не бажаний

Я знаю, що це не нова ситуація, чи є корисні ідеї чи концепції щодо того, як підійти до цієї проблеми?

Я також працював у подібних ситуаціях і можу дати вам наступну пораду.

1. Вам потрібно зменшити технічну заборгованість . Тепер. Чому? Тому що технічний борг - це як фінансовий борг. Ви сплатите відсотки за це.
2. Оскільки рефакторинг всієї бази коду неможливий, запитайте себе: що це заважає? Це просто занадто багато роботи? Чому?
3. Створіть план скорочення технічної заборгованості в часі. Наприклад, встановивши правила як " кожен біт коду, який торкається команда, повинен бути виправлений / перероблений на новий стандарт ". Як правило: одиничні тести повинні бути написані, код потрібно переміщувати у правильних шарах і т. Д. Це дозволяє виправити безліч кодів, не вдаючись до смішно дорогих і малоцінних проектів "рефакторингу".
4. Загорніть лайно. Розв'язка - це ключове значення для рефакторингу та гарної архітектури. Якщо ви можете якимось чином розділити базу коду, ви, можливо, перефактуруєте менші біти.
5. Не збільшуйте заборгованість за технологію далі. Не збільшуйте заборгованість за технологію далі. Не збільшуйте заборгованість за технологію далі. Не...

Ви праві, що рефакторинг всієї бази коду небажаний. Рефакторинг - це те, що ви робите перед новим розвитком, щоб зробити його більш гладким. Якщо ви не плануєте змінювати весь код у своїй кодовій базі, рефакторинг буде доводити неефективне використання часу.

Деякі поради на додаток до того, що говорить Склівз:

1. Розділіть код на часто і нечасто змінювані розділи. Тільки часто модифіковані розділи потребують повного введення в нову архітектуру. Інтегруйте нечасто модифікований код з новою архітектурою, використовуючи якомога менше змін (або ніяких змін, якщо ви можете піти з нею). Втримайтеся від спокуси повного переписування, це обійдеться дорожче, ніж ви отримаєте від цього. Слід оцінити, що існуючий код працює, навіть якщо він некрасивий.

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

3. Спробуйте знайти якомога більше довідкових архітектур і не бійтеся їх копіювати. Не винаходити колесо. Якщо хтось інший має архітектуру, яка добре працює для таких сайтів, як ваш, дізнайтеся на них.

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

НАЙБІЛЬШЕ найважливіше, що я бачив, намагаючись мати справу зі старою кодовою базою, це НЕ продовжувати змінювати те, що ви знімаєте. Тобто, з’ясуйте потрібну вам архітектуру, тоді ВИПУСКУЙТЕ З цим планом! Однією з найбільших проблем, з якою в мене була остання позиція, було те, що база даних коду мала кілька різних уявлень про те, як вона має виглядати з часом. Кожен раз, коли спробували нову ідею, частина коду перетворювалася, а інша - і тоді хтось мав «кращу» ідею. З часом він ставав дедалі непослідовнішим і врешті-решт був збитий.

Є справді приємна безкоштовна книга / pdf про реінжиніринг застарілого програмного забезпечення: http://scg.unibe.ch/download/oorp/

У заголовку написано ОО, але більшість ідей стосується будь-якого програмного забезпечення. Тут обговорюється, з чого почати, як боротися з різними частинами системи під час реструктуризації та багато іншого з цих тем.

Якщо у нього немає цілісної архітектури, це тому, що керівництво не розуміє / не піклується про проблему. Просто код далеко. Ви повинні ввести нову гарну архітектуру під час написання нового коду.

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

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

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