Всем привет!

И "последняя серия" про convention over configuration.
Я уже говорил, чем данный принцип полезен разработчику. Но можно посмотреть чуть шире.

1) с настройками приложения работают люди, не относящиеся к команде - тестировщики, DevOps-инженеры (да, они не должны этим заниматься, но ...), сопровождение ПРОМ. И у них будут похожие проблемы:
а) слишком много настроек
б) не понятно, что важно
в) не понятно, у всех одинаковые настройки (скопированные из каркаса) или у кого-то есть особенности, требующие внимания. По-хорошему, все должно быть описано в документации к релизу, но случается всякое)

2) для разработчика библиотеки или сервиса вывалить на пользователей сотню настроек, давая им возможность настроить "под себя" - самый простой, но не самый правильный вариант. Даже если ко всем настройкам есть подробная документация, но как я уже написал выше - случается всякое) Правильный подход - подумать, как этим сервисом будут пользоваться. Это на самом деле проблема. Не для всех, open sourse библиотека, которую неудобно использовать, скорее всего не пройдет "естественный отбор". А вот в "кровавом enterprise" проблема проявляется во всей красе. Не всегда пользователи могут отказаться от использования какой-то части платформы. Так вот, чтобы понять оптимальные настройки по умолчанию - надо поставить себя на место пользователя. Или собрать обратную связь, или пользоваться своим продуктом. Т.е. convention over configuration способствует движению в правильном направлении