LINUX.ORG.RU
ФорумTalks

«А это мягкий код - мы не будем вам его показывать!»

 , ,


0

2

Пишу сейчас программу и постоянно меня терзает желание выносить логику в конфигурационные файлы и делать программу максимально настраиваемой. А так же легко модифицируемой. Это хорошо наверно с точки зрения перфекциониста, но сильно тормозит разработку. Что вы обычно чувствуете когда сталкиваетесь с такими проблемами? И что вы обычно делаете в таких случаях?

https://habrahabr.ru/post/59005/
Мягкое кодирование — параноидальная боязнь жёсткого кодирования. Это приводит к тому, что незахардкожено и настраивается абсолютно всё, что делает конфигурацию невероятно сложной и непрозрачной. Этот анти-паттерн является вторым концом палки о жёстком кодировании и поэтому тоже является опасным. Во-первых, при разработке много ресурсов уходит на реализацию возможности настроек абсолютно всего. Во-вторых, развёртывание такой системы повлечет так же дополнительные затраты. Перед началом решения определённой задачи следует определить, что должно быть настариваемым, а что является постоянным для различных систем или может быть настроено автоматически.

И что вы обычно делаете в таких случаях?

Я говорю: «Привет. У меня вопрос по новым правкам. Вот ты там добавляешь ещё одну настройку в конфигурации. Если значение этой настройки поменять, программа вообще работать будет? Имеет ли смысл это выносить наружу?»

i-rinat ★★★★★
()

Не делаю ничего настраиваемым, пока мне это не понадобилось реально. Но писать стараюсь по возможности так, чтобы переделать можно было относительно быстро.

Legioner ★★★★★
()

Я в таких случаях использую SOLID, IOT и инжекцию зависимостей. Бонусом получаем возможность клепать юнит-тесты без особого гемора, и отложить реализацию дополнительной «гибкости конфигурирования» напотом не ломая архитектуру. Ну а если где-то нужна возможность гибкой конфигцрации - то допиливается уже потом, когда прототип уже работает и основные баги исправлены.

DawnCaster ★★
()

Решаю проблемы по мере поступления не просят настройку не делаю. Да себя уже давно определился - хочу сделать настройку, значит просто не знаю как нужно делать.

ilovewindows ★★★★★
()

Когдаь пользователи просят или настройка является необходимой. Изредка приходится добавлять настройки при расширении функциональности, чтобы не поломать совместимость с предыдущими версиями. А вот так, чтобы добавлять настройки просто так для украшения, неееет, я слишком ленив.

alman ★★★
()
Последнее исправление: alman (всего исправлений: 1)

Я как любитель гнома вообще стараюсь обходится без настроек. Только если уж совсем припрет, только тогда, и то со скрипом.

morse ★★★★★
()

Это зависит от того, сколько пользователей будет. Если ты только для себя пишешь, например, проще будет захардкодить конфигурацию где-то в отдельном модуле/хедере в виде констант/константных функций, чтобы безболезненно прикрутить чтение конфигурации из файла, когда понадобится.

Ну и не стоит забывать про release early, если ты всё-таки пишешь не для себя.

E ★★★
()

Никак не решаю, это не проблема ;) Всё что кажется нужным для настройки - выношу в настройки.

Интуитивное понимание «кажется нужным» берется из опыта работы админом и девопсом - примерно представляешь, что хотелось бы, если бы вот именно ты разворачивал эту софтину.

