Разбираемся с YAGNI, KISS, DRY

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

YAGNI

«You Aren't Gonna Need It» или «тебе это не понадобится».

Принцип из которого следует, что нужно удалять все методы, функции, классы и любой другой код, который не используется. Если ты думаешь, что этот код может быть еще когда-то пригодится — нет, он не пригодится. А если и когда-то вдруг он понадобится, то можно будет его взять из гита.

Условно, если в сервисе был какой-то обработчик xls-файлов и вы с командой поняли, что им никто не пользуется и он вам уже не нужен, то стоит не только с фронта убрать кнопку с загрузкой, но и убрать все, что с ним связано везде.

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

DRY

«Don't repeat yourself» или «Не повторяйся».

Как я писал во вступлении к данной статье, то уже упомянул данный принцип и то, что он не совсем прост как может показаться.

Например, у нас есть функции, которые скачивают космические фотографии через API NASA, для примера мы рассмотрим одну и представим, что в каждой такой функции у нас повторяется логика со скачиванием фото.

Ниже представлена чистая функция, реализующая данный функционал.

def download_image_from_nasa_apod(nasa_token,
                                  count=30,
                                  path_to_save='images/'):
    api_url = 'https://api.nasa.gov/planetary/apod'
    params = {
      'api_key': nasa_token,
      'count': count,
    }

    os.makedirs(path_to_save, exist_ok=True)

    response = requests.get(api_url, params)
    response.raise_for_status()
    response = response.json()

    for item in response:
        if 'hdurl' in item:
            download_image(get_filename(item['hdurl']),
                           item['hdurl'], path_to_save)

1. Мы получаем в функцию токен, количество страниц для просмотра API и путь для сохранения изображений.
2. Создаем папку, на случай если ее нет. Если она есть, то ничего не произойдет.
3. И в последнем цикле начинаем сохранять изображения. Ты можешь заметить, что в цикле используется для функции — get_filename() и download_image().

def get_filename(url):
    path = urlparse(url).path
    path = unquote(path)
    filename = os.path.basename(path)

    filename = filename.replace(' ', '_')
    return filename

def download_image(image_name, image_url, path_to_save):
    response = requests.get(image_url)
    response.raise_for_status()

    with open(f'{path_to_save}{image_name}', 'wb') as file:
        file.write(response.content)

Вышеприведенные функции хранятся в отдельном файле с обработчиками и такое решение соответствует принципу DRY.
Если бы мы их не вынесли отдельно и повторяли в каждой функции, которая отвечает за обращение к API, то код стал бы очень громоздим и более сложным в управлении.

Самое простое решение по уменьшению сложности – разделить систему на мелкие, независимые модули, которыми проще управлять.

KISS

«Keep It Simple Stupid» или «Делай проще, тупица».

Есть и другой вариант расшифровки данного акронима, например, «Keep it short and simple». Так что выбирай то, что тебе больше по душе. Есть еще достаточно много всевозможных вариантов расшифровок, можно заглянуть на википедию и посмотреть там.

По поводу данного принципа, да и других по большей части, достаточно много споров. Поэтому здесь я опишу наиболее близкие критерии для меня:

• Не нужно подключать всю библиотеку, если нужна одна функция или даже три.
• Не делать больше, чем нужно. Т.е. не нужно докидывать сверху оговоренного функционалы еще какие-то вещи от себя. Инициатива штука хорошая, но как минимум это нужно обсудить с заказчиком.
• Не нужно делать сложную логику, если это не требуется.

Данный принцип декларирует простоту системы в качестве основной ценности или цели. И фактически сюда можно включить такие принципы, как: «меньше - лучше», «не повторяй себя (DRY)».