Владимир

Если по теории, то мне в свое время вот эта книга помогла:
https://www.litres.ru/robert-s-martin/chistaya-arh...

Притом после 1 прочтения я нифига не понял, но стал пытаться внедрять практики из книги в повседневную разработку. Выписывал в блокнот все свои затупы.
В этот момент передо мной как раз стояла задача, привести кусок лапши в хоть как-то поддерживаемое состояние. Именно он и сподвиг меня почитать эту книгу.

Через несколько месяцев прочел еще раз, анализируя все затупы, что записал за это время в блокнот. После прочтения начал потихоньку рефакторить в существующих проектах места, которые уж очень жить мешали.

Еще через пол года прочел третий раз, опять же с оглядкой на личный опыт. И тут я кажется уже совсем въехал. По крайней мере многие проблемы с организацией взаимодействия между компонентами стали разрешаться. И вообще появилось достаточно четкое понимание, как структурировать приложение и где разбивать его на компоненты.
Ну и после 3 прочтения еще помог момент: мне дали с нуля проектировать новое, достаточно крупное приложение на Rust. Притом заказчик кричал "микросервисы - это круто, хочу, хочу, хочу", а тимлид мне сказал "давай монолит, но так чтоб потом легко было распилить, а то все сроки про**ем". Вот тут прямо вообще понимание пришло. Ну и плюс в Rust архитектурные компоненты очень хорошо ложатся на отдельные крейты (это такая единица компиляции в Rust), а компилятор в принципе не дает делать циклические зависимости между крейтами.

Ну и недавно решил освежить память и перечитать еще раз. И на этот раз уже были мысли вроде "так если делать по другому, потом проблемы вылезут тут и тут".

ORM его использует. А использовать его самому в Django проекте - это глупость, аннулирующая всю пользу от применения Django.

class ProductImagesSerializers(serializers.ModelSerializer):
    class Meta:
        model = ProductImage
        fields = '__all__'  


class ProductListSerializer(serializers.ModelSerializer):
    images = ProductImagesSerializers(many = True, read_only = True)
    class Meta:
        model = Product
        fields = ['id', 'name', 'slug', 'price', 'category', 'images']
        read_only_fields = fields

Создаете модель корзины, связываете ее с моделью пользователя. Потом создаете модель товары корзины и связываете ее с моделью корзины. Важно указать в ForeignKey полях аргумент related_name, чтобы можно было обращаться из родительской модели к дочерней.

class Basket(models.Model):
    user = models.ForeignKey(User, on_delete=models.CASCADE, related_name='basket')

class BasketProducts(models.Model):
    basket= models.ForeignKey(Basket, on_delete=models.CASCADE, related_name='basket_products')
    products = models.ManyToManyField(Products, on_delete=models.CASCADE, related_name="basket_products")