Радикальный метод решения - использовать скриптовые языки или недоязыки типа Go. Тогда девопс/SRE может зайти и вручную «настроить» что угодно правкой кода. Понятно что это приводит к лютейшей тормознутости и говнокоду в самом софте (быстрая Java vs тормозные JavaScript/node, красивый C# vs убожество Go), поэтому это очень неприятный, тяжелый компромисс

stevejobs ★★★★☆
()
Ответ на: комментарий от stevejobs

Тогда девопс/SRE может зайти и вручную «настроить» что угодно правкой кода.

devops/sre и без Go может это сделать, на чистой этой вашей жаве

А у тебя просто получается: переложил архитектурные проблемы на другого - и жизнь прекрасна.

alpha ★★★★★
()
Последнее исправление: alpha (всего исправлений: 1)

Пишу сейчас программу

Да ну?!

Это хорошо наверно с точки зрения перфекциониста, но сильно тормозит разработку

Да ладно, все и так знают что именно тормозит тебе разработку.

ya-betmen ★★★★★
()
Ответ на: комментарий от alpha

devops/sre и без Go может это сделать, на чистой этой вашей жаве

да вот не может. Не так давно на прошлой работе, единственный человек в команде, который мог полностью корректно сделать релизную сборку нашей софтины - был только я, и это занимало день.

первый квест в том, чтобы вообще собрать этот код и получить релизные артефакты для развертывания. Для примера, когда нам передали этот код для улучшения, мы (разработчики-программисты) в течение двух недель учились только собирать и запускать этот код - и по-моему, так и не научились.

Второй квест в том, чтобы обмазать релизные артефакты скриптами на энсибле, пайтоне и баше, и совместить это с ченжами в архитектуре приложения инфраструктуре. Третий - в написании толстенной инструкции для админов (админы обычно не хотят разбираться в скриптах, им нужно вордовский файл на триста страниц, в котором описываются команды, которые нужно выполнить в командной строке - иначе говоря, плейбуки, описанные «человеческим» языком). На выходе всех квестов получается готовая поставка для развертывания на прод.

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

для таких же проектов на пайтоне или эрланге часть проблем снимается. Например, не нужно ничего пересобирать или перезаупускать - можно прямо на живую править код и прямо в режиме онлайн смотреть, починилось ли

stevejobs ★★★★☆
()
Последнее исправление: stevejobs (всего исправлений: 1)
Ответ на: комментарий от stevejobs

Но упаси бог забраться внутрь и что-нибудь поменять - у «человека со стороны» это сразу минус месяц работы просто на понимание, какого черта здесь творится.

От того что ты этот хлам перепишешь на Go, ситуация не поменяется. Дело не в языке, а в архитектуре.

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

Devops должен кодить внешние скрипты удобными ему инструментами, а не переписывать интерфейсы твоей программы на твоем Go.

alpha ★★★★★
()
Последнее исправление: alpha (всего исправлений: 1)

Делаю возможность изменять из конфигурационных файлов все, что пользователь потенциально может захотеть изменять. При этом если значение не установлено в конфигурационном файле, то используется значение по умолчанию, описанное внутри программы. Таким образом в конфиге для того, кто будет настраивать, достаточно пары полей типа имени БД и порта сервиса.

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

p.s. Этих ваших (анти-)паттерно-фанатиков лучше не читать. А то велик шанс вместо своего кода обнаружить доширак.

Deleted
()
Ответ на: комментарий от alpha

у нас с админами есть такой вечный конфликт.

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

админы обычно хотят следующий воркфлоу: - либо используйте инструменты которые мы уже умеем (не нужно использовать Consul или Netflix Eureka, если всё можно навелосипедить на BIND9 DNS)
- либо напишите всё на скриптовом языке, и скажите в каком месте править. Но только так, чтобы всё было четко ясно и понятно: на какой строке какой символ поправить
- никакой динамики и аджайла нам не надо. Выложил релиз, инструкцию - и это «конечный источник истины». Следующий багфикс возможен только через календарный квартал

в результате взаимодействие с админами превращается в передел зон влияния. «Бандитский Петербург». И это как правило именно админы требуют переписать всё на Go, чтобы потом они могли править строку 32 символ 18. Поэтому сочетание слов «моё Go» рвет душу неизбывной болью. Даже минимальный ченж в коде продукта - это ОЧЕНЬ нетривиальная вещь для «человека со стороны», и когда я представляю как делает это админ, на глаза наворачиваются слезы.

обычный результат столкновения: конфиги (на самом деле - программа) на XML для Spring Framework или кусок кода приложения на Go, который правит выделенный под это несчастный человек с ролью «девопс». Он несчастный потому, что если вышел из разработчиков - это решение до глубины души оскорбляет его чувство прекрасного, а если из админов - потому что даже несмотря на Go всё равно это сборник костылей в котором ничерта не понятно и работает всё нестабильно и как говно

что сделать с этими политическими проблемами пока непонятно. Из проекта в проект, из компании в компанию, происходит одно и то же..

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

stevejobs ★★★★☆
()
Последнее исправление: stevejobs (всего исправлений: 2)
Ответ на: комментарий от alpha

Еще есть очень забавная позиция: «all or nothing at all» как в песне.

Например, программисты накодили хрень, которую непонятно как держать живой и перезапускать.

Если спросишь что за хрень - тебе тут же ответят «этими вопросами занимаемся не мы, а админы, понятия не имеем и иметь не хотим».

Если же дать задачу - сделать поддержку живости, то скорей всего программисты решат что «теперь это их задача». И в первую же очередь рванутся писать свою систему инициализации.

И вопрос опять сводится к разделу сфер влияния - система инициализации это чья корова, и кто её доит

И похоже, что такая война всех устраивает. Люди находят в ней особую извращенную радость :(((

stevejobs ★★★★☆
()

Это приводит к тому, что незахардкожено и настраивается абсолютно всё, что делает конфигурацию невероятно сложной и непрозрачной.

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

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

Я считаю что какие-то внутренние сущности нет смысла выносить в конфигурацию - изменение их является по сути изменением работы того черного ящика, которым является твое приложение, так что должно идти релизом и делать это должен разработчик, так как именно он знает (ну или должен знать) как его код работает. А вот хардкодить какие-то внешние связи это плохо, потому что то, что приходит в твой черный ящик (и, по сути, выходит из него) должно настраиваться пользователем\администратором. Опять же если внутренние сущности влияют на входные\выходные данные то это надо выносить в конфиги. Короче говоря сядь и подумай что пользователь товего ПО может захотеть изменить, при том что он в целом не знает что внутри твоего приложния происходит и руководствуется только какими-то внешними раздражителями, и вынеси в конфиги.

alozovskoy ★★★★★
()

Нередко добавляя новую фичу, которая может серьезно повлиять на нагрузку сервисов, делаю возможность отключить ее через конфиг и вернуться к старому поведению без отката. Но да, я разрабатываю не клиентский софт, а веб-приложение.

drull ★☆☆☆
()
Последнее исправление: drull (всего исправлений: 3)
Ответ на: комментарий от E

например, проще будет захардкодить конфигурацию где-то в отдельном модуле/хедере в виде констант/константных функций, чтобы безболезненно прикрутить чтение конфигурации из файла, когда понадобится.

Пытаюсь так делать. Ускоряет начало отладки.

rezedent12 ☆☆☆
() автор топика
Ответ на: комментарий от stevejobs

И это как правило именно админы требуют переписать всё на Go

Я вот, например, не требую. Я как раз прихожу к разработчикам того же дженкинса и спрашиваю - «где мой api для настройки системных вещей типа почтового ящика админа?». А мне говорят: «API для настроек - это мы не можем, там думать надо. Зато у вас же есть groovy, можете влезть в любой java-объект и выполнить любой код»

Просто нет слов какая гибкость и настраиваемость.

Так что я немного нервно реагирую на слова: «а нам не нужны конфиги, мы просто предоставим возможность делать все что угодно на скриптовом языке»

и непонятно даже с какой стороны баррикады взятый

я нынче devops в команде java-разработчиков, то есть отвечаю за взаимодействие разработчиков с админами (пока не отвечаю а только вот две недели как начала и пытаюсь вникнуть, что где). Так что через полгодика обращайся, расскажу как мы решаем эту проблему :)

alpha ★★★★★
()
Ответ на: комментарий от Deleted

Делаю возможность изменять из конфигурационных файлов все, что пользователь потенциально может захотеть изменять. При этом если значение не установлено в конфигурационном файле, то используется значение по умолчанию, описанное внутри программы. Таким образом в конфиге для того, кто будет настраивать, достаточно пары полей типа имени БД и порта сервиса.

Так и сделал в своём VirtualGPIO.

p.s. Этих ваших (анти-)паттерно-фанатиков лучше не читать. А то велик шанс вместо своего кода обнаружить доширак.

В каком смысле?

rezedent12 ☆☆☆
() автор топика
Ответ на: комментарий от stevejobs

что сделать с этими политическими проблемами пока непонятно. Из проекта в проект, из компании в компанию, происходит одно и то же..

Может стоит полностью пересмотреть подход?

rezedent12 ☆☆☆
() автор топика
Ответ на: комментарий от alozovskoy

Короче говоря сядь и подумай что пользователь товего ПО может захотеть изменить

Разве что номера портов и названия режимов.

rezedent12 ☆☆☆
() автор топика
Ответ на: комментарий от Manhunt

Что такое IOT ?

Это опечатка, разумеется. Имеется ввиду IOC.

DawnCaster ★★
()

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

KillTheCat ★★★★★
()

делаю несколько слоев конфигурации - часть настроек можно поменять через интерфейс ПО, больше - через конфиг-файл(ы), все остальные параметры типа hardcoded, но в одном месте, что позволяет быстро перекидывать их в другие слои.

dib2 ★★★★★
()
Ответ на: комментарий от ya-betmen

Все кто уже общался с тобой на форуме или в жизни.

А ты я смотрю телепат, в смысле телепатель читающий массово мысли людей.

rezedent12 ☆☆☆
() автор топика

ТС, задавай себе такие вопросы:

  • то что я хочу вынести в настройки имеет смысл или это константа (да/нет)
    • да - переходи дальше
    • нет - алгоритм завершен
  • то что я выношу в настройки не конфликтует с другими настройками (да/нет/не знаю)
    • да - переходи дальше
    • нет - а оно точно надо?
      • да - переосмысливай все настройки, делай защиту от дурака
      • нет - алгоритм завершен
    • не знаю - можешь узнать за разумное время?
      • да - узнай же
      • нет - алгоритм завершен
  • я осилю это (да/нет)
    • да - фичу мне запили
    • нет - алгоритм завершен
peregrine ★★★★★
()
Ответ на: комментарий от peregrine

ТС, задавай себе такие вопросы:
то что я хочу вынести в настройки имеет смысл или это константа (да/нет)

Имеет, ибо конфигурация оборудования при внедрении может оказаться другой.

то что я выношу в настройки не конфликтует с другими настройками (да/нет/не знаю)

Нет.

нет - а оно точно надо?

Не знаю пригодится ли на самом деле. Проще сказать заказчику что надо ставить реле протока и ничем другим его заменять не следует. И ставить именно соленоидный клапан, а не питание насоса дёргать.

я осилю это (да/нет)

Осилю, тут вопрос времени, неделю или 2 недели.

Я решил что надо предусмотреть не только сигнал открытия клапана, но и сигнал закрытия, на случай если вместо соленоидного клапана будет применён управляемый вентиль. Для всего прочего я решил что в ответ на одну кнопку определяющую режим включается один режимный выход и все другие отключаются. То есть в конфигурационном файле будут описаны названия режимов, GPIO контакты кнопки и питания каждого режима, а так же GPIO датчика протока для учёта ресурса, а так же GPIO открытия потока воды и GPIO закрытия потока. А описания цен каждого режима вынести в другой файл.

Я решил не выносить логику в конфигурационный файл, а указывать в нём только номера контактов GPIO.

rezedent12 ☆☆☆
() автор топика
Последнее исправление: rezedent12 (всего исправлений: 1)

Что вы обычно чувствуете когда сталкиваетесь с такими проблемами?

☑ Не сталкиваюсь с такими проблемами.

shrub ★★★★★
()
Ответ на: комментарий от rezedent12

Имеет, ибо конфигурация оборудования при внедрении может оказаться другой.

А ты можешь программно узнать эту конфигурацию? Если да, то смысл перегружать заказчика 100500 настройками.

peregrine ★★★★★
()

При правильном использовании dependency injection это не является анти-паттерном, так как практически не несет дополнительных расходов.

komeiji
()
Ответ на: комментарий от alozovskoy

Не понимаю чего тут сложного и непрозрачного.

Отсутствие вменяемых умолчаний, например.

thunar ★★★★★
()
Ответ на: комментарий от peregrine

А ты можешь программно узнать эту конфигурацию?

Нет.

rezedent12 ☆☆☆
() автор топика

У нас в компании принято при добавлении новых фич всегда делать их отключаемыми через параметры. Идея здравая, так как клиенты могут не обрадоваться внезапному появлению какой-то новой фичи у них в продакшене при обновлении. Однако в результате это правило применяется для всего, что попало, даже для тех изменений, которых клиент не увидит (хорошо ещё, что не для багфиксов), в результате параметров стало так много, что обновление между мажорными версиями с несовместимыми конфигами - это ручной труд и несколько недель работы специалиста. Скрипты для миграции параметров либо не существуют, либо не работают, так как разработка идёт активно, новые параметры добавляются регулярно, за совместимостью никто не следит, и много кастомизированных версий софта для конкретных клиентов.

Pythagoras ★★
()
Ответ на: комментарий от Pythagoras

и много кастомизированных версий софта для конкретных клиентов.

О том что бы вынести кастомизацию в плагины задумывались?

У орков в Warhammer 40,000 широкий выбор военной техники и вооружений: почти всё оружие клепается вручную, или, как говорят сами орки, «кастом» (kustom). Есть огромное количество вариантов как различных конструкций, так и названий одного экземпляра. Адептус Механикус при изучении оружия орков недоумевают: в руках человека оружие орков — просто куча хлама, однако в лапах орка всё работает вполне эффективно. Ну и на взрывы оружия в руках большинству орков совершенно плевать: был слабым — взрыв прикончил, был сильным и что-либо оторвало — мек всегда может сделать киборком или посадить в дред. http://cyclowiki.org/wiki/Оружие_орков

rezedent12 ☆☆☆
() автор топика

Пишу сейчас программу и постоянно меня терзает желание выносить логику в конфигурационные файлы

«Если за это не убивать, то за что тогда вообще убивать?» © vsl

redgremlin ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.