Как вести поддержку/документацию монстр-проекта?

Добрый день.

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

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

Бывает документация классов, методов и тд, но в этом случае это скорее всего не поможет.
Какие варианты управления, баз знаний или еще чего-то бывают?
Спасибо
  • Вопрос задан
  • 820 просмотров
Пригласить эксперта
Ответы на вопрос 4
php666
@php666
PHP-макака
Переписать всё заново
Ответ написан
@BorisKorobkov
Web developer
У вас два разных вопроса.

кто его использует? В какие моменты? консольный скрипт, может быть апи?

Должна быть правильная структура проекта.
Framework и другие сторонние библиотеки - в папке vendor или node_modules
Ваш движок - в другой папке.
Каждый сайт - в отдельной папке. Если у него есть свой функционал или переопределение базового - наследование от базового.

Тогда ответы на ваши вопросы очень простые:
* какой именно функционал - открыть наследуемый класс. В IDE есть иконка-подсказка.
* кто использует - в IDE есть "Find usages"

а может быть пользователь еще не авторизовался? или его заблокировали?

Для этого должно быть логирование. Если речь про скрипты, то git. Если про изменение в БД, то и триггеры на уровне БД или запрет прямого доступа к БД, а работа только через модель и логирование.
Ответ написан
@Free_ze
Пишу комментарии в комментарии, а не в ответы
Разница должна быть обязательно расширением базовой функциональности (статически - через наследование), либо работать через стандартизированный интерфейс (динамически - API для плагинов).
Костыли с кучей if лучше заменять полиморфизмом, используя IoC via DI и идею паттерна Стратегия.

Детальную девелоперскую документацию вести нет смысла, как показывает практика - ее трудно поодерживать. Можно завести вики или даже документы, в общих чертах описывающих работу тех или иных неочевидных узлов.
С точки зрения логики работы приложения, в сурёзных конторах QA пишут тест-кейсы, которые фиксируют требования. Это бывает полезно, чтобы освежить память. (тест-кейсы не устаревают, ибо каждый релиз прогоняется полный регрессионный цикл)
Ответ написан
@DarkTM
Страдаю фигней
Правильная архитектура, она сама себя документирует, так как отражает происходящие процессы. Ведение документации закладывается изначально в проект. В каждом языке есть свой инструмент для автоматической генерации док. Хотя правильно сразу делать гайдлайн + общая модель всех бизнес процессов, плюс нарезка на микросервисы.
В вашем случае - уже поздно пить боржоми когда печень сдохла. Так как проект вышел из под контроля и ситуации, когда есть хоть кто-то, кто может описать работу вашего сервиса. И вам написали один из двух выходов - переписывать с нуля. Второй выход - форкать, садить человек пять и пусть разбираются в коде и как оно работает, заодно и документируют. Других средств просто нет.
Хотя нет вру, вру. есть. Написать нейронку, распарсить код, сделать AST, скормить нейронке и пусть задокументирует. Стоить это будет думаю больше чем весь ваш проект в принципе.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы