Функциональные интерфейсы, часть 2. Best practices.

В части 1 был обзор функциональных интерфейсов (ФИ), а в этом посте — 4 рекомендации по их использованию.

1️⃣ Не реализуйте ФИ через анонимные классы.
Используйте лямбда-выражения и ссылки на методы. Это короче и понятнее.
✅ Runnable r=() -> …
❌ Runnable r=new Runnable{
@Override
public void run(){…}
}

2️⃣ Определите сценарии использования ФИ.
ФИ — это интерфейс, но с одним абстрактным методом. В него можно добавить сколько угодно методов с реализацией — дефолтных, приватных и статических. Один ФИ может расширять другой ФИ. Класс может реализовать ФИ через implements.

Чтобы код был простым и понятным, нужно разграничивать его компоненты:
🔸Цель обычного интерфейса - обозначить набор методов для будущих классов.
🔸Цель ФИ — передать набор инструкций через лямбды и ссылки на методы.

Один метод в ФИ - оптимальный вариант. Но есть случаи, когда дополнительные методы уместны, так как тесно связаны с самим интерфейсом.
Пример: интерфейс Predicate. Несмотря на то, что он функциональный, в нём есть 4 метода с заданной реализацией: and, or, isEqual и negate.

3️⃣ Используйте аннотацию FunctionalInterface.
Она не обязательна, но облегчает чтение кода.

4️⃣ Если используете ФИ как аргумент, отражайте тип ФИ в названии метода.

Пример: в классе 2 метода с одним именем и разными типами аргументов:

void adapt(Callable)
void adapt(Supplier)

Этот код компилируется, но у него 2 недостатка:
▪️Чтобы понять разницу между методами нужно читать код или документацию.
▪️В качестве аргумента нельзя передать лямбда-выражение, т.к оно подходит под оба типа:

❌ adapt(str->print(str))

Чтобы избежать этих проблем, используйте разные имена для методов. Хороший пример — класс CompletableFuture для многоэтапных вычислений. В его методах легко ориентироваться благодаря удачным названиям:
▫️thenAccept(Consumer)
▫️thenApply(Function)
▫️thenRun(Runnable)

Статический анализ кода, часть 1. Основные метрики

Главная цель принципов разработки и паттернов проектирования — снизить стоимость разработки. Хорошим считается код, который легко:
🔸читать
🔸менять
🔸тестировать
🔸переиспользовать

Простота - субъективное понятие. Разработчику, который в проекте со дня основания, легко ориентироваться в коде и исправлять ошибки. Джуниор, который недавно пришёл и получил первое задание, вряд ли с ним согласится. К счастью, есть объективные показатели качества кода, которые можно отслеживать и анализировать. Их получают с помощью статического анализа на основе исходного и байт-кода. Базовых метрик больше 50, и обычно они группируются в 4 категории:

1️⃣ Связность (Cohesion)
Показывает, насколько сильно внутренние элементы взаимодействуют друг с другом, насколько сфокусирован класс.
В классе с низкой связностью много методов, которые мало взаимодействуют между собой:

class Программист {
   void написатьКод()
   void помытьПосуду()
   void погладитьКота()
}

Идеальная сущность с точки зрения Cohesion - лямбда-выражение. Их легко читать, тестировать и переиспользовать.

2️⃣ Связанность (Coupling)
Показывает, как одна сущность взаимодействует с другими. Класс А связан с классом Б, если в классе А
▫️Поля класса Б
▫️Вызов методов класса Б
▫️Локальные переменные класса Б
▫️Если класс А - подкласс Б

В большинстве проектов есть модуль base или common - часто он является примером сильной связанности. Менять такой модуль - всегда большой риск.

3️⃣ Сложность (Complexity)
На этот показатель влияет:
▪️Сколько сущностей взаимодействуют
▪️Количество операций в методе
▪️Глубина наследования
▪️Количество ветвлений и возможных состояний

