Рекомендации правильного проектирования кода чтобы максимально избежать легаси

Легаси - часть кода, со скрытыми слоями, которая делает что то и никто не знает как именно она работает. Фактически наличие легаси в проекте значит утерю понимания и прозрачности кода

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

Легаси можно максимально отодвинуть или предотвратить если следовать рекомендациям

  • минимально используйте наследие в ооп. У вас должна быть очень везкая причина чтобы унаследовать класс. Если каким то образом вы наследуете класс который уже наследуется от другого - это уже путь в никуда. Любые дальнейшие правки базовых классов обязательно аукнуться в других местах в будущем
    Наследование от классов фреймворка не считается, если оно для этого изначально было спроектировано (в фреймворк вы ведь не будете изменения вносить? )
  • избегайте маппинга на ровном месте. Если у вас основные данные находятся в базе - используйте эти названия таблиц и полей для всех остальных переменных и классов с минимальными искажениями. Если допускаете искажение - оно должно быть единым во всём проекте. Множественное число, заглавные буквы. При изменении названий в базе - меняйте и переменные. Никаких исторически сложилось. И сразу
    Названия файлов, папок и URL также должно максимально точно повторять описание полей и таблиц. Это также поможет при отладке
  • добавляйте комментарии там где через переменные или смысл не получается полную картинку описать. Это может быть текст задачи по локальному изменению алгоритма какого то блока или описание общего смысла скрипта. Особенно это важно при наличии множества похожих по смыслу блоков
  • не дублируете логику которая отвечает за что то конкретное. Логика формирования паролей, подключений. Она может измениться и правок этих зависимостей должно быть как можно меньше.  Но без фанатизма. Да, это что-то похожее на S в Solid

 

Нужно отличать вещи которые однажды изменяться и сразу везде и вещи которые однажды изменятся локально

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

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

  • Автор: kosmom
  • Рейтинг: 27
  • Просмотров: 344
  • Комментариев: 0
  • Создан: 12.08.2023 16:08

Комментарии (0)

Ваши предложения и пожелания пишите на pro@kosmom.ru

Теги

backup bootstrap core framework eloquent excel home project html ios javascript keep-alive kpi laravel legacy mvp orm php rip scroll timestamp undefined vue vuetify watch безопасность биометрический паспорт ваша любаша для путешествий загран на 10 лет загран паспорт загранпаспорт нового образца зимние книги как заполнить анкеты кеширование книги на новый год логирование мцф недвижимость новогодние книги образец заполнения антеты паспорт для путешествий паспорт нового поколения печать продукт проектирование прокси разработка ремонт ремонт в апартаментах ремонт нежилого помещения самокат сдача сколько стоил ремонт апартаментов спорт стандарты таблица финансы хостинг цена ремонта что почитать зимой юзабилити

Случайный пост

02.11.2015 17:24
Неделя 28 сентября - 4 октября 2015 года