я бы конечно сделал два приложения

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

где вы будете хранить их шаблоны?

не верю я в реюзабл приложения.....

Как в идеале. То что ты можешь юзать 2 и более раза без изменений надо выносить в пакеты и отдельный гит. и ставть через pip. остальное для вашего проекта будет уникально. Но это в идеале.

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

да

Так что то что вы не можете вынести одельным проектом в гит, но считаете реюзабл. Это самообман) "Авось где-то пригодится еще"

не верю я в реюзабл приложения.....

Можете не верить, оно работает)

У меня сейчас проект, предыдущий разраб вынес шаблоны и статику в /themes/default/ и тут папки static и templates А модельки и админки все в папке /core/models.py и admin.py Ну, а в папках с приложением forms views urls etc

Вот мне из этого только Модели и Админка не понравилось, а все остальное очень даже какжется удобным )

Ну все складывать в папку core или типа того неправильно. Нужна модульность и разбивка на приложения

Если конечно это не блог из пары страниц

Угу, ме этот момент тоже не понравился : )

Неее, там огромная приложуха .

1к строк почти в models.py ...

Это просто ужасно.

Да это печально) Для отого кому надо это поддерживать

Two scops with Django рекомендуют хранить все шаблоны в templates/

1к строк почти в models.py ...

это не много

Two scops with Django рекомендуют хранить все шаблоны в templates/

Понятное дело

на прошлых местах работы были классы по 10к строк (один класс, не список)

да и сейчас есть

Я про это и сказал выше.

на прошлых местах работы были классы по 10к строк (один класс, не список)

И как работалось?

И как работалось?

вполне нормально

в крупных проектах это нормально

сейчас есть модель Car, 9456 строк)

сейчас есть модель Car, 9456 строк)

на 150 полей?

Я бы не говорил, что это нормально Насколько тестами всё покрыто?

сейчас есть модель Car, 9456 строк)

2 вопроса - как и зачем? Управление сложностью не?

Я бы не говорил, что это нормально Насколько тестами всё покрыто?

когда у тебя платежная система и основной моделью является transaction - это нормально

или когда у тебя онлайн аукцион машин - тоже нормально

Большие проекты это отдельный разговор)

2 вопроса - как и зачем? Управление сложностью не?

3 года говнокода)

Большие проекты это отдельный разговор)

так я про большие проекты)

Я бы не говорил, что это нормально Насколько тестами всё покрыто?

мало, во время разработки mvp никто не писал тесты

а сейчас стараемся разбивать на микросервисы

В больших проектах хорошо дробить модели, классы через абстракции уже и т.д. иначе поддерживать сложно

или когда у тебя онлайн аукцион машин - тоже нормально

Чем они отличаются от других крупных проектов, что им позволительно перегружать код моделей?

Чем они отличаются от других крупных проектов, что им позволительно перегружать код моделей?

тем, что почти вся логика завязана на одной сущности

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

этому есть решение

мне нравится идеология, которая реализована в Symfony

там есть модель и сервис

модель - описание самой сущности

сервис - логика сущности

ну, это конечно оптимизирует и разделит какую то часть кода

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

ну, абстракции - это хорошо

но они никак тебе не помогут, если эта логика используется в одном месте

Но не все их делают, я тоже встречался с моделями в 10к+ строчек, где все вперемежку

тем, что почти вся логика завязана на одной сущности

Что-то меня это не убеждает писать лапшу на десяток тысяч строк

Все можно вынести

но они никак тебе не помогут, если эта логика используется в одном месте

Вы путаете тип класса с интерфейсом класса

Что-то меня это не убеждает писать лапшу на десяток тысяч строк

там нету лапши

там много функций

Да

В сущность пихают и нестандартную валидацию и тригеры (вроде отправки уведомлений) и сами действия вроде что-то посчитать и когда это растет это довольно тяжко для поддержки

А какие вьюхи в таких проектах?: )

В сущность пихают и нестандартную валидацию и тригеры (вроде отправки уведомлений) и сами действия вроде что-то посчитать и когда это растет это довольно тяжко для поддержки

это уже говнокод)

валидации у нас отдельно

Вьюхи как раз там не шибко большие, в крайнем случае Mixin и тд. А вот с сущностями беда

А какие вьюхи в таких проектах?: )

их много) какие вас интересуют?)

валидации у нас отдельно

Где?

там много функций

Можно вынести часть функций, относящихся к одной подтеме в миксин, например. Это не запрещено, даже если миксин будет импортиться один раз

Где?

в классах валидации

ERROR: S client not available

их много) какие вас интересуют?)

Да обычные, количество строк например: ) И CBV или FBV?

CBV конечно

Да обычные, количество строк например: ) И CBV или FBV?

ни то ни другое, проекты не на питоне

шаблоны - twig

там много функций

И вынести функции в utils абстрагируясь от типа оперируемых объектов

И вынести функции в utils абстрагируясь от типа оперируемых объектов

я согласен, их можно разделить и это будет правильно

но в целом, они все равно будут большими

из 10к строчек 100 не получится сделать =)

Не всё же сразу

В итоге эти части будут абстрагироваться, их будет легче мейнтейнить и тестировать

из 10к строчек 100 не получится сделать =)

Постепенный рефакторинг - оказыаается что из 10 все 5 дублирубтся

Просто для разных объектов

А на лапшу в 10к строк даже смотреть не хочется, радости от работы с таким очень мало

К Джанго не относится, но руководство не любит рефакторинг как правило. Результатов не видно и все такое. Сначала убеди)

смотря какое руководство

если они его не любят, они не совсем компетентны

смотря какое руководство

Это и + снижение затрат на поддержку и внедрение новых фич

Покрытие тестами легче -> меньше багов

если они его не любят, они не совсем компетентны

Ты описал 99% руководителей

Ты описал 99% руководителей

да, так и есть

но это не значит, что они правы)

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

это может быть unit economic

user experience

acquisition

code refactoring и так далее

если все время писать код и оставлять таким какой он есть, это ведет к материальным ущербам

В особо крупных компаниях да, так и есть в большинстве случаев. Но представь какой-то средний интернет бизнес, кода навалом. Разработчиков несколько, пара тестеров, ну 1 архитектор, он же тим лид и штук 50 всяких там маркетологов и прочий нечисти. Там не до рефакторинга, надо отбиваться от нечисти, которая хочет то се)

И таких большинство

В особо крупных компаниях да, так и есть в большинстве случаев. Но представь какой-то средний интернет бизнес, кода навалом. Разработчиков несколько, пара тестеров, ну 1 архитектор, он же тим лид и штук 50 всяких там маркетологов и прочий нечисти. Там не до рефакторинга, надо отбиваться от нечисти, которая хочет то се)

Так пусть тимлид и отбивается :D

"Вы же специалист "

Ну ему бы за качеством кода следить) А он только отбивается