Показатель сложности часто идёт рука об руку с размером, но не всегда. Сложный метод может быть небольшим по размеру, но скрывать внутри себя десятки вариантов развития событий:

public void check(long id) {
  dao.get(id).findProcessor()
  .getAccount().checkBalance();
}

4️⃣ Размер (Size)
Большие сущности сложно поддерживать. В этой категории много метрик, например, количество:
🔹Полей
🔹Методов
🔹Статических методов
🔹Подклассов
🔹Связанных библиотек

А теперь ответы на вопросы перед постом:
✅ Если класс А часто использует класс Б, то это признак высокой связанности. Связанность (coupling) характеризует внешние отношения между сущностями. Связность (cohesion) - про внутреннюю структуру самой сущности.
✅ На сложность влияет количество ветвлений и глубина наследования. Остальные характеристики относятся к категории "размер".

Статический анализ кода, часть 2. Инструменты

В части 1 обсудили основные метрики: связность, связанность, сложность и размер. Также статический анализ включает проверку форматирования, поиск уязвимостей и возможных ошибок.

Когда и чем можно выполнять статистический анализ?
1️⃣ Во время написания кода.
С помощью встроенных правил IDE и дополнительных плагинов:
▫️Checkstyle проверяет форматирование, возможные ошибки, показывает сложные классы. Самый популярный плагин для Intellij IDEA.
▫️SonarLint и FindBugs ищут возможные ошибки, уязвимости, проверяют код на несколько тысяч ошибочных паттернов.
▫️CodeMR замеряет атрибуты качества кода — связность, сложность и т.д. Считает метрики, рисует картинки, показывает проблемные места с точки зрения дизайна.
▫️PMD ищет ошибочные паттерны в разных категориях — дизайн, кодстайл, производительность. Не знаю, почему этот плагин попадает во все списки анализаторов, у него достаточно скудный список правил по сравнению с аналогами.

2️⃣ Во время сборки.
Анализ редко делают в процессе сборки, но такая опция доступна — с помощью maven или gradle плагинов: Checkstyle Plugin, PMD Plugin.

3️⃣ На этапах CI/CD.
Можно запускать периодически или после определённых событий: создание пул-реквеста, слияние ветки. Результаты могут иметь рекомендательный характер, а могут не пропускать дальше по CI.

Конкретных инструментов много, как платных, так и бесплатных. Самый популярный - SonarQube. Метрики качества не считает, но проверяет на гигантское количество ошибочных паттернов и интегрируется с плагином в IDE.
JArchitect менее распространён и стоит дороже. Но и функций больше — метрики качества и красивые графики.

Статический анализ проводят в большинстве проектов. Обычно это проверка форматирования и поиск частых ошибок. Конкретные метрики считаются редко. И зря, ведь по ним можно объективно оценить:
🔸Текущее состояние кода
🔸Развитие системы от релиза к релизу
🔸Необходимость рефакторинга
🔸Проблемные места системы

Тестирование, часть 1. Вопросы на собеседовании

Чем опытней разработчик, тем больше тем обсуждается на собеседованиях. Начиная с уровня middle будьте готовы к таким вопросам:

1️⃣ Назовите свойства юнит-тестов?
Хорошие юнит-тесты соблюдают принцип FIRST:

🔸F – Fast
Выполняются быстро. Никто не хочет лишний раз запускать медленные тесты. Один юнит-тест — не дольше 0.5 сек.

🔸I – Isolated / Independent
Любой набор тестов можно запускать в любом порядке, тесты не зависят друг на друга. Каждый тест сфокусирован на одном действии и наборе параметров. Если тест упал, то сразу понятно, где и при каких условиях возникла ошибка.

🔸R – Repeatable
Результат теста не зависит от операционной системы, конфигурации компьютера, внешних ресурсов и наличия интернета. Результат теста повторяется при многократном вызове.
⭐️ Это свойство хромает, когда тесты используют случайные числа или проверяют работу нескольких потоков.

🔸S – Self-Validating
У теста два результата — прошёл или нет. Разработчик не должен проверять записи в логе или сравнивать текстовые файлы.

