LINUX.ORG.RU

Разбиение на пакеты по назначению.


0

1

maxcom, hizel

Раз уж есть форум по разработке движка сайта, то не грех им воспользоваться :). Тем более, что чтобы не было «лебедь рак и щука», процесс обсуждения должен занимать минимум 60% времени, затраченного на девелопмент в команде.

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

Существующие пакеты в ru.org.linux:

auth - всё, что относится к аутентификации пользователя: регистрация, логин, сброс/воостановление пароля, ввод каптчи. Нахождение здесь IPBlockDao и IPBlockInfo IMO спорно, потому что это уже расширенная информация о пользователе, доступная модераторам.

boxlet - основные классы для бокслетов - блоков инормации на главной.

comment - классы, предназначенные для обслуживания комментов.

gallery - отдельные классы, предназначенные для работы с галереей. опять же - IMO спорно, потому что это всего лишь как бы расширение возможностей пакета topic. Может, лучше topic.gallery?

group - классы для обслуживания групп секций.

poll - обслуживание голосований. topic.poll?

search - обслуживание поисковых запросов.

section - секции движка. Очень много захардкоденного, сам объект Section как бы размазан частично в захардкоденном виде и частично в базе данных в виде таблицы. Наверное, потом обсудим, как разрулить это (моё мнение: объекты Section должны полностью находиться в БД и должны содержать все необходимые признаки. Например, дополнительное поле is_gallery и т.д.).

storage - пакет-помощник для галереи и для аватарок пользователей. util.storage?

topic - обслуживание тем сообщений.

user - профиль пользователя, игнор-лист, избранные темы, уведомления, темы и комментарии пользователя. user.LostPasswordController => auth.LostPasswordController?

util - вспомогательный код.

пакеты site и spring в результате рефакторинга должны исчезнуть.

Далее предлагаемые изменения. Создать пакеты:

config - в него перенести site.config/* и site.Config

util.cache - перенести сюда site.MemCachedSettings и spring.commons.*

Перенести классы в существующие пакеты:

spring.boxlets - два варианта: или перенести всё в boxlet, или раскидать по пакетам, к которым относятся бокслеты.

site.tags.BoxListTag -> boxlet.BoxListTag; site.DateFormats => util.DateFormats; site.DefaultProfile => user.DefaultProfile

также предлагаю добавить пакет ru.org.linux.admin, в котором будет содержаться код, отвечающий за обслуживание административных (модераторских) функций. То есть, полностью изолировать общий код и код, отвечающий за действия с повышенными привилегиями, Например:

admin.ipmanage - получение информации об IP-адресе пользователя, бан по IP. Сюда же перенести auth.IPBlockDao и auth.IPBlockInfo

admin.user - например, код, ответственный за удаление аватарки пользователя ScoreUpdater и т.д.

★★★★★

Пользуясь случаем, а её хочется пожелать, чтобы изменили код регистрации новых пользователей. Яркий пример сегодняшнего ,тому visual и Visual_N. Так выпьем же ... ну ... за расстояние Левинштайна, или кого-то похожего.

visual ★★★ ()
Ответ на: комментарий от visual

Дык, от тебя до Visual_N расстояние Левенштейна — 2, а если считать регистр, то аж 3. До virtual тоже 2, а он раньше тебя зарегистрирован. И до vista столько же, а он еще раньше зарегистрирован. Нужны более точные правила.

Кстати, у нас могут быть пользователи с одними и теми же буквами в никах, но в разном регистре?

proud_anon ★★★★★ ()
Ответ на: комментарий от proud_anon

а он раньше тебя зарегистрирован.

Зато у меня скор больше. =)

А вообще это мой фэйл. Так зарегать неудачно.

visual ★★★ ()

в целом да, как-то так и будем делать, по section согласен, что-то там странно все сделано

hizel ★★★★★ ()

все равно меняем маленькими кусочками, я ориентируюсь на Issue, pool request-ы и сами патчи можно комментировать. глобальные планы maxcom что-то не одобряе :]

hizel ★★★★★ ()
Ответ на: комментарий от hizel

все равно меняем маленькими кусочками, я ориентируюсь на Issue, pool request-ы и сами патчи можно комментировать.

Но обозначить хотя б общее направление

Глобальные планы maxcom что-то не одобряе :]

это да. Большие коммиты тоже не любит, но иногда маленьким коммитом не обойтись. А моё правило: каждый коммит должен обеспечить сборку проекта без ошибок; и иногда невозможно провести маленькое изменение, не нарушив это правило. Обычно при рефакторинге одно цепляет другое и получаются огромные коммиты.

Slavaz ★★★★★ ()
Ответ на: комментарий от Slavaz

Обычно при рефакторинге одно цепляет другое и получаются огромные коммиты.

это да. надо как-то сдерживать себя.

hizel ★★★★★ ()
Ответ на: комментарий от hizel

это да. надо как-то сдерживать себя.

:) Если я просто переношу класс из одного пакета в другой то автоматом цепляется куча других классов в других пакетах. И сдерживай себя, не сдерживай, а всё равно коммит будет большим. А ещё хочется, чтобы коммит был неким логически законченным действием. То есть, например, формирование нового пакета: тут уже будут затронуты при переносе несколько классов, коммит вообще будет огромным.

На этапе рефакторинга огромные коммиты - это норма.

Slavaz ★★★★★ ()
Ответ на: комментарий от Slavaz

ну пройдем этот этап и будет проще

с другой стороны такой мышковозный рефракторинг мог бы сделать и maxcom, а так получается двойная работы ты натыкал, а потом Макс по diff-у пытается вкурить, что к чему

hizel ★★★★★ ()
Ответ на: комментарий от Slavaz

да и вообще не обязательно делать логически законченным, если боимся забыть то создаем Issue и в каждом poll request-е делаем ссылку на Issue

типа как тут: https://github.com/maxcom/lorsource/issues/82

hizel ★★★★★ ()
Ответ на: комментарий от hizel

с другой стороны такой мышковозный рефракторинг мог бы сделать и maxcom

Как бы да. Я просто выступил катализатором процесса :).

Поэтому и создал эту тему, чтобы поговорить друг с другом не через коммиты с огроменными диффами, а нормально по-русски.

В site и в spring остаётся ещё несколько классов, их нужно тоже классифицировать и раскидать по пакетам. их надо сейчас обсудить.

Slavaz ★★★★★ ()
Ответ на: комментарий от hizel

да и вообще не обязательно делать логически законченным, если боимся забыть то создаем Issue и в каждом poll request-е делаем ссылку на Issue

ок, понято. Так, наверное, будет тоже неплохо.

Slavaz ★★★★★ ()

maxcom, скажи своё мнение по поводу субпакетов:

  • topic.archive
  • topic.gallery
  • topic.news
  • topic.poll
  • topic.tagcloud
Slavaz ★★★★★ ()
Ответ на: комментарий от Slavaz

Получается довольно странная классификация, вот почему:

  • archive - Archive* это только оглавление архива, сам по себе архив показывается в NewsViewerController и GroupController
  • gallery - это вспомогательные классы для работы с картинками. То что сейчас в БД картинки лежат в таблице topics это одна из исторически сложившихся проблем, которую я хочу как-нибудь решить. Сами по себе топики галереи показываются все тем же NewsViewerController'ом
  • news - NewsViewerController это довольно универсальная вещь, она показывает и новости, и галлерею, и топики пользователей и форум.
maxcom ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.