Describe architecture and code problems
| Проблемы | Решение | Выгода |
|---|---|---|
| Неправильная структура файлов и наличие лишних (ненужных) файлов. (помойка) Усложняет поиск нужных модулей кода. | Провести структуризацию | Удобство в поиске (все лежит на своем месте). |
| Наличие "файлов-монстров" типа museums_db_wrapper.py, script_file.js. Усложняет читабельность кода, все валяется в одном месте, затрудняя поиск нужных модулей кода | Разбить большие файлы на логические модули | Улучшит скорость интеграции нового Back-end, поиск по коду. |
| Проблема с кэшем (точнее нынешнее его состояние). Чтобы объект из hypertext-admin попал в hypertext-mobaile необходимо перезагружать hypertext-mobaile, при этом загрузка происходит более 2 мин, а объектов в базе при этом ничтожное количество. | Возможно проблема решится сама собой, если решить проблему ниже. | Увеличится скорость, не придется перегружать постоянно сервер |
| Функции БД выполняются в python. Дублирование функций БД, как минимум не разумно, лишняя нагрузка на сервер, плюс тормоза, лишний код. | Использовать возможности mongoDB. | В разы увеличит скорость, избавимся от лишнего кода. Возможно сразу решит проблему с кэшем. |
| Проблема с редактором описаний в hypertext-admin. Все проблемы с кареткой, подсветкой тегов, вылезают из неправильного использования редактора. А точнее мы используем wysiwyg редактор, но не используем его функции. При этом, дублируем некоторый функционал, который идет в разрез с функционалом реализованным в wysiwyg. Это порождает все проблемы. |
|
|
| Отсутствие комментариев в коде, замедляет разработку, если приходится копаться в чужом коде, либо в своем, написанным давным давно. | Комментировать код, перед функцией (что делает, что принимает на вход, что возвращает), комментировать не очевидные строки кода. | Улучшит скорость интеграции нового Back-end. И читабельность кода. |
| Неправильное использование Объектно-ориентированного языка python. Так как язык ОО, то следует его использовать как ООЯ. | Использовать как ООЯ | Улучшит логику кода, разделения на модули, что позволит легче масштабировать систему. |
Время: предположительно, чтобы решить данные проблемы, потребуется 6-8 полных рабочих дней
Итог:
Произведя рефакторинг проекта получим:
- Удобную структуризацию файлов проекта
- Читабельность кода
- Поиск по коду
- Масштабируем системы без лишних временных затрат
- Увеличение производительности системы
- Увеличение производительности работников
- Уменьшится вероятность появления багов, и уменьшится время их исправления
- Красивый легко поддерживаемый код
Не произведя рефакторинг проекта получим:
- Сложность интеграции новых фич. С каждой новой фичей, все сложнее и сложнее интегрировать.
- Увеличится вероятность возникновения багов, которые отнимут много времени при исправление
- В перспективе, когда закончим проект, и реши произвести такой же рефакторинг, это отнимет чудовищное количество времени
- Разработка проекта будет замедлятся из-за неудобной структуры, помойки в коде, и из-за отсутствие желания копаться в нем (отсутствие желание работать над проектом)
- Потеря производительности системы, при увеличении функциональности