Чтобы добавлять сообщения и комментарии, .

@mismatch:
mismatch

3 закона TDD от дяди Боба — интересно, а где же в них место рефакторингу и почему дядя Боб взялся рефакторить на 40-й минуте, а потом дописал тест на отрефакторенный код?

@mismatch:
mismatch

The Secrets of Concurrency — доклад от Heinz Kabutz

@mismatch:
mismatch

The deep synergy between testability and good design — еще один доклад от Майкла Физерса. И начинает он с того, что проблемы с тестированием кода сигнализируют о проблемах с дизайном этого кода. Например, если у вас возникает желание протестировать приватные методы класса, скорее всего он делает слишком много и не следует принципу единственной ответственности. Некоторых разработчиков смущает то, что следование этому принципу приводит к появлению большого количества небольших классов. Но так ли это плохо? Да, в определенных случаях вам придется походить по файлам, чтобы разобраться как работает некоторая функциональность. Но это разделение упрощает поддержку кода. В большинстве случаев вам будет достаточно заменить один из этих небольших классов или добавить еще один небольшой класс вместо того, чтобы менять один большой и беспокоиться не сломали ли вы существующую функциональность.
Далее Майкл задается вопросом: а что же затрудняет тестирование кода?
1. Спрятанное в методе состояние — у вас длинный метод с многими локальными переменными и вы хотите протестировать работу этого метода при различных комбинациях значений этих переменных
2. Сложная система — класс с многими зависимостями, необходимыми для его создания
3. Неполное выключение — например, не освобождаются ресурсы или не переводятся в нужное состояние. В этом случае появится зависимость между тестами и они начнут падать, сигнализируя об имеющейся проблеме.
4. Состояние перетекает из одного теста в другой — например, статическая изменяемая переменная или синглтоны
5. Наличие фреймворка — если фреймворк затрудняет тестирование, то вы недостаточно разделили фреймворк и предметную область
6. Сложности с моками — не нарушаете ли вы закон Деметра?
7. Скрытые эффекты
8. Скрытые входные данные — возможно вы перестарались с инкапсуляцией
9. Громоздкий список параметров метода — нарушение принципа единственной ответственности
10. Недоступность метода — этот случай рассмотрен в самом начале
11. Круговерть тестов — при изменении кода меняется много тестов — вы нарушаете принцип открытости/закрытости

@mismatch:
mismatch

Escaping the Technical Debt Cycle — Michael Feathers говорит о том, что важно концентрироваться не на количественных метриках, а на качественных. Не все можно измерить (попробуйте, подсчитать кол-во нарушений принципа подстановки Лисков в коде) и то, что вы измеряете и контролируете, не должно заменять здравого смысла. Важно не то, насколько красивые показатели у вашего кода, а то, насколько легко адаптировать его к изменяющимся требованиям. Исходя из этого Майкл определяет технический долг, как затраты на рефакторинг, после которого добавление новой функциональности будет безболезненным. Для оценки технического долга он предлагает использовать feature trend cards: напишите на карточках несколько воображаемых фич (не связанных с текущими задачами) и оцените время, необходимое для их добавления. Делайте это периодически и вы будете представлять размер долга. Второе предложение от Майкла — выделяйте подготовительный рефакторинг, необходимый для добавления новой функциональности, в отдельную задачу. Далее поручите выполнение этой задачи одним разработчикам, а добавление функциональности — другим. Такое разделение способствует общению между двумя группами и подчеркивает важность подготовительного рефакторинга. Но это разделение также имеет свою цену и не стоит проводить его регулярно.
Во второй части доклада Майкл задается вопросом: откуда же берется технический долг? Одной из причин он называет недостаточную прозрачность для бизнеса процесса разработки и недостаток понимания влияния желаемых изменений на существующую функциональность. Второй причиной он называет недостаток понимания качества текущего дизайна кода — насколько он хорош или плох.

@mismatch:
mismatch

martinfowler.com — готовы ли вы к сертификации по непрерывной интеграции?

@mismatch:
mismatch

Audi и светофоры — и почему этого раньше не сделали?

@mismatch:
mismatch

LinkedHashMap для LRU-кэша на коленке. Наткнулся здесь, а потом и в JavaDoc это нашел. Идея не новая, но всегда полезно вспомнить базовые вещи.
На практике я использовал CacheBuilder из Guava, а еще советуют Caffeine (но там, как я понял, другой алгоритм вытеснения элементов из кэша).

