Как не надо учиться программированию
Новичкам важно копировать хорошие практики, но обучающие видео не дают такой возможности.
Иногда, чтобы не тратить много времени на чтение документации и, в то же время, быстро получить представление о какой-то теме я смотрю видосы. Ну, знаете, такие типа "как сделать телеграм бота" или "как заюзать S3 для картинок". Они помогают очень быстро получить общую картину. Но, как правило, помимо введения в тему, они демонстрируют ужасный стиль программирования. Об этом я хочу сегодня поговорить.
В моих примерах будет код на C#, но они, в той или иной степени, применимы к любому современному языку. Без долгих рассуждений пройду по проблемам.
1. Хардкодим ключи, логины, пароли и т.д.
Что тут не так? А вот что:
- если код уйдёт в git, то эта инфа станет доступной всем кто имеет доступ к репе. Даже если потом поменять подход, история никуда не денется и можно вытащить настоящие ключи доступа.
- для того, чтобы поменять эту инфу нужно пересобирать проект и по новой деплоить, вместо того, чтобы изменить конфиг или переменную среды
- если такие значения понадобятся в разных частях программы придётся переписывать подход, но скорее всего те кто так написал, просто захардкодят их ещё в паре мест (да начнётся хаос!)
2. Всё пишем в одном единственном методе Main()
- Main - это точка входа, тут должно быть только самое необходимое - конфигурация приложения и запуск (не реализация, а запуск) основного функционала.
- c# - это ООП, и писать на нём нужно именно в это парадигме, он не предназначен для другого
- даже простой функционал небольшого приложения, реализованный в одном едиственном методе, превращает код в помойку
3. Делаем вид, что исключений не бывает
- -исключения бывают, и бывают довольно часто, если их не отлавливать в нужном, приложение просто упадёт
- часть исключений нужно отлавливать, обрабатывать и пробрасывать выше а часть не пробрасывать, а часть не ловить в одном месте, а ловить в другом
4. Игнорируем или не знаем, что существует такая штука как Stream
- в основном, в операциях ввода-вывода, используют ReadToEnd, не смотря на объём получаемого и процессы последующей обработки
- при более менее масштабной обработке входных данных, использование Stream может кратно сократить потребление памяти
5. Запустили Task и молимся
- если мы запустили на выполнение асинхронный Task, то у нас нет официальных рычагов воздействия на него кроме CancellationToken
если такой таск залип на ожидании ответа от внешнего сервиса, то ждать его можно очень долго
Конечно проблем гораздо больше, чем я тут перечислил. Давайте теперь к сути.
Люди, которые записывают обучающие видео с таким веером проблем, скорее всего сами не понимают, что они пишут, либо просто забивают. Лично я резко негативно отношусь к таким "обучающим материалам". Дело в том, что их читают и смотрят те, кто только учится разрабатывать софт, и, обучаясь на таких примерах, они сразу впитывают ужасный стиль программирования.
Вынести ключи в конфиг, сделать класс TelegramBotService, и создавать CancellationToken при IO операции не так уж и сложно. Да, чуть сложнее, чем хардкод и свалить всё в Main(). Да это может отпугнуть тех, что хочет "войти в IT". Но если ты берёшься обучать кого-то, отвечай за качество этого обучения. Думаешь, что просто выложил видос, набрал лайков, пару подписок и всё закончилось? Нет, люди научились писать плохой код на таком видео. Кто-то написал себе бота и забросил разработку. Кто-то пошёл с этими "знаниями" на собес и провалился. Те кто поамбициознее и поупорнее пошли на фриланс писать ботов для телеги, и может даже написали парочку, но очень глючных.
А всё началось с одного популярного видео с плохим кодом. Последствия - вполне реальные и для многих - болезненные.