В простых приложениях, например 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?
Статья полезна, чтобы понимать что вообще происходит, как это работает. Т.е. как это вживую работает на низком уровне, в одном из вариантов реализации. Спасибо. Очень интересно (для начинающего уровня).
Все книги с картинки относятся к IT (программирование, devops), а ссылку на IT не проставили. Только отдельные издательства. А ссылки на подборку с книгами с картинки - нету. Хотя заманивают то в основном книги с картинки.
Не совсем. Дело в том, что в тестах techempower, который показывает самый производительный Web фреймворк используется не коробочное решение, а максимально затюненое решение. Затюненое до такой степени, что читать код невозможно.
Present Simple - описательное время, можете погуглить в русском - описательные высказывания. Например "солнце светит", "Земля кружится вокруг солнца", "Часы круглые", "Шкаф стоит".
Present Continuous - повествовательное время - "я читаю книгу", "я бегаю", "слон идет". Т.е. какой-то процесс происходит и мы о нем говорим.
Кстати тут вопрос "Часы идут" - это описание или повествование. Можно сказать и так и так. Наверное "Часы ходят" - это описание, а "Часы тикают" - это уже повествование, процесс идет.
Persent Perfect - например тебе дали работу, и ты пункт 1 работы уже сделал, но при этом еще делаешь остальную часть работы.
Т.е. в настоящее время работа делится на ту часть, которую ты уже сделал, и ту часть которую ты еще не сделал.
И чтобы подчеркнуть, что это настоящее время, но часть работы ты уже сделал - говорят не в "прошлом", а "в настоящем, но уже сделанном".
Т.е. "я попил чай", говорит что сегодня (день еще не завершен), в настоящем, я чай УЖЕ попил. Т.е. это настоящее завершенное время. Не вчера, не в прошлом, попил чай, а именно сегодня, действие уже завершилось, в сегодняшнем (что значит сегодняшний - решаешь сам, например рабочий день, или день в школе - это сегодняшнее время, в ней работа есть завершенная уже (о ней говорят в Present Perfect), и еще не завершенная) интервале времени.
Т.е. тебя спросят - ты работу уже выполнил? Я скажу - выполнил пункт 1. Я скажу это в Present Perfect, т.к. рабочий день еще идет, но часть работы уже завершена. И об этой части работы, которая уже завершена - говорят в Present Perfect. А если спросят завтра - то это будет уже прошедшее время - Past какой-то там.
Конкретно говорится что React Elements - это то что можно "потрогать" из реализации Virtual DOM в React. И еще Fibers говорится, но это вроде Internal, как их потрогать я не знаю, постоянно вижу упоминания в исходниках, но наружу вроде они не торчат.
В статье сказано - минимальный. Обычно под минимальной оценкой я понимаю 1 или 2 балла в нашей системе школьных оценок. Слово минимально - обычно ассоциируется с абсолютным значением. "им рекомендовано присвоить минимальный рейтинг 10% сотрудников" - этож каким нелюдем надо быть, чтобы рекоммендовать присваивать минимальный рейтинг даже вполне нормальному человеку. Хотя в оригинале фраза звучит, как найти 10% самых отстающих. Что уже не вызывает такой ненависти. Специально искажают слова? Зачем?
Salesforce asked some managers to rank their lowest 10% of employees.
Т.е. надо выявить 10%-тов самых lowest (не знаю, не продуктивных или самых плохих) сотрудников.
А не присвоить 10%-там сотрудников самый низкий рейтинг. Можно фразу с оригинала, где сказано именно так?
Если данная ошибка перевода сделана специально, то решение - просто перестать верить в кликбейтные заголовки: "Завтра 3-я мировая война". Отличный тест на проверку!
В простых приложениях, например 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 файлу.
аа, спасибо
Все книги с картинки относятся к IT (программирование, devops), а ссылку на IT не проставили. Только отдельные издательства. А ссылки на подборку с книгами с картинки - нету. Хотя заманивают то в основном книги с картинки.
del
Pyypl не принимает российский паспорт.
Не совсем. Дело в том, что в тестах techempower, который показывает самый производительный Web фреймворк используется не коробочное решение, а максимально затюненое решение. Затюненое до такой степени, что читать код невозможно.
Был статья на хабре об этом.
https://habr.com/ru/post/701352/
Т.е. в реальной жизни все так - именно в классической парадигме.
https://www.techempower.com/benchmarks/
Present Simple - описательное время, можете погуглить в русском - описательные высказывания. Например "солнце светит", "Земля кружится вокруг солнца", "Часы круглые", "Шкаф стоит".
Present Continuous - повествовательное время - "я читаю книгу", "я бегаю", "слон идет". Т.е. какой-то процесс происходит и мы о нем говорим.
Кстати тут вопрос "Часы идут" - это описание или повествование. Можно сказать и так и так. Наверное "Часы ходят" - это описание, а "Часы тикают" - это уже повествование, процесс идет.
Persent Perfect - например тебе дали работу, и ты пункт 1 работы уже сделал, но при этом еще делаешь остальную часть работы.
Т.е. в настоящее время работа делится на ту часть, которую ты уже сделал, и ту часть которую ты еще не сделал.
И чтобы подчеркнуть, что это настоящее время, но часть работы ты уже сделал - говорят не в "прошлом", а "в настоящем, но уже сделанном".
Т.е. "я попил чай", говорит что сегодня (день еще не завершен), в настоящем, я чай УЖЕ попил. Т.е. это настоящее завершенное время. Не вчера, не в прошлом, попил чай, а именно сегодня, действие уже завершилось, в сегодняшнем (что значит сегодняшний - решаешь сам, например рабочий день, или день в школе - это сегодняшнее время, в ней работа есть завершенная уже (о ней говорят в Present Perfect), и еще не завершенная) интервале времени.
Т.е. тебя спросят - ты работу уже выполнил? Я скажу - выполнил пункт 1. Я скажу это в Present Perfect, т.к. рабочий день еще идет, но часть работы уже завершена. И об этой части работы, которая уже завершена - говорят в Present Perfect. А если спросят завтра - то это будет уже прошедшее время - Past какой-то там.
Кто знает что там с Present Perfect Continuous?
Документация с вами не согласна: https://reactjs.org/docs/faq-internals.html
Конкретно говорится что React Elements - это то что можно "потрогать" из реализации Virtual DOM в React. И еще Fibers говорится, но это вроде Internal, как их потрогать я не знаю, постоянно вижу упоминания в исходниках, но наружу вроде они не торчат.
В статье сказано - минимальный. Обычно под минимальной оценкой я понимаю 1 или 2 балла в нашей системе школьных оценок. Слово минимально - обычно ассоциируется с абсолютным значением. "им рекомендовано присвоить минимальный рейтинг 10% сотрудников" - этож каким нелюдем надо быть, чтобы рекоммендовать присваивать минимальный рейтинг даже вполне нормальному человеку. Хотя в оригинале фраза звучит, как найти 10% самых отстающих. Что уже не вызывает такой ненависти. Специально искажают слова? Зачем?
Salesforce asked some managers to rank their lowest 10% of employees.
Т.е. надо выявить 10%-тов самых lowest (не знаю, не продуктивных или самых плохих) сотрудников.
А не присвоить 10%-там сотрудников самый низкий рейтинг. Можно фразу с оригинала, где сказано именно так?
Если данная ошибка перевода сделана специально, то решение - просто перестать верить в кликбейтные заголовки: "Завтра 3-я мировая война". Отличный тест на проверку!