Бото*бы, говнокод и профессионализм — разбираем критику [18+]

YOUTUBE · 01.12.2025 06:00

Ключевые темы и таймкоды

Введение и контекст

0:00

Автор обсуждает критику своего телеграм-бота, разработанного для книжного клуба.
Упоминается использование ненормативной лексики в комментариях критиков.
Стрим по разработке бота длился 9,5 часов и завершился созданием первой рабочей версии.

Критика от Александра Данилова

1:29

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

Реакция на критику

3:26

Автор подчёркивает, что большинство разработчиков ботов ведут себя нормально.
Видео создано в ответ на вопросы зрителей, а не на критику Александра.

О профессиональности

5:00

Автор просит не считать его профессионалом, так как он не является программистом.
Рекомендует начинающим разработчикам обращаться к профессионалам из сообщества Aogram.

Выбор библиотек

5:50

Обсуждается важность количества звёзд на GitHub для выбора библиотек.
Подчёркивается, что эти показатели помогают оценить популярность и актуальность библиотек.

Выбор Aogram

7:44

Автор объясняет, почему не выбрал Aogram для своего проекта.
Отмечает, что Aogram не лидирует по популярности на GitHub и не понравился ему по документации.

Функциональность бота

8:44

Автор описывает функциональность своего бота: приём и отправка сообщений, онлайн-клавиатура.
Утверждает, что все необходимые функции можно реализовать напрямую через Telegram Bot API без использования сторонних библиотек.

Заключение

9:45

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

Выбор библиотеки для проекта

9:58

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

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

10:53

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

Интуитивность сайта AioGram

12:46

Сайт AioGram не интуитивен: сложно найти документацию.
На сайте Python Telegram Bot Development Community документация более очевидна.
Дополнительные усилия для поиска документации снижают привлекательность библиотеки.

Важность простоты использования

14:43

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

Популярность Python Telegram Bot

15:42

Python Telegram Bot — самая популярная библиотека для разработки Telegram-ботов.
Запросы на AioGram менее популярны, возможно, из-за более широкого поиска библиотек для Telegram-ботов.

Выбор библиотеки для разработки

16:32

Обсуждение эффективности использования библиотек по сравнению с прямым взаимодействием с Telegram.
Упоминание о простоте задачи и возможности быстрого написания кода.

Очевидность некоторых вещей

17:29

Подчёркивание очевидности некоторых действий, например, включения компьютера в розетку.
Объяснение, почему автор показал процесс заведения бота на стриме.

Оценка кода

18:24

Признание того, что код на стриме может быть «говнокотом», но это нормально в определённых условиях.
Важность учёта контекста при оценке кода.

Дисклеймер и задачи

19:22

Дисклеймер о выборе библиотеки и отношении к сообществу ботописателей.
Цель — оперативно реализовать необходимый функционал.

Рефакторинг и оптимизация

20:22

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

Подходы к разработке

22:13

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

Аналогия с кухней

24:09

Аналогия между быстрым приготовлением блюда и созданием произведения искусства.
Поиск баланса между качеством и скоростью в разработке.

Приоритет результата

25:22

Результат — это достижение поставленной цели.
Цель должна быть конкретной и правильно сформулированной.
Идеальный код не всегда означает достижение результата.

Рефакторинг и достижение результата

26:21

Рефакторинг следует проводить только после достижения результата.
Автор достиг результата к десятому часу стрима, но не стал рефакторить из-за усталости.
Неидеальное решение было получено за девять часов.

Процесс и результат

27:20

Процесс важен в сексе, но в жизни важнее результат.
Цитата Эйнштейна: «Надо делать настолько хорошо, насколько возможно, но не лучше».
Профессионализм определяется достижением результата.

Техническое задание

28:43

ТЗ можно писать в любом формате, не обязательно в документе.
В данном случае ТЗ было написано в Redmine.
Выбор фреймворка и написание ТЗ зависят от задачи.

Выбор инструментов

29:42

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

Миграции и ручной код

32:41

Миграции не всегда необходимы, особенно в небольших проектах.
Автоматически сгенерированные миграции также требуют проверки.
Ручной код может быть эффективным в некоторых случаях.

Использование GUID

34:12

GUID не всегда полезны для небольших баз данных.
Схема данных должна быть эффективной, а не сложной.
Не бывает идеального решения для всех сценариев.

Эффективность

35:29

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

Сложности автоматизации

36:47

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

Унификация баз данных

37:43

База населённых пунктов для служб доставки разная, что усложняет унификацию.
Сведение разных баз требует значительных усилий, включая ручной труд.
Пример: СДЭК доставляет в десятки тысяч населённых пунктов, но модуль доставки в Битрикс считает только тысячу крупных городов.

Значение ручной работы

39:41

Иногда ручная работа может быть более эффективной, чем автоматизация.
Не стоит бояться ручной работы, даже если она неприятна.
Важно достигать результата, а не просто автоматизировать всё.

Индексы и миграция

40:40

Индексы не всегда необходимы и могут быть дорогостоящими.
Миграции не всегда нужны, особенно если данные не меняются.
Специалисты должны использовать только необходимые инструменты для проекта.

Слои приложения и рефакторинг

41:36

Слои приложения должны быть чётко разделены во время рефакторинга.
Перемешивание слоёв может привести к проблемам в будущем.
Иногда использование ORM оправдано, но не всегда.

Размещение ботов

42:35

Боты обычно размещаются на серверах в дата-центрах, а не на локальных компьютерах.
Настройка PostgreSQL на сервере требует времени и усилий.
Использование SQLite упрощает процесс запуска ботов.

Популярность библиотек

43:34

Библиотека SQLite имеет мало звёзд на GitHub по сравнению с другими проектами.
Python-telegram-bot имеет 20 тысяч лайков, в то время как SQLite — всего 2800.
Это вызывает удивление, учитывая популярность Python в реальных проектах.

Типизация данных

45:03

Объяснение, что работа не связана с ORM, а направлена на типизацию данных.
Сущности и структуры данных облегчают поддержку и рефакторинг кода.
Классы не обязаны соответствовать таблицам базы данных.

Выбор инструментов

46:00

Инструменты выбираются под конкретную задачу с учётом её особенностей и ограничений.
Пример с телеграм-ботом для книжного клуба: не нужно решать все задачи мира.
Глобальная функция `get_all_books` в модуле `books` используется публично.

Подключение к базе данных

47:24

Проблема с переподключением к базе при каждом запросе.
Необходимость рефакторинга для улучшения производительности.

Лимиты Telegram

47:46

Упоминание о лимитах на отправку сообщений в Telegram.
Признание, что автор не знал о лимитах.

Размер чанка и лайф кодинг

48:44

Обоснование размера чанка 50–60.
Подчёркивание важности достижения результата в условиях ограниченного времени.

Конкатенация строк

49:07

Критика конкатенации строк с помощью плюса.
Планы по рефакторингу для улучшения кода.

Тесты и хакатон

50:08

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

Маркдаун-разметка

51:07

Использование маркдаун-разметки в боте вместо HTML.
Отсутствие стыда за использование устаревшего метода.

Отзывы о курсе

52:07

Демонстрация положительных отзывов о курсе на Stepik.
Подтверждение удовлетворённости студентов курсом.

Критика и предложение помощи

53:03

Критика легкомысленного подхода к критике.
Предложение помощи и консультации по созданию YouTube-канала.

Заключение

54:03

Пожелания удачи и хорошего настроения.
Прощание и приглашение к следующему выпуску.