unam3 / trial-bot-all Goto Github PK

Сейчас Config телеги (который, вообще-то стейт)

data Config =
  Config
    { tokenSection :: TokenSection
    , helpMessage :: HelpMessage
    , repeatMessage :: RepeatMessage
    , numberOfRepeats :: NumberOfRepeats
    , numberOfRepeatsMap :: NumberOfRepeatsMap
    }

содержит в себе два типа полей: статические, которые не меняются во время выполнения: repeatMessage, helpMessage, tokenSection, NumberOfRepeats. И динамический numbersOfRepeatsMap. Совмещать в одном типе данных две разные штуки -- стейт и статическое окружение не стоит, если в этом нет необходимости.

Обычно для хранения окружения используют ReaderT, а для состояния либо StateT либо в ридер кладут MVar, TVar или IORef, но можно и просто передавать аргументом ф-ии

Тоже самое относится к "конфигу" вк

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

Для уменьшения сложности есть следующие подходы:

1. Разделяй большую функцию на функции поменьше. Итоговая проблема которую решала функция разделится при этом на более мелкие проблемы и читающему код станет легче поскольку в голове в каждый момент чтения можно будет держать меньше информации. Это вообще классический принцип, он помогает не только понимать программы, но и в принципе их писать, я думаю ты о нем слышал, есть даже на вики статья.
2. Нужно постараться сделать так чтобы у каждой функции была одна зона ответственности, чтобы у нее была одна четкая цель. Тоже стандартный термин для этого применяется - связность.
3. Используй стандартные паттерны проектирования вместо того чтобы заново их реализовывать самому. Например, для обработки списков есть функции filter, map, foldr (есть также для списков с эффектами аналоги). Не стоит использовать рекурсию, а вместо этого лучше выразить то же через стандартные функции. Поскольку каждый их встречал и использовал, читающему будет легче понять смысл функции. Заметил подобный код в Telegram.HandleUpdates.handleUpdates.
4. Уменьшить вложенность кода. Каждый дополнительный уровень приводит к тому, что при чтении необходимо помнить все вложенные конструкции вверх по "стеку".

https://rizzoma.com/topic/c27faf1cfa188c1120f59af4c35e6099/0_b_9n8n_8jl2r/

Весь код проверен через hlint и не вызывает ни одного варнинга.

Из дока

В ответ на запрос сервер может вернуть одну из ошибок:
{"failed":1,"ts":30}
{"failed":2}
{"failed":3}
"failed":1 — история событий устарела или была частично утеряна, приложение может получать события далее, используя новое значение ts из ответа.
"failed":2 — истекло время действия ключа, нужно заново получить key методом groups.getLongPollServer.
"failed":3 — информация утрачена, нужно запросить новые key и ts методом groups.getLongPollServer.
Обратите внимание, объекты в сообщении об ошибке могут содержат поля, не описанные в документации. Их необходимо игнорировать и не пытаться обработать.

По хорошему эти кейсы надо обрабатывать

• Использование нетотальных ф-ий (тех которые могут вывалится с рантайм ошибкой) крайне желательно избегать. В коде достаточно много используется fromJust. В случае init, head лучше использовать деконструкцию списка
• В целом отсутствует обработка ошибок. Если выпадет ексепшн по любому поводу у всего приложения большие шансы закрашиться. Для обработки ошибок можно использовать разные подходы: ExceptT, catch/try, явный возврат Maybe/Just. Каждую ошибку хорошо бы логгировать в собственном логгере с уровнем error

[Tg] Only latest text message (from updates) will be processed.

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