Изначально суд признал неправоту банка, но последующие инстанции встали на его сторону.
Непонятно почему последующие инстанции всатли на сторону банка, хотя верховный суд привел весьма логичные доказательства правоты пользователя, а адвокат вроде приводит нелогичные доказательства, например:
Наконец, как отметил судья, банк может заблокировать деньги на счёте только по решению суда либо по постановлению органов предварительного следствия при наличии судебного решения.
Получается суды разрешают блокировать деньги на счетах пользователей?
В классе User вызов функции AddDomainEvent(new UserWasCreated(Id, Email)); // детали реализации скрыты Откуда эта функция, т.е. какой класс хранит ее реализацию, прям сам класс User?
Как хорошо, что не программисты не нанимают программистов. По вашему комментарию я понял, что вы не понимаете сути программирования, а "смотрите на рюшечки".
В простых приложениях, например Todo App на React (классика) очень хорошо работают многие паттерны - например можно разбить компоненты на мельчайшие части, прям компоненты по 1 строчке. Т.е. удается добиться максимального Single Responsibility. Однако это не значит что это сработает в продакшене.
Хотелось бы по продакшеннее примера Feature-Sliced Design.
Мне кажется ваша ошибка комментария в том, что люди считают что это ВЫ считаете что ВАМ нужно унижаться до уровня работника, т.е. все плохие черты переносят на вас.
Вам корона не жмет?
Вот человек прямым текстом говорит - Вам.
Если вы проводите собеседования, к вам большая просьба: сразу прямо сообщайте соискателю свое позицию.
Зря вы публикуете такие статьи. GetMatch известное и позиционирующее себя как топовое агенство. Пиара на этой статье вы не словили, по крайней мере не того хайпа который был бы полезен.
Т.е. без правил Дядюшки Боба — получится средний, шаблонный, стандартный код. Но если ты освоишь все правила Дядюшки Боба, то получится шедевр. Но если не освоишь — получится наоборот — говнокод.
Ну это мое видение как я применяю правила Дядюшки Боба. Т.е. можно попробовать другой подход - начать с малого, применять постепенно, как-то попробовать так. Т.е. если что-то не работает у меня, то это не значит что оно вовсе не работает и прям никто не применяет это правильно и все начинают применять одинаково и у всех все одинаково.
Понимать Дадюшку Боба очень сложно. Первый пример из статьи:
Не раскрывай детали реализации используя исключения.
Если обработка ошибок раскрывает реализацию — то это неправильная обработка ошибок
Не цитата Дяди Боба, но на этом принципе построен первый пример.
Представьте, если ваша упоминаемая http библиотека будет бросать исключение - UnableToDoNeededHttpRequest, что переводится как "НеУдалосьВыполнитьHttpЗапрос". И ты хрен поймешь в чем там проблема - DNS не нашел имя, connect на порт не удался, сервер ответил 500. Детали реализации то мы не раскрываем.
Хорошо, но для решения проблемы есть пункт
Название исключения надо давать настолько подробным, чтобы описание было вообще не нужно.
Т.е. проблема решается такими исключениями, которые говорят сами за себя.
Попробуй теперь выполнить сразу 2 правила.
И не раскрыть что мы делаем DNS запрос.
И сообщить, что проблема в шаге с DNS запросом.
Сразу и не придумаешь как это реализовать.
Это не шаблонный и понятный DnsErrorException (который нарушает оба правила, зато придумывается за 1 секунду и получается в итоге достаточно "шаблонный" квадратно-ездовой код).
Hidden text
Будет UnableToFindServerByName исключение.
И не раскрывает детали реализации (только совсем верхнеуровнево), и говорящее само за себя имя исключения.
Еще надо подумать как дать красивое название исключению.
Итог: Если ты взял часть правил из рекомендаций Дядюшки Боба и выполнил, а часть правил понял неправильно, и не выполнил - то получится лютый говнокод. Т.к. применяя первую часть правил ты сильно усложняешь код, и создал сложные ситуации, и чтобы решить сложные проблемы ты не смог применить вторую часть правил.
Т.е. без правил Дядюшки Боба - получится средний, шаблонный, стандартный код. Но если ты освоишь все правила Дядюшки Боба, то получится шедевр. Но если не освоишь - получится наоборот - говнокод.
Согласно чистому коду - код как раз должен быть таким чтобы не надо было смотреть как устроен трифт. А код который надо смотреть как устроен - и я могу написать.
/** Раскрываем подробности того, что ходим в сервис комиссий */
throw CommissionServiceTimeout()
}
Вы можете пояснить как из TGetCommission вы получили таймаут? А может там не таймаут, может там 500 из-за бага в коде? Как вы так "кастите" TGetCommission именно в CommissionServiceTimeout?
Статья полезна, чтобы понимать что вообще происходит, как это работает. Т.е. как это вживую работает на низком уровне, в одном из вариантов реализации. Спасибо. Очень интересно (для начинающего уровня).
Непонятно почему последующие инстанции всатли на сторону банка, хотя верховный суд привел весьма логичные доказательства правоты пользователя, а адвокат вроде приводит нелогичные доказательства, например:
Получается суды разрешают блокировать деньги на счетах пользователей?
В классе User вызов функции
AddDomainEvent(new UserWasCreated(Id, Email)); // детали реализации скрыты
Откуда эта функция, т.е. какой класс хранит ее реализацию, прям сам класс User?
В Windows есть Shadow Copy, можно посмотреть историю файла. Но надо включать и настраивать. В Mac OS - Time Machine (но может уже убрали).
Как хорошо, что не программисты не нанимают программистов. По вашему комментарию я понял, что вы не понимаете сути программирования, а "смотрите на рюшечки".
Я вот плачу Яндексу, и пока буду платить достаточно, Яндекс не удалит мои данные.
А не может быть такого, что они "ой недотестировали", потому что они "плохо старались"?
Как менеджер по продажам. "У нас в фирме качество." А что за качество, что там - непонятно.
Пруфов нет.
В простых приложениях, например Todo App на React (классика) очень хорошо работают многие паттерны - например можно разбить компоненты на мельчайшие части, прям компоненты по 1 строчке. Т.е. удается добиться максимального Single Responsibility. Однако это не значит что это сработает в продакшене.
Хотелось бы по продакшеннее примера Feature-Sliced Design.
А как оказывается из примеров на сайте feature sliced design - todo app'ы. На udemy смотрел такие курсы "сайт кинофильмов за 4 часа".
Немного грубовато (наверное по-этому вы ловите минусы), но отличный свежий взгляд на решение проблемы.
Мне кажется ваша ошибка комментария в том, что люди считают что это ВЫ считаете что ВАМ нужно унижаться до уровня работника, т.е. все плохие черты переносят на вас.
Вот человек прямым текстом говорит - Вам.
Но я поставил плюс.
Зря вы публикуете такие статьи. GetMatch известное и позиционирующее себя как топовое агенство. Пиара на этой статье вы не словили, по крайней мере не того хайпа который был бы полезен.
Ну это мое видение как я применяю правила Дядюшки Боба. Т.е. можно попробовать другой подход - начать с малого, применять постепенно, как-то попробовать так. Т.е. если что-то не работает у меня, то это не значит что оно вовсе не работает и прям никто не применяет это правильно и все начинают применять одинаково и у всех все одинаково.
Понимать Дадюшку Боба очень сложно. Первый пример из статьи:
Не раскрывай детали реализации используя исключения.
Не цитата Дяди Боба, но на этом принципе построен первый пример.
Представьте, если ваша упоминаемая http библиотека будет бросать исключение - UnableToDoNeededHttpRequest, что переводится как "НеУдалосьВыполнитьHttpЗапрос". И ты хрен поймешь в чем там проблема - DNS не нашел имя, connect на порт не удался, сервер ответил 500. Детали реализации то мы не раскрываем.
Хорошо, но для решения проблемы есть пункт
Т.е. проблема решается такими исключениями, которые говорят сами за себя.
Попробуй теперь выполнить сразу 2 правила.
И не раскрыть что мы делаем DNS запрос.
И сообщить, что проблема в шаге с DNS запросом.
Сразу и не придумаешь как это реализовать.
Это не шаблонный и понятный DnsErrorException (который нарушает оба правила, зато придумывается за 1 секунду и получается в итоге достаточно "шаблонный" квадратно-ездовой код).
Hidden text
Будет UnableToFindServerByName исключение.
И не раскрывает детали реализации (только совсем верхнеуровнево), и говорящее само за себя имя исключения.
Еще надо подумать как дать красивое название исключению.
Итог: Если ты взял часть правил из рекомендаций Дядюшки Боба и выполнил, а часть правил понял неправильно, и не выполнил - то получится лютый говнокод. Т.к. применяя первую часть правил ты сильно усложняешь код, и создал сложные ситуации, и чтобы решить сложные проблемы ты не смог применить вторую часть правил.
Т.е. без правил Дядюшки Боба - получится средний, шаблонный, стандартный код. Но если ты освоишь все правила Дядюшки Боба, то получится шедевр. Но если не освоишь - получится наоборот - говнокод.
Согласно чистому коду - код как раз должен быть таким чтобы не надо было смотреть как устроен трифт. А код который надо смотреть как устроен - и я могу написать.
Первый пример:
Вы можете пояснить как из TGetCommission вы получили таймаут? А может там не таймаут, может там 500 из-за бага в коде? Как вы так "кастите" TGetCommission именно в CommissionServiceTimeout?
Статья полезна, чтобы понимать что вообще происходит, как это работает. Т.е. как это вживую работает на низком уровне, в одном из вариантов реализации. Спасибо. Очень интересно (для начинающего уровня).
На github можно либо скачать весь проект zip архивом сразу, либо ходить по страницам и смотреть веб страницы по 1 файлу.
аа, спасибо