Обсуждение

По поводу парного программирования: в процессе разработки ПО вообще многое трудно оценить каким-либо образом кроме экспертной оценки. Но вот наличие и отсутствие серьёзных ошибок при парном и одиночном программировании - вещь довольно таки заметная. Думаю, что не стоит всё-таки искать здесь схем, общих для всех случаев, слишком всё индивидуально.

Показать выгодность чего угодно - не сложно. Другое дело, для честного доказательства нужны честные тесты с контрольной группой. Лучше всего - слепые. А при нынешней стоимости рабочего часа среднего программиста это безумно дорого. Потому и давали тесты в шестидесятых разницу производительности между программистами в сорок раз, а сейчс "собиратели и компиляторы" радостно рапортуют о разнице в два - два с половиной. Controlled russian на самом деле не такая уж и утопия. Просто он будет уже не процедурным Картинка на двадцатой странице просто ржачная. Лучше уж писать управление тостером, чем такое. И хорошо б презентацию просто в PDF класть...

Интересно было бы поглядеть на неутопичный controlled russian. На непроцедурность вполне согласен. Картинка на двадцатой странице прихвачена из презентации самих стандартизаторов языка: там показывается выразимость весьма хитрых отношений между оркестровкой и хореографией, которые трудно выразить в других нотациях. Вообще, это давняя проблема: связь оркестровки и хореографии -- "заклятых друзей". Проблема еще и в том, что посредине пути они все могут передоговориться, что делать дальше, и картинку придется перерисовывать на ходу. Презентацию я кладу в исходниках ;) Ибо из .pdf к себе чужие слайды трудно утащить, а из исходников -- вполне.

Во-первых, спасибо за ваши посты. Во-вторых, выскажусь по поводу орг. норм (16-й слайд). Возможно, вы и сами знаете, что оформлять бизнес-правила в "программистском стиле" не лучший подход. Такие правила становятся запутанными, слабо контролируемыми и трудно изменяемыми. Есть такое понятие (тип данных) - "Регистр правил" - он более подходит для формулировки норм и правил. Правила мы представляем не в виде множества импликаций "Если-То", а в виде функциональной зависимости (отношения, таблицы). Детерминант - набор переменных, от которых зависит значение корня (зависящая часть). В приведенном примере детерминант состоит из 3-х измерений (переменных) - CartItems, PurchaseSum, CustomerCategory. Корнем регистра является переменная DiscountValue. Упрощяя, все перечисленные переменные являются столбцами таблицы, в которой формулируются сами правила (значения строк таблицы). (CartItems, PurchaseSum, CustomerCategory) -> DiscountValue Пользователь может добавлять и изменять правила, заданные в табличном стиле, без привлечения программиста.

В картинке смешон сам текст. Давно известно, программитсы живут на какой-то другой планете.

В ClearSpeak крайне не рекомендуется формулировать организационные нормы в виде "Если - то", ибо при этом легко перепутать декларативный стиль и процедурный. Что касается бОльшего удобства табличных форм записи правил по сравнению с текстовыми, то я бы поспорил. Я хорошо помню, что в свое время (будучи уже программистом) с трудом разобрался с проектированием баз данных -- все эти "нормальные формы" давались мне пару месяцев с неимоверным трудом. А потом "мозги повернулись" (эдакая "метанойя") и стало легко, понятно и появилась ложная уверенность, что это все легко и понятно для всех остальных -- ведь никаких специальных слов, кроме слов "таблица" в этом проектировании баз данных нет! Но это была ложная уверенность. Никому про "детерминанты", "измерения-переменные", "корни регистра" и прочее из вашего примера я бы не брался рассказывать. А вот переводить из controlled natural language в ваш табличный язык для исполнения (или в любой другой язык, в котором уже можно компьютерно исполнять) -- это дело уже программистов. Именно программисты должны взять понятный людям текст и превратить его в понятный для машины.

