Всем привет!
Читаю сейчас книжку "Release it! Проектирование и дизайн для тех, кому не все равно". Несмотря на то, что книге 15 лет, полезного много.
Сегодня хочу поднять одну интересную мысль:
файлы конфигурации для сопровождения - это как UI или API для пользователей приложения. Но если UI проектирует дизайнер, API тоже проектируют, ну я на это надеюсь по крайней мере), то на файлы конфигурации часто забивают.
А это риски для ПРОМа.
Что нужно делать:
1) Infrastructure As Code - хранить конфигурацию в git
2) разделять стендозависимую и постоянную конфигурацию, чтобы случайно не поменять что-то важное для корректной работы сервиса. Также имеет смысл разделить настройки для разных компонентов системы, пользовательские и настройки стенда.
3) убрать дублирование, все тот же принцип DRY - Don't Repeat Yourself
4) не забывать чистить конфигурацию от неиспользуемых параметров
5) наименование параметров должно отвечать на вопрос "зачем", а не "что"
6) нужен инструмент для сравнения конфигураций - на разных стендах, в дистрибутиве и на стенде.
Про книжку напишу подробнее.
#configuration #support #devops
Читаю сейчас книжку "Release it! Проектирование и дизайн для тех, кому не все равно". Несмотря на то, что книге 15 лет, полезного много.
Сегодня хочу поднять одну интересную мысль:
файлы конфигурации для сопровождения - это как UI или API для пользователей приложения. Но если UI проектирует дизайнер, API тоже проектируют, ну я на это надеюсь по крайней мере), то на файлы конфигурации часто забивают.
А это риски для ПРОМа.
Что нужно делать:
1) Infrastructure As Code - хранить конфигурацию в git
2) разделять стендозависимую и постоянную конфигурацию, чтобы случайно не поменять что-то важное для корректной работы сервиса. Также имеет смысл разделить настройки для разных компонентов системы, пользовательские и настройки стенда.
3) убрать дублирование, все тот же принцип DRY - Don't Repeat Yourself
4) не забывать чистить конфигурацию от неиспользуемых параметров
5) наименование параметров должно отвечать на вопрос "зачем", а не "что"
6) нужен инструмент для сравнения конфигураций - на разных стендах, в дистрибутиве и на стенде.
Про книжку напишу подробнее.
#configuration #support #devops
Всем привет!
Я часто вижу в проектах лишние настройки. Как правило, они попадают в проект следующими путями:
1) скопировали из каркаса\образца\соседнего сервиса не задумываясь - нужны эти настройки или нет. Да, принцип "работает - не трогай" встречается и у разработчиков)
2) решили явно прописать какие-то настройки, так сказать для надежности
Я считаю, что так делать не надо. Почему?
1) лишние настройки раскрывают нам лишние детали, которые или не нужны вообще, или нужны, но не сейчас. Повышается когнитивная сложность кода. Знать все детали своего сервиса - это хороший подход, был, лет 10-20 назад. Сейчас ПО очень сильно развилось в плане специализации, количество зависимостей среднего проекта - несколько сотен, поэтому знать все детали просто невозможно.
2) следствие из сказанного выше - ухудшается читаемость кода. Да, это моя любимая тема. Мы чаще читаем код, чем пишем. Настройки тоже часть кода.
3) среди скопированных настроек могут быть не нужные в данный момент. Код легко меняется, ТЗ меняется также легко, поэтому добавлять что-то "на вырост" не стоит
4) портянка настроек, в которую что-то постоянно добавляется, может превратится в некий аналог "большого кома грязи", который будут боятся трогать. Как разработчики, так и сопровождение. Чтобы этого не допускать - настройки нужно чистить. Чтобы меньше было чистить - не нужно добавлять лишнее. Как-то так)
А вообще есть такой хороший принцип, описывающий то, что я хочу сказать: convention over configuration. Тоже одна из моих любимых тем. Принцип говорит о том, что должны быть некие настройки по умолчанию, устраивающие большинство потребителей. Эти настройки потребитель не задает, они заданы где-то внутри сервера или библиотеки.
#clean_code #configuration #conv_over_conf
Я часто вижу в проектах лишние настройки. Как правило, они попадают в проект следующими путями:
1) скопировали из каркаса\образца\соседнего сервиса не задумываясь - нужны эти настройки или нет. Да, принцип "работает - не трогай" встречается и у разработчиков)
2) решили явно прописать какие-то настройки, так сказать для надежности
Я считаю, что так делать не надо. Почему?
1) лишние настройки раскрывают нам лишние детали, которые или не нужны вообще, или нужны, но не сейчас. Повышается когнитивная сложность кода. Знать все детали своего сервиса - это хороший подход, был, лет 10-20 назад. Сейчас ПО очень сильно развилось в плане специализации, количество зависимостей среднего проекта - несколько сотен, поэтому знать все детали просто невозможно.
2) следствие из сказанного выше - ухудшается читаемость кода. Да, это моя любимая тема. Мы чаще читаем код, чем пишем. Настройки тоже часть кода.
3) среди скопированных настроек могут быть не нужные в данный момент. Код легко меняется, ТЗ меняется также легко, поэтому добавлять что-то "на вырост" не стоит
4) портянка настроек, в которую что-то постоянно добавляется, может превратится в некий аналог "большого кома грязи", который будут боятся трогать. Как разработчики, так и сопровождение. Чтобы этого не допускать - настройки нужно чистить. Чтобы меньше было чистить - не нужно добавлять лишнее. Как-то так)
А вообще есть такой хороший принцип, описывающий то, что я хочу сказать: convention over configuration. Тоже одна из моих любимых тем. Принцип говорит о том, что должны быть некие настройки по умолчанию, устраивающие большинство потребителей. Эти настройки потребитель не задает, они заданы где-то внутри сервера или библиотеки.
#clean_code #configuration #conv_over_conf
Всем привет!
Снова попробую сам с собой поспорить ... санитары, ау ... так ли хорош принцип convention over configuration.
1) Первое возражение я уже упомянул в предыдущем посте. А как же полный контроль над настройками проекта? Мало ли что там в значениях по умолчанию.
Ответ: при текущей модульности и сложности ПО - это видимость контроля. Невозможно вынести все настройки в один файл. А даже если и возможно - как потом с этим работать?
С другой стороны достаточный набор модульных и регрессионных тестов плюс нагрузочное тестирование дает некую уверенность, что все настроено верно. А тесты нужны в любом случае.
2) Если система прячет от нас настройки - она менее гибка, и в нестандартном use case ее придется настраивать "через одно место". И это в самом деле важный момент. convention over configuration не означает, что разработчик компонента спрятал все настройки в "черный ящик". Это неправильный convention over configuration. Правильный - разработчик продумал некие настройки по умолчанию, удовлетворяющие основные use cases, но оставил возможность подтюнить при необходимости.
Это может быть application.yaml в Spring Boot, код на Kotlin или Groovy DSL в Gradle или даже написание плагина в Maven. Последний кейс может показаться антипримером - настроить что-то под себя достаточно сложно. Кто-нибудь делал свой Maven плагин?) Но как раз за это многие и любят Maven - сделать из скрипта сборки "большой ком грязи" на Maven гораздо сложнее, чем в том же Gradle. Так что кажется, что и такой вариант допустим.
#conv_over_conf #configuration
Снова попробую сам с собой поспорить ... санитары, ау ... так ли хорош принцип convention over configuration.
1) Первое возражение я уже упомянул в предыдущем посте. А как же полный контроль над настройками проекта? Мало ли что там в значениях по умолчанию.
Ответ: при текущей модульности и сложности ПО - это видимость контроля. Невозможно вынести все настройки в один файл. А даже если и возможно - как потом с этим работать?
С другой стороны достаточный набор модульных и регрессионных тестов плюс нагрузочное тестирование дает некую уверенность, что все настроено верно. А тесты нужны в любом случае.
2) Если система прячет от нас настройки - она менее гибка, и в нестандартном use case ее придется настраивать "через одно место". И это в самом деле важный момент. convention over configuration не означает, что разработчик компонента спрятал все настройки в "черный ящик". Это неправильный convention over configuration. Правильный - разработчик продумал некие настройки по умолчанию, удовлетворяющие основные use cases, но оставил возможность подтюнить при необходимости.
Это может быть application.yaml в Spring Boot, код на Kotlin или Groovy DSL в Gradle или даже написание плагина в Maven. Последний кейс может показаться антипримером - настроить что-то под себя достаточно сложно. Кто-нибудь делал свой Maven плагин?) Но как раз за это многие и любят Maven - сделать из скрипта сборки "большой ком грязи" на Maven гораздо сложнее, чем в том же Gradle. Так что кажется, что и такой вариант допустим.
#conv_over_conf #configuration
Всем привет!
И "последняя серия" про convention over configuration.
Я уже говорил, почему стоит придерживаться данного принципа разработчику и команде в целом. Но можно посмотреть чуть шире.
1) с настройками приложения могут работать люди, не относящиеся к команде - тестировщики, DevOps-инженеры (да, они не должны этим заниматься, но занимаются), сопровождение ПРОМ. И у них будут похожие проблемы:
а) слишком много настроек
б) не понятно, что важно, что нет
в) не понятно, у всех одинаковые настройки (скопированные из каркаса) или у кого-то есть особенности, требующие, чтобы на них обратили внимание. По-хорошему, все это должно быть описано в документации к релизу, но случается всякое)
2) если ты разработчик какой-то библиотеки или сервиса, то вывалить на пользователей сотню настроек, давая им возможность все кастомизировать "под себя" - самый простой, но не самый правильный вариант. Даже если ко всем настройкам есть подробная документация, но как я уже написал выше - случается всякое) Правильный подход - подумать, как этим сервисом будут пользоваться. Это на самом деле критическая проблема. Не для всех, для того же open sourse проблема видится не критичной - библиотека, которую неудобно использовать, скорее всего не пройдет "естественный отбор". А вот в "кровавом enterprise" проблема вполне себе существует. Не всегда пользователи могут отказаться от использования какой-то части платформы. Так вот, чтобы понять оптимальные настройки по умолчанию - надо поставить себя на место пользователя. Или собрать обратную связь, или пользоваться своим продуктом. Т.об. принцип convention over configuration способствует движению в правильном направлении. Хотя конечно не является гарантией.
Вот теперь пожалуй всё)
#configuration #conv_over_conf
И "последняя серия" про convention over configuration.
Я уже говорил, почему стоит придерживаться данного принципа разработчику и команде в целом. Но можно посмотреть чуть шире.
1) с настройками приложения могут работать люди, не относящиеся к команде - тестировщики, DevOps-инженеры (да, они не должны этим заниматься, но занимаются), сопровождение ПРОМ. И у них будут похожие проблемы:
а) слишком много настроек
б) не понятно, что важно, что нет
в) не понятно, у всех одинаковые настройки (скопированные из каркаса) или у кого-то есть особенности, требующие, чтобы на них обратили внимание. По-хорошему, все это должно быть описано в документации к релизу, но случается всякое)
2) если ты разработчик какой-то библиотеки или сервиса, то вывалить на пользователей сотню настроек, давая им возможность все кастомизировать "под себя" - самый простой, но не самый правильный вариант. Даже если ко всем настройкам есть подробная документация, но как я уже написал выше - случается всякое) Правильный подход - подумать, как этим сервисом будут пользоваться. Это на самом деле критическая проблема. Не для всех, для того же open sourse проблема видится не критичной - библиотека, которую неудобно использовать, скорее всего не пройдет "естественный отбор". А вот в "кровавом enterprise" проблема вполне себе существует. Не всегда пользователи могут отказаться от использования какой-то части платформы. Так вот, чтобы понять оптимальные настройки по умолчанию - надо поставить себя на место пользователя. Или собрать обратную связь, или пользоваться своим продуктом. Т.об. принцип convention over configuration способствует движению в правильном направлении. Хотя конечно не является гарантией.
Вот теперь пожалуй всё)
#configuration #conv_over_conf