🔸T - Timely
Тесты пишутся вовремя, в рамках той же задачи, что и основной код.

⭐️ Юнит-тесты должны быть читаемыми. Тогда их легко поменять, если бизнес-логика изменится. Сложно разбираться в методах test1(), test2(), test3() и переменных a, b, c.
⭐️ По тестам можно оценить инженерную культуру компании. Обратите внимание на количество и качество юнит-тестов, кто и когда их пишет. Если тестов нет, или сеньор пишет код и создаёт подзадачу «написать тесты» для джуниора - это дно. Откладывать тесты из-за дедлайна — тоже так себе.
⭐️ Тесты можно не писать для PoC (proof of concept) — временный код для проверки гипотез, который не связан с продакшн кодом.

Тесты организуют по структуре 3A (Arrange-Act-Assert), также встречается название Given-When-Then.

// given

Инициализация переменных и моков.

// when

Вызов проверяемого метода.

// then

Проверка результата и состояния других объектов.

3 блока должны чётко следовать друг за другом, тогда тест легко читать. Если после блока проверок идёт действие и дополнительные проверки — значит тест слишком большой.

2️⃣ Что такое TDD?
Test Driven Development - процесс разработки, когда сначала пишется тест, а потом код. Подробно это выглядит так:
▫️Написать тест для кода, которого нет
▫️Запустить тесты, новый тест падает
▫️Написать код, чтобы тест проходил
▫️Запустить тесты, тесты проходят
▫️Рефакторинг нового кода
▫️Запустить тесты, тесты проходят

Плюсы TDD:
➕Код сразу покрыт тестами
➕У класса удобный интерфейс, который сразу используется в тестах
➕Структурированный код

После этого следует такой диалог:
- А Вы лично используете TDD?
- Нет.
- Почему? У него же столько плюсов.
- Большой минус - частое переключение контекста и фокус на деталях. Мне удобнее написать простое рабочее решение, и только потом добавить проверки, валидацию и обработку ошибок. После этого в соответствии с требованиями как следует оттестировать то, что получилось. Я сразу пишу код, который легко использовать и тестировать, поэтому TDD меня только замедляет.
- Согласен.

​Тестирование, часть 2. Тестовое покрытие

Code coverage (CC) - метрика, которая показывает, насколько код покрыт тестами.

❓Как считается СС?
Запускаются тесты и отслеживается, какие классы, методы и строки кода выполнились. Это число делится на общее количество и так получается процент кода, покрытый тестами.

❓Почему у СС плохая репутация?
❌ Не говорит о качестве тестирования и надёжности системы. Если метод выполнился, это не значит, что он протестирован.
❌ Тестировать get/set методы, конструкторы и классы-конфиги нет необходимости, но из-за жёстких требований по СС приходится писать бесполезные тесты.

❓Зачем считать СС?
✅ Менеджеры хотят быть в курсе состояния проекта и не хотят смотреть в код. Поэтому их главный инструмент - это метрики, в том числе СС. Так оценивается текущая ситуация и сравниваются релизы.
✅ Качество и надёжность— понятия субъективные. С помощью СС и последующего анализа можно найти компоненты, которые слабо покрыты тестами. Таким образом увеличить надёжность системы.

❓Какие значения СС нормальные?
Для большинства проектов это 60-80%.

❓Как посчитать?
1️⃣ Intellij IDEA:
Run → Run with Coverage
По умолчанию IDEA использует свой способ подсчёта, но для java есть ещё 2 библиотеки:
🔸JaCoCo
🔸Emma (не поддерживается с 2013)

Результаты разных библиотек могут отличаться. Если на этапе CI/CD используется JaCoCo, то лучше в IDE тоже использовать JaCoCo. Чтобы поменять:
Run → Edit Configurations... → Code Coverage → Choose coverage runner

2️⃣ Во время сборки.
Те же библиотеки используются в Maven и Gradle плагинах — JaCoCo Plugin, Emma Plugin.

