АГ
Разработка сложных проектов - это не просто "бери ReaderT / mtl / whatever"
Size: a a a
2020 October 02
АГ
например?
Например какая либа? Да хоть и SQL. Или метрики какие-нибудь. Или структурное логгирование. Что угодно
Y
Have you heard the tragedy of Dart Plagius the wise?
🤣
YS
Например какая либа? Да хоть и SQL. Или метрики какие-нибудь. Или структурное логгирование. Что угодно
ну вот пока такого нет
YS
ну, таких проблем
YS
В общем, кмк, ты не о том
АГ
Так себе аргумент. Ты, видимо, один работаешь, и проект у тебя не то чтоб сильно большой, да?
AI
я уже рассказывал, как воюю с графкуэлем - единственным рассадником типов в проекте. когда надо попрототипировать и пробросить на фронт разное, проще сделать тип строку, сериализовать в нее кучу навороченных структур а после приема десериализовать. чем описывать это все на уровне типов )
YS
Плохо сделанная система, понятно, будет разваливаться от любых попыток что-то там поменять. Ридеры/мтл/фримонады тут не причем
YS
я уже рассказывал, как воюю с графкуэлем - единственным рассадником типов в проекте. когда надо попрототипировать и пробросить на фронт разное, проще сделать тип строку, сериализовать в нее кучу навороченных структур а после приема десериализовать. чем описывать это все на уровне типов )
значит видимо по твоей задачи он - лишнее)
АГ
Именно. Они ни при чем. Нужны практики их использования. Которые бы позволили предсказывать, что и в будущем ты можешь запихнуть некую непредвиденную фигню в свой проект, с минимальными потерями и рискамми
YS
да эти практики были уже давно придуманы)
YS
дели большое на маленькие части
AI
значит видимо по твоей задачи он - лишнее)
это универсальный а потому ложный тезис
YS
обеспечь взаимодействие маленьких частей
YS
сделай изоляцию тех компонентов, которые не должны знать друг о друге
АГ
@Ordinary_man , можно задать вопрос. У тебя какие планы на карьеру?
YS
те компоненты, которые должны знать друг о друге - держи поближе
YS
@Ordinary_man , можно задать вопрос. У тебя какие планы на карьеру?
ну, кодить
YS
хз как сказать