Чистый (ваш) код в Django
Эта статья написана в целях индивидуального обзора курса разработки программного обеспечения CSUI 2022.
Введение
Уборка, вероятно, не ваше любимое занятие, и уж точно не мое. Будь то уборка вашей комнаты или чистка вашего кода, это, вероятно, не будет хорошим временем. Но у обоих есть кое-что общее. Это очень важно.
Содержание
1. Некоторые принципы «Чистого кода»
Как вы, возможно, уже знаете, чистый код — это не компьютеры или компиляторы, а люди. Для компьютеров то, как вы пишете свой код, не имеет ни малейшего значения, если его синтаксис правильный и логически правильный. Но люди не компьютеры. Ваши коллеги по работе и другие программисты не обязательно смогут прочитать ваш код, особенно если вы написали нечистый код.
Вот некоторые из наиболее известных принципов «Чистого кода»:
- ПОЦЕЛУЙ (будь проще (и) глупее)
- СУХОЙ (не повторяйтесь)
- YAGNI (Вам это не понадобится)
В следующих частях я постараюсь показать примеры этих принципов в Django.
2. ПОЦЕЛУЙ в Джанго
KISS (Keep It Simple (и) Stupid) в основном говорит вам, чтобы ваш код был коротким, простым и легко читаемым другими.
Используйте формы Django, сериализаторы, разрешения и декораторы, а не ручные альтернативы
Изучая Django, вы, вероятно, изучили формы Django, сериализаторы и многое другое, как и я давным-давно.
Но иногда я задаюсь вопросом о пользе использования этих вещей. Не могли бы вы просто написать несколько строк HTML-кода для форм? Или написать больше строк кода в представлениях вместо того, чтобы делать сериализаторы или разрешения?
Да, вы можете сделать именно это, чтобы сделать то же самое. Но то, что вы можете это сделать, не означает, что вы ДОЛЖНЫ это делать.
Во-первых, ручные HTML-формы небезопасны! Используя формы Django, ваши формы будут более безопасными, поскольку он использует токен CSRF в качестве защиты от подделки межсайтовых запросов. Вы можете искать это самостоятельно, но с точки зрения чистого кода это также не очень хорошо для ручных HTML-форм. Посмотрите на сравнение здесь:
Без форм Джанго:
С формами Джанго:
Вы можете подумать: «Подождите, разве код с формами Django не длиннее?». Да, это дольше, если вы включите файл forms.py. Но если вы сравните только файл views.py, вы увидите, что файл с формами Django будет намного проще и читабельнее, чем без форм Django. Это связано с тем, что даже если код (объединенный) в первом фрагменте длиннее, он аккуратно разделен. Это означает, что вы можете легко сделать вывод о том, что предполагается делать.
В этом суть принципа KISS. Вам нужно сделать код простым и легко читаемым для других, даже если в конечном итоге вы напишете больше кода или вам придется больше думать об этом. Самое главное, что нужно вынести из этого, — сделать простой и читаемый код для других.
Используйте представления на основе классов, а не представления на основе функций
При необходимости используйте представления на основе классов вместо представлений на основе функций. Это связано с тем, что, хотя представления на основе функций более гибкие, чем их аналог, представления на основе классов будут более удобочитаемыми для длинных и избыточных функций/представлений.
Я не буду долго объяснять это, так как большинство людей, вероятно, знают о представлениях на основе классов, но вы можете ознакомиться с другим моим рассказом о рефакторинге в Django здесь. Один из разделов посвящен представлениям на основе классов в Django REST Framework.
3. СУХОЙ в Джанго
DRY или Don’t Repeat Yourself — это принцип, который объясняет сам себя. Вы не должны повторяться в своем коде. Некоторые вещи, которые вы можете сделать в Django, чтобы уменьшить избыточность:
Используйте декораторы для ограничения доступа к представлениям
Если вы раньше не использовали декораторы, вы, вероятно, писали это в своих представлениях раньше:
if request.user.is_authenticated:
И если у вас есть несколько представлений в одном файле, это может выглядеть так:
Что, если я скажу вам, что есть лучший способ, который не включает в себя копирование и повторение себя снова и снова? Вот как с декораторами:
Ух ты! Круто, да? Вы также можете видеть, что в декораторе вы можете написать любой пользовательский код, какой захотите. Так что это не только для ограничения доступа к представлениям или перенаправления вас куда-то. Вы можете сохранять вещи в сеансе пользователя, такие как пути URL-адресов реферера, прежде чем они перейдут в представление, или многие другие вещи, которые вы можете себе представить. Небо это предел!
Поместите часто используемые коды в отдельные вспомогательные функции и в отдельный файл
Это еще один пример, который действительно легко реализовать для всех нас! Извлеките часто используемый код в отдельную вспомогательную функцию и поместите его в utils.py файл.
Пример отправки писем без вспомогательных функций:
Пример отправки писем с вспомогательными функциями:
Разница довольно разительная, если честно, и для более сложных и сложных функций она была бы гораздо более нужна.
4. ЯГНИ в Джанго
YAGNI или вам это не понадобится Это принцип, который говорит нам не забегать вперед. Иногда я и, возможно, некоторые из вас писали код для «будущего». Может быть, нам понадобится то или иное позже, так что не могли бы вы написать это прямо сейчас? Неа! Это действительно плохая привычка для чистого кода, потому что чаще всего вам не понадобится этот код.
Например, я вернусь к декораторам, которые мы обсуждали ранее. Возможно, узнав, что мы можем делать @login_required декораторов, мы хотели бы сделать еще один для пользователей, которым qualified.
Ну, мы еще не реализовали эту qualified вещь, но, может быть, мы напишем ее сейчас на «будущее».
Ну... сделано.
2 года спустя…
«Что это за «квалифицированный» декоратор?»
Да, вы, вероятно, забыли об этом и никогда не использовали его. Это потому, что вам это, вероятно, не нужно в первую очередь. Итак, вывод из этого заключается в том, что вы не должны добавлять функциональность или любой другой код, пока это не будет сочтено необходимым, если только вы не хотите раздутую и беспорядочную кодовую базу для своих проектов.
