Согласен, я только учусь писать быстро, со смыслом, так и чтобы красиво. Если вдруг будут советы, где подсмотреть качественный стиль написания подобных статей или что можно было бы поправить в текущей, буду признателен.
Да, полностью согласен и продавать бизнесу рефакторинг подобного рода сложно (а фриланс я вообще никогда не учитываю, для меня это сторонний мир)
Среднестатистически я пытаюсь оцифровать затраты, которые несет бизнес (сколько стоит uptime, как много часов бэклога ушло на дебагинг системы, доработку самопала или оптимизацию взаимодействия с ним, сколько тратиться на инфру, что разработчики не могут использовать из-за самопала из-за чего новые фичи выходят медленнее) и какие фичи они долгосрочно хотят, прикидывая как новое решение поможет достичь этого, потом предоставляю эти цифры, со словами: "Вот эти деньги мы сможем сохранить и конвертировать в больше фич, если сделаем вот это" – и дальше уже то, насколько я был убедителен
Уверен ли каждый раз в своих словах? Нет, удивительно насколько часто это все субъективно, НО практика показывает, что с опытом начинаешь попадать все четче и четче и это опуртонистическое: "нас ждет светлое будущее" – может и не в такой степени, но сбывается
Важно рисковать, брать ответственность, показывать всем бенефиты, но готовиться к шторму
Да, в данной ситуации (1) код был разбросан необоснованно, (2) пост больше про еще одно преимущество складывать связанный код ближе друг к другу, ЕСЛИ такая возможность имеется, (3) я вернул все на места, потому что это прод код, который сделан так как сделан и на данный момент единообразие всей кодовой базы – более ценно для всех, чем модификация одного куска.
При этом в дальнейшем, команда мигрирует уже на подход с лоцирование кода ближе к месту использования.
Наша ветка — прекрасный пример тому, что несмотря на приличное количество контрпримеров, основной текст (и тон) вашего поста остался без изменений.
Да, потому что это мой пост и мое мнение, а есть ваше мнение.
Я хочу, чтобы вы не пропагандировали идею, что что-то, называющееся «законом Деметры» на самом деле является сколько-нибудь объективным правилом, ведущим к хорошему коду.
Для вас нет, а мне и моим коллегам знание этого принципа полезно для принятия решения использовать или не использовать его в той или иной ситуации.
У всех есть свои догмы, у меня свои. Я, например, считаю, что типизация приносит исключительно положительный эффект, а есть люди, которые против использования типизации. Я с ними дел вести не буду.
У вас есть позиция против LoD, ок, это ваша позиция.
Ну то есть ваша цель — она «получить побольше комментариев»?
Начать диалог с аудиторией, потому что в процессе диалога рождается много полезных мыслей и идей. Например, наша с вами ветка – прекрасный тому пример.
А «правила» вообще существуют в определенных рамках.
Оно называет «Правило / Закон Деметры», вы хотите чтобы я перевел это как-то по-другому? Кажется, вы не заметили, что лично я использую в статье слово «принцип»
Согласен, но вы очень категоричны, мне нравится мое название, оно завлекает и заставляет людей написать почти 40 комментариев)
… а вмержить все равно не дадут, потому что правила.
Мы говорим про терминологию, а не устав процесса разработки компании, это абсолютно разные вещи. Это как соотносить «замок» на двери, и «замок» при вязке собак.
Поэтому, какое бы не было название у термина / паттерна, если его несоблюдение не мешает скомпилировать / воспроизвести программу с требующейся логикой это всегда «рекомендация». А если вы решили добавить его в устав, тогда становиться «правилом», но только в определенных рамках.
Случай с текстом не критический (хоть и влияет на восприятие), а вот случай с «обращением к локальной переменной» приведет к ошибке во время компиляции / исполнения кода.
Так вот, хоть и дословный перевод «Law of Demeter» получается «Правило / Закон Деметры», но, конечно же, на деле, это «рекомендация», потому что соблюдение / не соблюдение данного «правила» не повлияет на runtime или компиляцию кода.
Поэтому, какое бы не было название у термина / паттерна, если его несоблюдение не мешает скомпилировать / воспроизвести программу с требующейся логикой это всегда «рекомендация».
И опятьже ".Active()" это раскрытие подробностей, о которых внешнему коду может быть (зависит от бизнес-требований, о чем я писал выше) абсолютно не нужно знать.
В объект, который из логики самого домена должен управлять вложенными объектами.
Я думаю, что вам стоит почитать про Агрегаты из DDD, скорее всего, вам они тоже не понравятся, они тоже направлены на то, чтобы управлять всеми операциями, которые относятся к подчиненным / вложенным Сущностям.
а это совершенно не обязательно правильно
Да, именно так, поэтому я и написал в статье, что надо использовать «здравый смысл»)
Поменял
Согласен, я только учусь писать быстро, со смыслом, так и чтобы красиво. Если вдруг будут советы, где подсмотреть качественный стиль написания подобных статей или что можно было бы поправить в текущей, буду признателен.
Да, полностью согласен и продавать бизнесу рефакторинг подобного рода сложно (а фриланс я вообще никогда не учитываю, для меня это сторонний мир)
Среднестатистически я пытаюсь оцифровать затраты, которые несет бизнес (сколько стоит uptime, как много часов бэклога ушло на дебагинг системы, доработку самопала или оптимизацию взаимодействия с ним, сколько тратиться на инфру, что разработчики не могут использовать из-за самопала из-за чего новые фичи выходят медленнее) и какие фичи они долгосрочно хотят, прикидывая как новое решение поможет достичь этого, потом предоставляю эти цифры, со словами: "Вот эти деньги мы сможем сохранить и конвертировать в больше фич, если сделаем вот это" – и дальше уже то, насколько я был убедителен
Уверен ли каждый раз в своих словах? Нет, удивительно насколько часто это все субъективно, НО практика показывает, что с опытом начинаешь попадать все четче и четче и это опуртонистическое: "нас ждет светлое будущее" – может и не в такой степени, но сбывается
Важно рисковать, брать ответственность, показывать всем бенефиты, но готовиться к шторму
Да, в данной ситуации (1) код был разбросан необоснованно, (2) пост больше про еще одно преимущество складывать связанный код ближе друг к другу, ЕСЛИ такая возможность имеется, (3) я вернул все на места, потому что это прод код, который сделан так как сделан и на данный момент единообразие всей кодовой базы – более ценно для всех, чем модификация одного куска.
При этом в дальнейшем, команда мигрирует уже на подход с лоцирование кода ближе к месту использования.
Да, потому что это мой пост и мое мнение, а есть ваше мнение.
Для вас нет, а мне и моим коллегам знание этого принципа полезно для принятия решения использовать или не использовать его в той или иной ситуации.
У всех есть свои догмы, у меня свои. Я, например, считаю, что типизация приносит исключительно положительный эффект, а есть люди, которые против использования типизации. Я с ними дел вести не буду.
У вас есть позиция против LoD, ок, это ваша позиция.
Начать диалог с аудиторией, потому что в процессе диалога рождается много полезных мыслей и идей. Например, наша с вами ветка – прекрасный тому пример.
Оно называет «Правило / Закон Деметры», вы хотите чтобы я перевел это как-то по-другому? Кажется, вы не заметили, что лично я использую в статье слово «принцип»
Согласен, но вы очень категоричны, мне нравится мое название, оно завлекает и заставляет людей написать почти 40 комментариев)
Мы говорим про терминологию, а не устав процесса разработки компании, это абсолютно разные вещи. Это как соотносить «замок» на двери, и «замок» при вязке собак.
Поэтому, какое бы не было название у термина / паттерна, если его несоблюдение не мешает скомпилировать / воспроизвести программу с требующейся логикой это всегда «рекомендация». А если вы решили добавить его в устав, тогда становиться «правилом», но только в определенных рамках.
Так вот, хоть и дословный перевод «Law of Demeter» получается «Правило / Закон Деметры», но, конечно же, на деле, это «рекомендация», потому что соблюдение / не соблюдение данного «правила» не повлияет на runtime или компиляцию кода.
Поэтому, какое бы не было название у термина / паттерна, если его несоблюдение не мешает скомпилировать / воспроизвести программу с требующейся логикой это всегда «рекомендация».
Можете привести пример полноценного правила?
А можете привести пример «правил», которые нарушать нельзя нигде и никогда?
Любой адекватный программист понимает, что правила – это ориентир, а не неприкосновенная истина.
Ими можно пользоваться, а можно этого не делать. Выбор за каждым.
Просто не везде бывают getter (например в Golang в любом случае пришлось бы писать метод getComments)
Это как-то слишком похоже на QueryBuider, поэтому я скорее за «repository.Where(ActiveSpecification())», но это лично моя вкусовщина.
Через переопределение getter?
А, вы в формате Active Record пишите, понял. Я использую Repository, чтобы больше сохранять чистоту Сущностей.
Как именно будет спрятано?
Вы выстаиваете цепочку методов от post, а спецификация должна существовать как отдельный класс с chain methods или как command.
Я не говорил что LoD это говорит, наоборот, if бизнес-логика требует управлять вложенными сущностями -> можно использовать LoD
Это супер и они как раз являются отличными примером того, как LoD помогает структурировать код.
Спецификация не должна быть частью сущности post, вот здесь есть хороший пример Specification blog.byndyu.ru/2014/07/command-and-query-responsibility.html
В объект, который из логики самого домена должен управлять вложенными объектами.
Я думаю, что вам стоит почитать про Агрегаты из DDD, скорее всего, вам они тоже не понравятся, они тоже направлены на то, чтобы управлять всеми операциями, которые относятся к подчиненным / вложенным Сущностям.
Да, именно так, поэтому я и написал в статье, что надо использовать «здравый смысл»)