3️⃣ На этапах CI/CD.
JaCoCo Plugin и Emma Plugin доступны для Jenkins, Teamcity, GitLab, Travis и остальных CI серверов.

​Статистика: что использовали Java разработчики в 2019 году

Бостонская компания Snyk каждый год опрашивает разработчиков об их проектах и технологиях. В прошлом году в опросе поучаствовало две тысячи человек, в том числе 8% участников из России.

Главное из отчёта за 2019:
1️⃣ Какая версия java используется в продакшене?
64% — 8
25% — 11
3% — 7 и ниже

2️⃣ Почему Вы не переходите на последнюю версию java?
51% — И так всё устраивает
32% — Трудности с миграцией
30% — Сложно согласовать переход

3️⃣ Какой JVM язык используется в качестве основного?
87% — Java
5,5% — Kotlin
2,9% — Closure
2,6% — Scala
1,5% — Groovy

4️⃣ Вы используете разбиение на модули (фича Java 9)?
64% — Нет
29% — Планируем
7% — Да

5️⃣ Какая у Вас версия Spring в продакшене?
48% — 5.1
18% — 5.0
17% — 4.3
5% — 4.2
4% — 3.2

6️⃣ Какой серверный веб-фреймворк Вы используете?
50% — Spring Boot
31% — Spring MVC
11% — JSF
5% — Vert.x
5% — Vaadin
5% — Struts

7️⃣ Ваша основная IDE:
62% — Intellij IDEA
20% — Eclipse
10% — NetBeans

8️⃣ Ваш инструмент сборки:
64% — Maven
25% — Gradle
6% — Ant

9️⃣ Ваш CI-сервер:
58% — Jenkins
12% — Никакой
6% — GitLab
5% — TeamCity
4% — Bamboo
4% — Travis
4%— Circle

🔟 Ваш репозиторий:
24% — private GitLab
16% — public GitHub
15% — Enterprise GitHub
15% — BitBucket Server
11% — public GitLab
10% — BitBucket Cloud

Полная версия отчёта тут. Очень удивило, что 12% не используют CI, и что Closure обогнал Scala. Рост популярности Intellij IDEA по сравнению с прошлым годом тоже впечатляет:

​WakaTime: лёгкий способ прокачать навык эстимации

Секрет успеха прост — составить план и придерживаться его. Задача разработчика при планировании - оценить время на задачу с учётом сложности и рисков. Точные прогнозы это плюс к репутации, сорванные сроки — минус.

Навык оценки легко тренировать - почаще сравнивать оценку и фактическое время выполнения. Со временем у вас разовьётся сильная интуиция и адекватная оценка своих способностей. Приятный бонус - любовь менеджеров и низкий уровень стресса😌

Самое сложное — посчитать, сколько времени по факту ушло на задачу. Можно полагаться на память, а можно трекать время автоматически. Самый популярный плагин Intellij IDEA для Git — WakaTime. В бесплатной версии недоступно почти всё, но можно смотреть:
🔸Сколько времени ушло на написание кода
🔸Сколько времени заняла каждая задача:

5h 6 mins feature/EX-45
  50 mins bugfix/EX-64

Для мониторинга своей активности этого достаточно.

Полная инструкция:
1️⃣ Установить в IDEA плагин WakaTime
2️⃣ Перезапустить IDEA, появится окошко для ключа
3️⃣ Зарегистрироваться на сайте и перейти в раздел для IDEA
4️⃣ Взять из п.5 API Key, ввести его в IDE
5️⃣ Зайти в настройки, отключить все уведомления
6️⃣ Зайти в дашборд

Можно трекать работу в других IDE и редакторах — Eclipse, Android Studio, GoLand, даже в Notepad++. Можно подключить к GitLab, GitHub и BitBucket и смотреть, сколько времени занял каждый коммит.

Привет!

Сегодня будет не полезный пост, а небольшая просьба. Я пишу посты в этом канале уже 5 месяцев: делюсь знаниями, инструментами и аналитикой, стараюсь доступно передать свой 7-летний опыт java разработки.