@mismatch:
mismatch

Может ли TreeSet содержать дубликаты? Не спешите с ответом, а лучше почитайте этот пост.

@mismatch:
mismatch

В The Myth of the Root Cause: How Complex Web Systems Fail и Each necessary, but only jointly sufficient пишут о том, что при анализе падения, выхода из строя сложной системы не следует искать единую корневую причину. Анализируя произошедшее падение постфактум нам свойственно выделять одни события и недооценивать другие, а также неправильно выстраивать их во времени, путая причину и следствие. Также, когда объяснение требуют как можно скорее, нам свойственно упрощать и не докапываться до истинных причин. Нахождение единственной причины падения сложной системы сравнивают с поиском единственной причины успеха человека / бизнеса. На самом деле причин много, но каждая из них по отдельности не является достаточной, а только некоторая их комбинация. Надо перестать воспринимать сложную систему как линейную, а в нелинейной системе, как известно, даже небольшие отклонения значений ее параметров могут приводить к существенным изменениям всей системы. Утверждается, что сложную систему следует считать сломанной по умолчанию.
Опасность сведения падения системы к единственной корневой причине заключается еще и в том, что по результатам анализа обычно принимаются меры по недопущению предполагаемой причины повторно, которые сами по себе могут стать причиной следующего падения.

@mismatch:
mismatch

On the criteria for decomposing systems into microservices — мудрость веков, собранная в одной презентации. Особенно полезно для молодых и юных, воспринимающих микросервисы как непаханое поле, где царит анархия :)

@mismatch:
mismatch

More unit tests? No! What your code needs is petrol and a match. — развлечение для JS разработчиков.

@mismatch:
mismatch

Thinking In Parallel — а нужно ли распараллеливать решение задачи? Всегда ли это уменьшает время решения? Вопрос распараллеливания — это вопрос оптимизации. Об этом и не только говорит Brian Goetz в этом видео.

@mismatch:
mismatch

youtube.com — !адекватное Java — интервью!

@mismatch:
mismatch

youtu.be — для тех, кто пишет многопоточные программы и использует разделяемое изменяемое состояние, но еще не в курсе, чем это может обернуться.

@mismatch:
mismatch

habrahabr.ru — отличный юмор для тех, кто понимает ;)

@mismatch:
mismatch

vimeo.com — неплохое систематизированное введение в RxJava для тех, кто потерялся в документации

@mismatch:
mismatch

somethingsimilar.com — Notes on Distributed Systems for Young Bloods

@mismatch:
mismatch

habrahabr.ru — «Красота» кода — зло! Никогда не называйте код «красивым», даже мысленно. Самый изощрённый говнокод получается из стремления «сделать красиво». Код может быть читаемым, предсказуемым, лаконичным — но никак не красивым!

Что тут скажешь? Сердцу не прикажешь :) Смотришь на один код и умиляешься, а от другого плеваться хочется. И в этот момент не раскладываешь код по полочкам. Это уже, когда джуну объясняешь, что такое хорошо и что такое плохо.

Но, конечно, я не спорю, что "Самый изощрённый говнокод получается из стремления «сделать красиво»", потому что никто не отменял «хотели как лучше, а получилось как всегда». И, конечно, рефакторинг не должен превращаться в лоботомию. Поэтому сплюнули, включили мозги и принялись за работу.

@mismatch:
mismatch

youtu.be — введение в Kafka Streams

@mismatch:
mismatch

youtu.be — Perfect Scalability (by Michael Nash). При идеальной масштабируемости чем больше добавляем ресурсов тем большую нагрузку система может выдержать и эта зависимость линейная. Избегайте разделяемого состояния и соревнования за доступ к нему (за счет дублирования данных). Не полагайтесь на порядок операций (сделайте их идемпотентными). Минимизируйте общение между компонентами вашей системы, отдавайте предпочтение асинхронному взаимодействию. Разрабатывайте компоненты так, чтобы падение одного из них не приводило к падению всей системы. Масштабируемая система должна быть децентрализованной и постоянно развиваться пока функционирует. Применяйте command sourcing, чтобы справиться с пиковыми нагрузками, — принимайте и запоминайте комманды сразу, применяйте, когда есть свободные ресурсы. Сложные системы плохо масштабируются.