Абсолютно согласен на счет Duration. Пример можно было подобрать получше, так как в нашем случае за заполнение объекта класса конфиг отвечает Spring и он умеет работать с Duration
В моем продукте внешних тестов не очень много так как наружу торчит только API. Предположим что мы не пишем через BDD а для этого есть отдельный человек. 98% времени он будет заниматься ничем в продукте. При этом совсем без внешних тестов нельзя. А шарить одного тестера на 5-10 продуктов - он не будет хорошо разбираться сразу во всех продуктах чтобы прийти и написать нам сразу в спринт пару тестов
Аналогичная ситуация в моем продукте с фронтом - его очень мало. Пару платежных страниц и админок в которых редко кто мало что правит
Выглядит как безапелляционное заявление, а не обсуждение. Если я все же ошибаюсь, то:
Конкретно в моем проекте T-Shape не работает. Но работает в соседнем https://habr.com/ru/company/qiwi/blog/699696/ - там не было буржуя который всех уволил и команды сверху. Мотивация была от самой команды
Мда. Я надеялся что статья будет про варианты использования и технологические сложности... А тут просто про что все больше ДЦ используются для нагрева чего-то
Мне кажется что первое правило копипасты надо разделить на 2 правила. Первое правило - это понимать как работает то, что ты копируешь. Второе - дублирование кода
И вот к дублированию как невероятному злу у меня большая претензия:
Во-первых я постоянно вижу разработчиков которые считают дублирование самым плохим, что может быть в программировании.
Во вторых бывает "правильное дублирование". Дядя боб, на которого есть ссылка в начале статьи часто об этом пишет. То есть код совпал случайно - и не нужно делать наследование или композицию в таком случае
В третьих если код написан через TDD и хорошечно покрыт интеграционными тестами - то ошибка если забыл исправить во втором месте не сильно вероятна
В теории понятно что это за принцип. Но давайте рассмотрим на практике. У нас есть класс платеж, которому мы можем сказать - отменись. Кроме изменения собственного статуса отмена платежа должна создать еще один обьект - обьект отмены.
class Payment {
fun reverse()
}
И тогда получается что либо tell don't ask метод reverse должен возвращать что-то, нарушая Command Query Separation, либо сам payment и reversal должны уметь себя куда-то сохранять - то есть получать интерфейс репозитория, что нарушает Single Responsability Principle.
Я попытался найти упоминания слова топология в части IT и выходит только топология сетей. А как назвать когда люди начинают определять что тут будет монга - тут оракл, а тут кафка? В противовес слову архитектура какое слово больше всего подходит? Системный дизайн?
Огромное спасибо за эту фразу. А то меня каждый раз спрашивают коллеги когда мы "делаем архитектуру" - если это не архитектура - то что же мы делаем... "Архитектура — это не количество серверов и схема их расположения (это топология)."
Добрый день! Мне кажется что в чистом коде Дядя Боб по касательной упоминает про SOLID - а не "Автор уделил много внимания принципам solid". Я книгу давно читал но недавно пересматривал видео лекции. Чистый код это в основном про "Read like a well written poem"
Абсолютно согласен на счет Duration. Пример можно было подобрать получше, так как в нашем случае за заполнение объекта класса конфиг отвечает Spring и он умеет работать с Duration
Наверно, в переводе с английского да. Цвет - Зеленый. Тип топлива - бензиновый. Статус движения - едущий.
По русски так и не додумался как это написать. Бывают прилагательные (зеленый), а тип топлива просто - бензин.
Может быть у вас есть лучшие варианты и я поправлю статью?
Согласен, что тема не новая. Но раз за разом натыкаюсь на то, что новые разработчики не слышали об этом. А кто-то даже считает что это не нужно.
Примеры нарушения / исправления свои. Может быть она покажутся кому-то менее искусственными, чем в книге.
Кроме того, обычно конспекты делают по книге. Тут конспект сделан по лекциям на англ языке. Различается структура разделов и некоторые правила.
Все верно
И еще вопрос - есть ли статистика по мошенничествам с картами по странам?
А есть какие-то примеры со статистикой - как отличаются платежные рынки других стран? Например:
Большинство платежей в Индонезии проходит без 3ds (потому что отсталые эмитенты не поддерживают эту технологию)
В Китае / ЮВА большинство платежей проходит через WeChat или мобильные кошельки. В США большинство карт бесчиповых
В центральной африке мобильные платежи превышают количество платежей по картам и наличные оборот
В моем продукте внешних тестов не очень много так как наружу торчит только API. Предположим что мы не пишем через BDD а для этого есть отдельный человек. 98% времени он будет заниматься ничем в продукте. При этом совсем без внешних тестов нельзя. А шарить одного тестера на 5-10 продуктов - он не будет хорошо разбираться сразу во всех продуктах чтобы прийти и написать нам сразу в спринт пару тестов
Аналогичная ситуация в моем продукте с фронтом - его очень мало. Пару платежных страниц и админок в которых редко кто мало что правит
Вопрос был скорее шуточный. Типа - может ли быть менеджер основной компетенцией а backend, android, ios и биг дата как T-Shape
Выглядит как безапелляционное заявление, а не обсуждение. Если я все же ошибаюсь, то:
Конкретно в моем проекте T-Shape не работает. Но работает в соседнем https://habr.com/ru/company/qiwi/blog/699696/ - там не было буржуя который всех уволил и команды сверху. Мотивация была от самой команды
Прочитал половину статьи и понял что кроме технических подробностей не понял зачем это надо...
А где грань T-Shape? Front умеющий в инфраструктуру? Сетевой админ умеющий во фронт? А может быть системный аналитик умеющий в бек?
Почему в одного человека? В одну команду. Ну то есть ты можешь быть T shape специалистом с глубокой экспертизой в тестировании
Мда. Я надеялся что статья будет про варианты использования и технологические сложности... А тут просто про что все больше ДЦ используются для нагрева чего-то
Мне кажется что первое правило копипасты надо разделить на 2 правила. Первое правило - это понимать как работает то, что ты копируешь. Второе - дублирование кода
И вот к дублированию как невероятному злу у меня большая претензия:
Во-первых я постоянно вижу разработчиков которые считают дублирование самым плохим, что может быть в программировании.
Во вторых бывает "правильное дублирование". Дядя боб, на которого есть ссылка в начале статьи часто об этом пишет. То есть код совпал случайно - и не нужно делать наследование или композицию в таком случае
В третьих если код написан через TDD и хорошечно покрыт интеграционными тестами - то ошибка если забыл исправить во втором месте не сильно вероятна
В теории понятно что это за принцип. Но давайте рассмотрим на практике. У нас есть класс платеж, которому мы можем сказать - отменись. Кроме изменения собственного статуса отмена платежа должна создать еще один обьект - обьект отмены.
class Payment {fun reverse()}И тогда получается что либо tell don't ask метод reverse должен возвращать что-то, нарушая Command Query Separation, либо сам payment и reversal должны уметь себя куда-то сохранять - то есть получать интерфейс репозитория, что нарушает Single Responsability Principle.
Как быть с этим?
Я попытался найти упоминания слова топология в части IT и выходит только топология сетей. А как назвать когда люди начинают определять что тут будет монга - тут оракл, а тут кафка? В противовес слову архитектура какое слово больше всего подходит? Системный дизайн?
Вы получаете официальную зарплату? На сколько она сопоставима с зарплатой в коммерческой разработке?
Если НКО становится иноагентом - вы будете там работать? Работа в иноагентской организации накладывает какие-то ограничения на сотрудников?
Огромное спасибо за эту фразу. А то меня каждый раз спрашивают коллеги когда мы "делаем архитектуру" - если это не архитектура - то что же мы делаем... "Архитектура — это не количество серверов и схема их расположения (это топология)."
Добрый день! Мне кажется что в чистом коде Дядя Боб по касательной упоминает про SOLID - а не "Автор уделил много внимания принципам solid". Я книгу давно читал но недавно пересматривал видео лекции. Чистый код это в основном про "Read like a well written poem"
Пример с логированием перс данных не решит контроль ввода