Постоянная обратная связь мотивирует писать дальше: меня очень радуют ваши лайки, шеры и личные сообщения. Приятно, что вы цените точную и практическую информацию и мой труд🧡

Я уже несколько месяцев занимаюсь созданием курса по многопоточности в java. В нём будет:
▫️Необходимая теоретическая часть
▫️Как и какими инструментами решать конкретные задачи
▫️Что актуально сейчас и тренды ближайших лет
▫️Разбор вопросов с собеседований

Большая часть материалов готова, но я хочу убедиться, что раскрыла все важные и интересные темы. Поэтому прошу вас мне помочь и заполнить небольшую анкету:
https://docs.google.com/forms/d/10zfRjnM6Fbpr03LWbNRETQDl3SNd7kjGmVh7Rh2XFRY/edit?usp=sharing

Ребята, спасибо, что уделили время заполнению анкеты! Я получила больше сотни ответов и ценных идей, буду внедрять💪
Многие писали, что присоединились недавно, поэтому на этой неделе будут подборки самых популярных статей. Если что-то пропустили — рекомендую прочесть.

Подборка: подготовка к собеседованиям

🔥Рейтинг технологий в вакансиях HeadHunter🔥

Вопросы с собеседований:
▫️Сравнение переменных
▫️Как создать поток: 7 вариантов ответа
▫️Интерфейсы: поля и методы
▫️Интерфейсы: отличия от абстрактного класса
▫️Вопросы про юнит-тесты

Подборка: Java core и Java 8

⚙️Java core:
▫️Сборщики мусора. Плюсы и минусы G1
▫️Как работает переопределение методов?
▫️2 способа обхода коллекций
▫️Система типов и проверка аргументов

👑 Java 8:
▪️Stream API: обзор и основные методы
▪️Stream API: ускоряемся🚀
▪️HashMap в Java 8
▪️Функциональные интерфейсы: обзор
▪️Функциональные интерфейсы: best practices

Как JVM работает со строками, часть 1

По статистике OpenJDK в приложениях 15-50% памяти занимают экземпляры String. Это много, поэтому разработчики JVM прикладывают много усилий, чтобы оптимизировать работу со строками.

❓Как сэкономить память, если в системе миллионы экземпляров?

1️⃣ Уменьшить количество памяти под одну строку.

Мы уже разбирали этот случай: в java 9 вышло обновление Compact String и размер памяти под строки сократился до 2 раз.

2️⃣ Добавить кэширование.

Есть два способа создать экземпляр String:
🔸Через оператор new:

String s = new String ("one");

В памяти создаётся новый объект.

🔸Без оператора new:

String s = "one";

В этом случае идёт работа с кэшем строк под названием String pool. Схема работы такая:
▫️Проверить в String Pool, есть ли там такая строка.
▫️Если есть — вернуть её.
▫️Если нет — создать объект, поместить в кэш, вернуть.

❓Как реализован String pool?
Структура похожа на HashMap: хэш-таблица фиксированного размера с парами хэш — строка. В последних версиях java она занимает 64 МБ, при желании размер меняется с помощью флажка:

-XX:StringTableSize=65536

В следующем посте рассмотрим ещё два способа снижения издержек на строки.

✅ Ответ на 1 вопрос перед постом:
new String("Java") создаёт новый объект в хипе,
s2 = "Java" создаёт объект в String pool. Это два разных объекта, поэтому при сравнении через == результат будет false.

Можно исправить ситуацию и добавить строчку в кэш методом intern():

String s1="Java";
String s2=new String("Java");
s2=s2.intern();
println(s1==s2); //true

✅Рассмотрим второй вопрос. О том, сколько строк создаётся в конструкции

String str=new String("Java");

Подвох в том, что для конструктора String нужен экземпляр String, поэтому создаётся 2 строки — "Java" и new String;

Но если строка "Java" использовалась раньше и попала в кэш, то будет создана только одна строка — new String.