class Products(models.Model):
    name = models.CharField(max_length=255)
   '''''

Потом сериализируете модели

class ProductsSerializer(serializers.ModelSerializer):
    class Meta:
        model = Products
        fields = ("__all__")


class BsketProductsSerializer(serializers.HyperlinkedModelSerializer):
    products = ProductsSerializer(many=True)
    class Meta:
        model = BasketProducts
        fields = ('basket','products')

class BasketSerializer(serializers.HyperlinkedModelSerializer):
    basket_products = BsketProductsSerializer(many=True)
    class Meta:
        model = Basket
        fields = ('user' , 'basket_products ')

class UserSerializer(serializers.HyperlinkedModelSerializer):
    basket = BasketSerializer(many=True)
    class Meta:
        model = User
        fields = ('id', 'phone','email' ,'basket')

Далее во вьюхе в вашей функции API указываете permission_class как isAuthenticated, потом получаете корзину пользователя командой request.user.basket . В запросе в хедере указываете Authorization и токен.

Попытаюсь ответить вам по пунктам, так как сам в своё время задавался теми же вопросами.

1. Если говорить об удобстве - читаемость хромает, но на прямую в разрез с методологией это не идёт. Если существует "оБЭМленый" Bootstrap и он ничем не уступает - используйте. Это по-настоящему продуманная и современная библиотека компонентов, соответствующая стандартам доступности. Отдельных соглашений на такие случаи не знаю.

Для себя решил отказаться от Bootstrap, чтобы глаз нервно не дёргался, при взгляде на "винегрет" из разных именований. Компенсирую это разработкой библиотеки собственных компонентов, руководствуясь тем же Bootstrap и лучшими практиками.

2. Касательно использования em: рекомендую ознакомиться с этой статьёй
Пришло время попрощаться с единицей измерения px
Для блоков отдельно назначать font-size в px не нужно. Попробуйте правильно использовать rem, взяв за константу, что он должен быть по умолчанию 16px. Если нужно будет - отвечу подробнее.

Лично я использую em в медиа-выражениях и в случае крайней необходимости в блоках.

3. В случае чистого БЭМ - создайте блок с одним шрифтом и другим и используйте его как микс.

4. Если честно, стараться использовать готовые решения CMS можно, но я бы не рекомендовал. Когда работал с WP, всё время кастомизировал классы и вывод шаблона. На Битрикс с этим проще, можно даже собственный класс назначить для WISYWIG редактора.
Вопрос в том можете ли вы себе позволить такую кастомизацию или нет. Если это требует сверх ресурсов - оно того не стоит.

5. Я использую альтернативное именование, которое прижилось лучше всего в англоговорящих странах .block__element--modifier. На мой взгляд оно читаемее.

Вообще для расширения "БЭМ кругозора" рекомендую ознакомиться с этими статьями
More Transparent UI Code with Namespaces
Battling BEM CSS: 10 Common Problems And How To Av...

Я в своей работе на данный момент использую расширенный БЭМ, так называемый BEMIT (BEM + ITCSS). Для обычных сайтов - этого хватает с головой, в случае современного реактивного фронтенда требует обсуждения с командой и более глубоко понимания в проектировании АНБ (абсолютно независимый блок).

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

На коленке состряпал, вроде работает:

import requests

url = "https://login.dnevnik.ru/login/esia/karelia"
#url на свой регион заменишь, там когда на сайте авторизуешься он отображается

login = 'логин'
password = 'пароль'
session = requests.Session()
get_cookies = session.get(url)
captcha_id = get_cookies.cookies['dnevnik_sst'].split('|')[0]
print(captcha_id)

data = {
	'exceededAttempts': False,
	'login': login,
	'password': password,
	'Captcha.Id': captcha_id
}

response = session.post(url, data)

Для всех операций используешь объект session, в нём будут сохранятся куки, и потом можно обращаться к страницам, как будто ты авторизованный, например так:

my_class_html = session.get('https://schools.dnevnik.ru/class.aspx')

schedule_html = session.get('https://schools.dnevnik.ru/homework.aspx')

Вы можете сравнивать даты целиком на больше и меньше не приводя к строке:

current_date >= start_date and current_date <= end_date

А еще можно воспользоваться спорным фирменным питоновским синтаксисом:
start_date <= current_date <= end_date
Если все эти переменные типа datetime, то всё будет как надо.

Ну тут скорее не вопрос, а крик души, который можно поддержать.

По делу: да, проблема есть, именовать на больших проектах сложно. Решений нет.
Вернее, только те, которые вам кажутся "грязными", но других не завезли (и не завезут).
И те, которые не относятся к разработке (вроде "дать люлей дизайнеру, который не понимает, как это всё работает, и лепит каждый элемент как попало")

Тут просто надо несколько абстрагироваться и принять то, что абсолютно в любой объёмной системе, даже если её вдруг пишет один человек (что вряд ли), всегда есть место неочевидным вещам. Перфекционист внутри рыдает, но что делать.

Откройте любое масштабное решение - чёрт ногу сломит, не так ли? И требуется немало времени, чтобы вникнуть. Потом вникаешь - и становится проще, но всё равно много нагромождено. А если выпасть из контекста на месяц - потом опять заново вникать. Это норма (картинка с Малышевой).

Стоит просто выбрать для себя какой-то стиль и строго ему следовать. И расширять словарный запас, чтобы играть словами.

Совмещение ваших пунктов 1 и 3 в одно - вполне здоровый стиль.
Если секция, где всё очевидно: about, gallery, text-section, etc.
Если контент неоднородный - именовать по смыслу (как в 3).

Единственное что мог бы посоветовать - не смущаться добавлять новые компоненты, задавая им какой-то дополнительный неймспейс (contacts-header, contacts-about), а не пытаться всё упихать в один общий с помощью модификаторов - в поддержке будет проще.

Просто размышления от прочитанного:
1. Подходы 2 ("section-1", "section-2") и 4 (атомарщина) - в аду для таких "специалистов" стоит отдельный котёл. Ну вы и сами понимаете. Использовать нужно никогда.
2. Инкапсуляция имён ничего не даёт в этом отношении, так как это придумано для элементов внутри блока (а с этим и концепция БЭМ хорошо справляется), глобально вам как разработчику всё равно нужно иметь понятное "корневое" название блока.

Ещё можно поработать со своей головой, возможно, что такой крик души идёт от страха быть осуждённым. Браузеру-то всё равно, вы ему хоть .qwerty123 { ... } скормите - нормально отобразится.
Понятные имена - для разработчиков, и надо понимать, что ни один толковый разработчик в вас камнем не бросит за то, что вы дали блоку имя .contacts-footer-call-to-action, если у вас этот самый .call-to-action в каждой секции настолько разный, что в один компонент не умещается.
Иногда помогает, если есть прямой выход на клиента или ЛПР донести, что такой дизайн... Ну не самый лучший для поддержки, и обосновать почему.
А чисто технически - решений нет, ну, вот такая работа, чё делать.

{{ a.text | safe }}