django: как оценить проект для рефакторинга
Имеет любого из Вас сделанная оценка a django проект и как улучшиться/осуществить рефакторинг, это - кодовая база? Любимый проект в компании, в которой я работаю, становится более широко используемым, и было бы хорошо улучшить свое качество перед дальнейшим развитием. Есть ли любые методы или методологии анализа django проекты, прежде чем мы начнем помещать все больше функций в него? Мы не хотели бы внезапно понимать, что из-за более раннего плохого выбора мы должны жить с чем-то действительно плохо.
2 ответа
Проработав более года на довольно большом сайте, я заметил, что в основном это касается нашего дизайна / кодирования. Это не просто рефакторинг, и, вероятно, вы уже много знаете, но, возможно, это может помочь :).
- Что еще более важно, мы не всегда помещали наш код в нужное место. Слишком много функциональных возможностей в методах представления, слишком мало в формах и моделях. Я сталкиваюсь с этой проблемой много раз. Для обработки ввода используйте формы, для форматирования / настройки / ... данных модели используйте методы или свойства модели. Серьезно, в какой-то момент я сократил вид со 150 строк до 20, просто поместив код в более удобные места. Очень хорошо улучшает ремонтопригодность и удобочитаемость
- Многие написанные нами коды на самом деле не использовали в полной мере возможности python и / или django. Для первого очень помогло чтение чего-то вроде Dive Into Python , для второго я просто отследил все сложные конструкции, которые мы построили (в основном устаревший код из 0.96), и посмотрел, есть ли альтернативы в django docs. Конечно, не тратьте зря время, пытаясь свести все к однострочному, но, безусловно, с устаревшим кодом это может помочь улучшить читаемость и ремонтопригодность.
- Всегда смотрите на такие сайты, как django-snippets , код Google , ... если есть достойные существующие проекты django, которые могут лишить вас многих функций.Часто эти проекты просматриваются большим количеством людей, поэтому они более стабильны и эффективны. Если проект не отвечает всем вашим требованиям, может быть хорошей идеей просто добавить свои требования самостоятельно, вместо того, чтобы делать все это индивидуально для вашего сайта.
- Старайтесь, чтобы перекрестные зависимости приложения были минимальными. Когда вы рисуете граф зависимостей (например, связывая каждое приложение, имеющее внешние ключи, друг с другом), он все равно должен быть ясным, а не тем, что каждое приложение связано с каким-либо другим приложением. Обычно у вас есть несколько «вспомогательных» приложений (например, пользовательская система, теги), которые используются многими, и все другие приложения фактически зависят только от этих приложений.
- Пишите тесты, у django отличный набор тестов, так что используйте его. Конечно, для частей кода, которые являются общими для многих приложений и могут измениться. На самом деле, ничто так не раздражает, как внезапное обнаружение ошибки, которую вы действительно решили 4 месяца назад, и вы не знаете, какое обновление с тех пор сломало ее снова.
- Еще раз взгляните на нормализацию базы данных, модель django orm все еще тесно связана с реляционными базами данных, и поэтому это важная концепция, особенно когда вы работаете с моделями, которые, вероятно, будут расширены позже.
Что касается реального рефакторинга, единственный важный инструмент, который я могу придумать, - это South , он может вам очень помочь, если ваша схема базы данных изменится. В противном случае, как подсказка, которую я уже дал: напишите тесты, чтобы убедиться, что ваша функциональность до и после рефакторинга остается неизменной.
Вы можете узнать о запахах кода . Некоторые говорят, что если ваш код пахнет, значит, вам нужно подумать о рефакторинге.
На самом деле это очень обширная тема. Помните, что:
Преждевременная оптимизация - это корень всех зло - Дональд Кнут
Я лично считаю, что это также справедливо для (преждевременного) рефакторинга.
РЕДАКТИРОВАТЬ: это также хороший ресурс о запахах кода: http://www.codinghorror.com/blog/2006/05/code-smells.html