Когда нарушить YAGNI? [закрытый]
Вы можете либо установить psql в свой контейнер Jenkins, а затем запустить скрипт через команду оболочки.
sh """
export PGPASSWORD=
psql -h -d -U -p -a -w -f .sql
"""
Или, поскольку Jenkinsfiles написаны на Groovy, используйте Groovy для выполнения ваших операторов. Вот документация Groovy для работы с базами данных.
8 ответов
ПО МОЕМУ СКРОМНОМУ МНЕНИЮ,
- Я сказал бы, идут YAGNI сначала. Получите его работающий без спецификации НОРМЫ с помощью 'самую простую вещь, которая работала бы'.
- Затем сравните, если стоимость создания 'конструктивных изменений' в будущем значительно больше, чем внесение изменения теперь. Действительно ли Ваше текущее решение обратимо? Если можно легко внести изменение завтра или после того, как несколько месяцев не сделают этого теперь. Если Вы не должны делать необратимое проектное решение теперь.. задержка до прошлого ответственного момента (так, чтобы у Вас было больше информации для принятия лучшего решения),
Закрыться, если Вы знаете со значительной степенью certainity, что что-то находится на горизонте и добавлении его позже, будет болью, не будьте страусом.. дизайн для него.
например, Я знаю, что диагностические журналы были бы необходимы перед поставками продукта. При добавлении регистрирующий код после того, как месяц был бы намного большим усилием, чем включение его сегодня, поскольку я пишу каждую функцию..., таким образом, это было бы случаем, где я переопределю YAGNI даже при том, что мне не нужны журналы прямо сейчас.
Видение также: T. & M. Минимизированные книги Poppendieck лучше в объяснении дилеммы bullet#2 выше.
Причина, которую YAGNI применяет к коду, состоит в том, что стоимость изменения является низкой. С хорошим, хорошо пересмотренным кодом, добавляющим опцию позже, является обычно дешевым. Это отличается от, говорит конструкция.
В случае протоколов, добавляя изменение позже является обычно не дешевым. Старое повреждение версий, это может привести к сбоям связи и матрице тестирования N^2, поскольку необходимо протестировать каждую версию против любой версии. Сравните это с единственными кодовыми базами, где новые версии только должны работать с собой.
Таким образом в Вашем случае, для дизайна протокола, я не рекомендовал бы YAGNI.
Я думаю, что YAGNI мог быть несоответствующим, когда Вы хотите изучить что-то :) YAGNI хорош для профессионалов, но не для студентов. Когда Вы захотите узнать, что Вам всегда будет нужен он.
Структурирование Вашей программы хорошо (абстракция, и т.д.) не является чем-то, к чему относится YAGNI. Вы всегда хотите структурировать свой код хорошо.
Просто для уточнения я думаю, что Ваше текущее затруднительное положение происходит из-за по приложению YAGNI. Структурирование Вашего кода таким способом, которым у Вас есть допускающая повторное использование библиотека для использования этого протокола, является просто хорошей практикой программирования. YAGNI не применяется.
Я думаю, что это довольно просто и очевидно:
Нарушьте YAGNI, когда Вы знаете, что в полной уверенности Испытываете необходимость в Нем
Я не волновался бы. То, что Вы знающий о "YAGNI" имеете в виду Вас, уже думает практично.
Я сказал бы, независимо от чего-либо отправленного здесь, Вы, статистически более вероятно, придумаете лучший код, чем кто-то, кто не анализирует их методы таким же образом.
Я соглашаюсь с Gishu и Nick.
Разработка части протокола позже часто приводит к мыслям как "проклятый, я должен был сделать этот тот путь, теперь я должен использовать это ужасное обходное решение"
Но это также зависит от того, кто будет взаимодействовать через интерфейс с этим протоколом.
Если Ваше управление оба конца, и что они изменятся версии одновременно, можно всегда осуществить рефакторинг протокол позже, как Вы были бы с нормальным интерфейсом кода.
О выполнении дополнительной реализации функций протокола позже, я нашел, что реализация протокола помогает много проверить его дизайн, таким образом, можно, по крайней мере, хотеть сделать простой пример кода из производства для тестирования его при необходимости в дизайне для чиновника.
В некоторых случаях имеет смысл пойти против интуиции ЯГНИ.
Вот некоторые из них:
Следуя правилам программирования. Особенно базовые классы и интерфейсные контракты. Например, если унаследованный вами базовый класс предоставляет методы GetHashCode и Equals, переопределение Equals, но не GetHashCode нарушает правила, задокументированные платформой, которые разработчики должны соблюдать при переопределении Equals. Это соглашение следует соблюдать, даже если вы обнаружите, что GetHashCode на самом деле не вызывается. Невозможность переопределения GetHashCode является ошибкой, даже если в настоящее время нет способа ее спровоцировать (кроме надуманного теста). В будущей версии платформы могут появиться вызовы GetHashCode. Или другой программист, просмотревший документацию (в этом примере документация по платформе для базового класса, который вы наследуете) может с полным основанием ожидать, что ваш код будет соответствовать, без проверки вашего кода. Другой способ думать об этом заключается в том, что весь код и применимая документация должны быть согласованы, даже с документацией, написанной другими, например, предоставленной поставщиком платформы.
Поддержка настройки. В частности, сторонними разработчиками, которые не будут изменять ваш исходный код. Вы должны выяснить и реализовать подходящие точки расширения в своем коде, чтобы эти разработчики могли реализовать все виды функций надстройки, которые никогда не приходили вам в голову. К сожалению, это обычное дело, когда вы добавляете некоторые функции расширяемости, которые в конечном итоге используют немногие, если вообще какие-либо внешние разработчики. (Если возможно обсудить требования расширяемости со всеми внешними разработчиками заранее или использовать частые циклы разработки / выпуска, отлично, но это возможно не для всех проектов.)
Утверждения, проверки отладки, отказоустойчивые устройства и т. Д. . Такой код на самом деле не нужен для правильной работы вашего приложения, но он поможет убедиться, что ваш код работает правильно сейчас и в будущем, когда будут внесены изменения.