Comments 21
Вы в начале привели таблицы, из которых явным образом следует, что в ТЗ есть противоречие. Почему этих таблиц нет в ТЗ?
даже если бы были, — ТЗ не программа, оно само не проверяет противоречия
Вы тоже, но противоречие нашли.
Хотя я понимаю, откуда ноги растут — у вас, скорее всего, составляются ТЗ на доработку, а документа, содержащего актуальное описание функциональности, с которым можно сверяться при подготовке ТЗ — нет. Так?
Если что, я отвечаю на ваш же вопрос в статье:
Хотя я понимаю, откуда ноги растут — у вас, скорее всего, составляются ТЗ на доработку, а документа, содержащего актуальное описание функциональности, с которым можно сверяться при подготовке ТЗ — нет. Так?
Если что, я отвечаю на ваш же вопрос в статье:
3. Как вести знания о предметной области и как формулировать ТЗ, чтобы не было противоречий?
ИМХО причина обсуждаемой ошибки: естественное желание сделать лаконичный код. Классическое решение согласно принципам защитного программирования: избыточность.
Фактически это та же матрица сочетаний, но развернутая в линию кода программы. Функция error выводит характер ошибки и значение переменной, ее вызвавшее. В случае необходимости нетрудно написать генератор, который сделает шаблон подобного кода.
Для лучшей ориентации в коде значения нужно заменить на константы с осмысленными именами:
Вместо многоточий стоит поставить комментарии:
При возможности лучше сразу писать целевой код, а не создавать внекодовую матрицу, т.к. при переносе из нее в код возможны опечатки. А для тестирования и документации этот код автоматически с помощью несложного конвертора можно превратить в матрицу, нпр., в Excel.
case doctype of
1: case clienttype of
1: do_something1;
2: do_something2;
3: do_something3;
else error (unknownClienttype, clienttype);
end;
2: case clienttype of
1: …
2: …
3: …
else error (unknownClienttype, clienttype);
end;
3: case clienttype of
1: …
2: …
3: …
else error (unknownClienttype, clienttype);
end;
else error (unknownDoctype, doctype);
end;Фактически это та же матрица сочетаний, но развернутая в линию кода программы. Функция error выводит характер ошибки и значение переменной, ее вызвавшее. В случае необходимости нетрудно написать генератор, который сделает шаблон подобного кода.
Для лучшей ориентации в коде значения нужно заменить на константы с осмысленными именами:
const ORGANIZATION = 1;
…
case clienttype of
ORGANIZATION: do_something1;
Вместо многоточий стоит поставить комментарии:
{ToDo}При возможности лучше сразу писать целевой код, а не создавать внекодовую матрицу, т.к. при переносе из нее в код возможны опечатки. А для тестирования и документации этот код автоматически с помощью несложного конвертора можно превратить в матрицу, нпр., в Excel.
Поддерживаю данный подход!
Только, если атрибута 3, то это уже трехмерная матрица. Если их будет штук 40, то полное сочетание в case операторе будет монстром. При добавлении нового атрибута надо будет еще во все места case оператора дописывать еще один уровень вложенности.
Плюс Вы не поняли еще одну фишку моего подхода — дополнительные действия с минисценариями. Их можно анализировать без внесения изменения в базу данных. Например, можно делать легкое регрес-тестирование или прогонять по всей базе не боясь чего-то изменить.
Только, если атрибута 3, то это уже трехмерная матрица. Если их будет штук 40, то полное сочетание в case операторе будет монстром. При добавлении нового атрибута надо будет еще во все места case оператора дописывать еще один уровень вложенности.
Плюс Вы не поняли еще одну фишку моего подхода — дополнительные действия с минисценариями. Их можно анализировать без внесения изменения в базу данных. Например, можно делать легкое регрес-тестирование или прогонять по всей базе не боясь чего-то изменить.
Ничего не мешает сделать подобный код и для 40 атрибутов. 40 уровней для вложенных case, конечно, будет очень объемным. И конечно его надо генерировать с помощью несложной программы или скрипта, а не писать руками, чтобы не ошибиться. На каждой вершине стоит перечислить значения атрибутов:
Но ИМХО ничего страшного — главное уверенность, что это будет верно работать и легко модифицироваться!
do_something1; // clienttype=ORGANIZATION doctype=...Но ИМХО ничего страшного — главное уверенность, что это будет верно работать и легко модифицироваться!
PS
еще одну фишку моего подхода — дополнительные действия с минисценариямиOk. Я предложил альтернативное решение. Как часто бывает везде свои ++ / --.
PPS Прикинул, что 40 уровней может быть многовато для моего предложения…
Я тоже подход с case-ом когда то пытался проанализировать. Это похоже на промежуточный вариант между тем, что пишут в ТЗ и мат. логикой, которая основана математических конструкциях.
Моя идея — пиши код почти как написано в ТЗ, а умная оболочка разруливает нестыковки. Если использовать свой язык, как Вы предложили, то это будет ближе к моим идеям. Так на программисте меньше ответственности за ошибки.
Моя идея — пиши код почти как написано в ТЗ, а умная оболочка разруливает нестыковки. Если использовать свой язык, как Вы предложили, то это будет ближе к моим идеям. Так на программисте меньше ответственности за ошибки.
Моя идея — пиши код почти как написано в ТЗ, а умная оболочка разруливает нестыковки. Если использовать свой язык, как Вы предложили, то это будет ближе к моим идеям. Так на программисте меньше ответственности за ошибки.Да, только я использовал не свой язык, а Delphi. Вы отметили важный принципиальный момент: чем больше сходство кода с ТЗ — тем он убедительнее.
Не та ветка…
Мне эта проблема напомнила про Drools. www.youtube.com/watch?v=GvN9W67Bscs&t=1s
Когда бизнес-логика усложняется, а ТЗ является просто коллекцией утверждений, требуется экспертная система для проверки противоречий.
Когда бизнес-логика усложняется, а ТЗ является просто коллекцией утверждений, требуется экспертная система для проверки противоречий.
Имхо у Вас в самом изначальном примере дублирование знаний (действие можно привязать к типу лица, а можно — к типу договора), и отсюда все проблемы. Атрибуты по-возможности должны быть ортогональны.
Ударим некропостом!..)
Все ссылки и идеи в статье есть, но главный вывод не сформулирован. Все бизнес правила должны лежать во внешнем хранилище и вообще не дублироваться в коде собственно программы. Программист должен вместо пачки условий дернуть интерпретатор, который сходит в хранилище и скажет «делай три раза ку». Поменялись правила в хранилище — изменилась бизнес-логика всего подключенного софта, без перекомпиляции.
Все ссылки и идеи в статье есть, но главный вывод не сформулирован. Все бизнес правила должны лежать во внешнем хранилище и вообще не дублироваться в коде собственно программы. Программист должен вместо пачки условий дернуть интерпретатор, который сходит в хранилище и скажет «делай три раза ку». Поменялись правила в хранилище — изменилась бизнес-логика всего подключенного софта, без перекомпиляции.
Вашими устами да мед пить.
(не я минуснул, если что...)
В большом проекте не раз видел, как крутые разработчики ипытывали разные эмоции.
Первая неделя — энтузиазм.
Вторая неделя — озабоченность.
Третья неделя — иллюзия, что вот вот и решу задачу, стоит только попотеть.
Четвертая неделя — отчаяние, но надежда еще есть.
Пятая неделя — сплошные возмущения, но дело уже сдвинулось на миллиметр.
Шестая неделя — начал понимать все извращение, но психика уже покалечена.
…
(не я минуснул, если что...)
В большом проекте не раз видел, как крутые разработчики ипытывали разные эмоции.
Первая неделя — энтузиазм.
Вторая неделя — озабоченность.
Третья неделя — иллюзия, что вот вот и решу задачу, стоит только попотеть.
Четвертая неделя — отчаяние, но надежда еще есть.
Пятая неделя — сплошные возмущения, но дело уже сдвинулось на миллиметр.
Шестая неделя — начал понимать все извращение, но психика уже покалечена.
…
UFO just landed and posted this here
Sign up to leave a comment.
Шаблон проектирования “минисценарий с проверкой противоречий”