МФ
нужен отдельный чел который умеет это делать и занимается только этим несколько лет
Как и отдельный чел на написание тестов? :)
Size: a a a
2020 September 26
NF
Как и отдельный чел на написание тестов? :)
не, это же тривиально)
SP
Но количество изменений легко трекать...
Да но там надо динамику смотреть..
AK
Да но там надо динамику смотреть..
А где не надо?
AD
потому что плохая идея «поддерживаемость» мерять строками. На поддерживаемость влияют вполне понятные практики вроде стабильности и количества зависимостей. А как код организован не столь важно. «клади то что меняется вместе рядом, то что не должно меняться вместе - отдельно». Стабильность можно по гиту трекать. Много трогают файлик - не стабильно. Если нестабильно и от этой штуки много кто зависит - значит выше шанс сломать вещи.
Людям просто удобно дрочить на вещи которые легко померять чиселком и которые можно мерять в статике без учета истории изменений
Людям просто удобно дрочить на вещи которые легко померять чиселком и которые можно мерять в статике без учета истории изменений
цикломатической сложностью - хорошая
AD
потому что настрогал чел лапшу на 300 строк ифов траев вайлов и прочей лабуды без задней мысли , ушёл, задача которую оно решало забылась и все, потом это невозможно прочитать.
ВУ
О, сумел пояснить Zen)
он этот Zen тут поясняет несколько лет...
за что ему спасибо. жаль, что доходит не с первого раза)
за что ему спасибо. жаль, что доходит не с первого раза)
AD
10 методов по 35 строк проще прочитать чем лапшу на 300 строк
2020 September 27
SP
10 методов по 35 строк проще прочитать чем лапшу на 300 строк
Не всегда)
AD
Не всегда)
Почти всегда
ВУ
ну если эти 300 строк надо раз в год читать, я согласен на такие 300 строк)
обычно это какой-то инфраструктурный код. парсер, например
обычно это какой-то инфраструктурный код. парсер, например
AD
ну если эти 300 строк надо раз в год читать, я согласен на такие 300 строк)
обычно это какой-то инфраструктурный код. парсер, например
обычно это какой-то инфраструктурный код. парсер, например
А потом тасочка затрагивающая изменения этого метода ещё полгода плодит гейзенбаги
ВУ
А потом тасочка затрагивающая изменения этого метода ещё полгода плодит гейзенбаги
это другой разговор. 300 строк можно тоже по-разному написать и по-разному покрыть тестами.
AD
это другой разговор. 300 строк можно тоже по-разному написать и по-разному покрыть тестами.
Пишут обычно как легче и быстрее
AD
Т.е. как попало
AD
В большинстве языков хорошо написать намного сложнее чем плохо
ch
Написать это наименьшая проблема, не так? Проблема в том чтобы потом поддерживать код
DK
ну если эти 300 строк надо раз в год читать, я согласен на такие 300 строк)
обычно это какой-то инфраструктурный код. парсер, например
обычно это какой-то инфраструктурный код. парсер, например
Да все время больше 300 строк. Взять тот же Android любая внутренняя фича от 10к строк и с непривычки там черт ногу сломи что к чему.
Хороший код появляется при код ревью и когда проснулся и "кто такое мог написать?", и просто исправил, а не пол дня ищу этого того, кем оказываюсь я.
Хороший код появляется при код ревью и когда проснулся и "кто такое мог написать?", и просто исправил, а не пол дня ищу этого того, кем оказываюсь я.
СП
Добрый день. Изучаю сейчас DDD Эванса. Помогите разобраться в чем отличие трансляционного и предохранительного уровней.
Понятно что, предохранительный - это более прокачанный трансляционный. Но в чем отличие, не пойму.
Понятно что, предохранительный - это более прокачанный трансляционный. Но в чем отличие, не пойму.
SP
Добрый день. Изучаю сейчас DDD Эванса. Помогите разобраться в чем отличие трансляционного и предохранительного уровней.
Понятно что, предохранительный - это более прокачанный трансляционный. Но в чем отличие, не пойму.
Понятно что, предохранительный - это более прокачанный трансляционный. Но в чем отличие, не пойму.
anticorruption layer просто частный случай translation layer. Если упрощенно - адаптеры.
Основная идея в том что бы бизнес логика не зависела от инфраструктуры. Простое следствие идеи разделения ответственности и прочих SRP (что бы штуки которые должны меняться по разным причинам лежали отдельно друг от друга).
В целом в этом контексте DDD это все вторично и просто "показать как можно отделить", проще будет там про гексагональную архитектуру почитать (ports/adapters).
Основные тезисы с которыми реально надо разбираться у Эванса в целом в начале книги (там где про моделирование, детали и т.д.) + понятие identity + понятие bounded context. Это важно. Примеры и паттерны которые Эванс предлагает - это уже вторично. Как минимум потому что и без DDD все примерно это предлагают в свлих "чистых луковых и гексагональных" архитектурах, ну и как максимум что странно рассуждать о DDD (как методология исследования и соединения problem и solution space, переработка знаний, общение с бизнесом) как о технических паттернах.
Да есть "тактическое DDD" (тот еще булшит) которое можно трактовать с позиции проектирования распределенных систем
Основная идея в том что бы бизнес логика не зависела от инфраструктуры. Простое следствие идеи разделения ответственности и прочих SRP (что бы штуки которые должны меняться по разным причинам лежали отдельно друг от друга).
В целом в этом контексте DDD это все вторично и просто "показать как можно отделить", проще будет там про гексагональную архитектуру почитать (ports/adapters).
Основные тезисы с которыми реально надо разбираться у Эванса в целом в начале книги (там где про моделирование, детали и т.д.) + понятие identity + понятие bounded context. Это важно. Примеры и паттерны которые Эванс предлагает - это уже вторично. Как минимум потому что и без DDD все примерно это предлагают в свлих "чистых луковых и гексагональных" архитектурах, ну и как максимум что странно рассуждать о DDD (как методология исследования и соединения problem и solution space, переработка знаний, общение с бизнесом) как о технических паттернах.
Да есть "тактическое DDD" (тот еще булшит) которое можно трактовать с позиции проектирования распределенных систем