Возможно, я зря ввязываюсь в дискуссию, потому что для объяснений "на пальцах" преимуществ "регистров правил" может не хватить временных ресурсов. Поэтому заранее прошу прощения за сумбурность. Возможно, мы по-разному понимаем "назначение" программистов. Для меня программист - это тот, кто кодирует поведение системы, но не настраивает конкретные параметры системы. Настройкой поведения системы занимается ее администратор (или кто еще), а не программист. Поэтому обычно программистам не рекомендуется использовать понятия прикладного уровня в текстах программ. Но программист (точнее программа) должен предоставить пользователю возможность самостоятельного использования понятий прикладного уровня. В том числе для формулировки бизнес-правил. К системе можно подойти с точки зрения стратификация данных (понятий и значений). Согласно принципу стратификации можно выделить системый уровень, служебный и пользовательский. На системном уровне как понятия, так и значения понятий задаются программистом (системой). На служебном система определяет понятия, но предоставляет пользователю возможность управления значениями понятий. На пользовательском уровне как понятия, так и их значения определяются пользователем. В примере со скидкой понятия прикладного (пользовательского) уровня используются на системном (в программном коде). Это плохой стиль. Вариант с регистром правил заданной структуры - это служебный уровень. Тоже имеет минусы,- у разных клиентов (пользователей) могут быть свои переменные, влиюящие на скидку. Оптимальный (с точки зрения гибкости) вариант - сделать структуру регистра настраиваемой пользователем (администратором) при сохранении семантики корня (значение скидки).

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

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

Я вот вчера допер зачем нужен моделирование процессов. Мне просто задали вопрос, на чем лучше писать экспертную систему. В исходной формулировке, словосочетание "экспертная система" отсутствовало, что означало, что товарищ совсем в программировании не шарит, т.е. отвечать ему особо смысла не имело. Но я задумался, а как таким товарищам быть и как программерам, к примеру, его окучивать? Допустим он достаточно платежеспособен, но тогда программеры или программерская контора скорее всего его тупо разведут на бабло, причем независимо от своего желания - грамотно контроллировать их он вряд ли способен (если способен - то и проблем нет). Интересует все-таки какой-то конструктивный выход. И тут я допер, что в данном случае как раз можно использовать моделирование процессов. Т.е. заказчику в данном случае нужна не сколько программа, сколько процесс, ибо экспертная система подразумевает составление базы знаний/правил, валидацию и обслуживание всего этого барахла. Это все переносимо и на организационные нормы. Таким образом, такому заказчику можно впарить процесс :). А оформить его в соответствии с новыми веяниями, по какому-нить стандарту, в каком-нить EPF Composer'е как разновидность OpenUP :).

Все-таки современная онтология тут сложнее: заказчику нужно впарить сервис, а вот сервис осуществлять системой, которая работает по процессу. :)

Зависит от заказчика. В общем и целом, думаю Вы правы, тем не менее, мне скорее видятся возможности впаривать именно процесс. Грубо говоря, впаривать сервис и налаживать систему очень геморно, это не моя специализация и мне это совсем не интересно. При этом такие заказчики есть. Дело в том, что нонче есть много возможностей раскрутится малыми ресурсами. Разумеется тут надо интегрировать разные компетенции, вот тут процессы вполне могут помочь. Т.е. к примеру предприниматель сам организует сервис и систему, а консультант ему налаживает процесс, причем в виде продукта - т.е. какую-то тулзу заточенную под его нужды.

"Семантика корня", "детерминант" и пр. - это язык специалистов. Для настройки правил пользователям его знать необязательно,- справляются. Тут практика критерий. Табличное (точнее регистровое) представление правил позволяет справиться с энтропией при большом количестве переменных (то, что Вы называете "верификацией"). Табличные правила система способна верифицировать сама, и остаться работоспособной при любых (часто противоречивых) пожеланиях пользователя. Пример со скидкой довольно прост,- на практике входной контекст часто состоит из десятка переменных, каждая из которых может принимать множество значений. Никакой специалист не справится с верификацией множества правил при таком контексте, если они выражены в форме импликаций. Даже в простых примерах непросто увидеть противоречивость правил. Например, что можно сказать по поводу следующей импликации? If Sum>100 Then Discount=10 ElseIf Category=Gold Then Discount=15 EndIf Я так понимаю, что данное правило понятно пользователю. Но увидит ли он сразу заложенную противоречивость правила? Какая должна быть скидка, если Category=Gold, а Sum=150? Как разбираться с такими "Если-То", когда размер скидки зависит, например, еще от сезона, региона, дня недели, категории товара, магазина, действующей акции и т.п.? Когда категорий клиентов не две, а с десяток? Поэтому еще раз. Для небольших примеров, тестовых демонстраций и пр. можно использовать привычные "Если-То". Для реальных больших систем - только регистры (табличные функции).

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

:) Извините. Все мои замечания касались конструкции "Если-то", использование которой я увидел на 16-м слайде.

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