С утилитками есть проблема, их нужно устанавливать на конкретное окружение CI/CD. С плагином для Gradle ничего устанавливать не нужно, получается что утилита генерации changelog встроена в систему сборки.
Разработчики языка Kotlin, сделали классы по умолчанию — final. И это было сделано не просто так. На мой взгляд, лучше придерживаться агрегации, композиции при расширении функционала какого-то класса, нежели наследования. Поэтому, хорошей практикой является закрытие класса на расширение через final, а если нужно расширить — то можно прибегнуть к паттерну "декоратор", но этот паттерн уже подразумевает выделение интерфейса для класса.
Представь ситуацию, когда <что-то с весьма незначительной вероятностью>
Я привел весьма распространенную ситуацию, и это действительно, считается антипатерном — мокать конкретные реализации. Конкретная реализация может быть не вашим кодом, а сторонней библиотекой, например, или это может быть код, за который ответственна другая команда в проекте. Что бы избежать этих проблем — лучше скрыть конкретную реализацию за интерфейсом и придерживаться контрактов в реализации этого интерфейса.
Результат непосредственно зависит от архитектуры, а разработка по сути стандартна
В статье как раз говорится про разработчиков, которые в принципе не сталкивались с таким процессом разработки, в котором есть автоматизированный pipeline со статическими анализаторами, тестами, quality gates, и пр. На моей практике, я очень редко встречал android проекты, которые попали мне из других рук, и где был бы написан хотя бы один тест. И эти проекты, в принципе, не пригодны к автоматическим тестам. Если бы, в таких проектах было бы требование покрытия кода тестами, их архитектура однозначно бы изменилась в сторону усложнения.
Т.е. требования к процессу разработки — реально влияют на то, какой будет архитектура проекта.
С утилитками есть проблема, их нужно устанавливать на конкретное окружение CI/CD. С плагином для Gradle ничего устанавливать не нужно, получается что утилита генерации changelog встроена в систему сборки.
Разработчики языка Kotlin, сделали классы по умолчанию —
final. И это было сделано не просто так. На мой взгляд, лучше придерживаться агрегации, композиции при расширении функционала какого-то класса, нежели наследования. Поэтому, хорошей практикой является закрытие класса на расширение черезfinal, а если нужно расширить — то можно прибегнуть к паттерну "декоратор", но этот паттерн уже подразумевает выделение интерфейса для класса.Я привел весьма распространенную ситуацию, и это действительно, считается антипатерном — мокать конкретные реализации. Конкретная реализация может быть не вашим кодом, а сторонней библиотекой, например, или это может быть код, за который ответственна другая команда в проекте. Что бы избежать этих проблем — лучше скрыть конкретную реализацию за интерфейсом и придерживаться контрактов в реализации этого интерфейса.
Представьте что
SomeApi—finalкласс, такой метод уже замокать не получится. Ну и это считается дурным тоном — мокать конкретные реализации.В статье как раз говорится про разработчиков, которые в принципе не сталкивались с таким процессом разработки, в котором есть автоматизированный pipeline со статическими анализаторами, тестами, quality gates, и пр. На моей практике, я очень редко встречал android проекты, которые попали мне из других рук, и где был бы написан хотя бы один тест. И эти проекты, в принципе, не пригодны к автоматическим тестам. Если бы, в таких проектах было бы требование покрытия кода тестами, их архитектура однозначно бы изменилась в сторону усложнения.
Т.е. требования к процессу разработки — реально влияют на то, какой будет архитектура проекта.