|
|
| Строка 23: |
Строка 23: |
| | Если собираетесь там быть — заходите, обычно на наших докладах нескучно. | | Если собираетесь там быть — заходите, обычно на наших докладах нескучно. |
| | [[Category:SECR-2010]] | | [[Category:SECR-2010]] |
| − | {{wl-publish: 2010-10-12 20:47:00 +0400 | StasFomin}} | + | {{wl-publish: 2010-10-12 20:47:00 +0400 | StasFomin}} |
| | {{To-lib-silent}} | | {{To-lib-silent}} |
Текущая версия на 17:18, 7 февраля 2013
Завтра начинается конференция CEE-SECR 2010, куда мы традиционно ходим других посмотреть и себя показать (а именно см. 2009, 2008, 2007, …).
И в этот раз будет пара десятков участников и пара докладов.
Алексей Алексеев, Николай Гребнев — «Уменьшение влияния человеческого фактора при разработке бизнес-приложений».
В этом докладе мы постараемся рассказать о принципах разработки инструментов для написания бизнес-логики, позволяющих сократить количество ошибок.
Речь пойдет о нескольких практиках, принятых в отделе технологического развития нашей компании. Принципы будут проиллюстрированы на примере инструментария компании Microsoft.Максимум статических проверок. Под статическими проверками мы понимаем проверки времени компиляции. Этот принцип является важным, но, к сожалению, зачастую недооценивается разработчиками инструментария разработки. Проверки времени компиляции могут отлавливать большой спектр ошибок. Есть и другая особенность – это удобство.
Ошибки времени исполнения сложнее воспринимаются, труднее найти причину ошибки.Разнообразие и декларативность проверок. Проверки общего назначения удобно задавать в декларативном виде. При этом сами проверки должен осуществлять фреймворк. За счет уменьшения дублирования и декларативности снижается вероятность ошибок. Проверки должны быть, как техническими, так и уровня доменной модели.
Мы будем говорить о проверках уровня доменной модели.Возможность анализа декларативных проверок. Любые ограничения порождают некоторую модель. Эту модель (проверки) можно формально верифицировать. Вообще, проблема доказательства большинства свойств программы невозможна. Этот вопрос выходит далеко за рамки нашего доклада. Но существует возможность верификации более слабых (менее выразительных моделей). Во второй части мы обсудим функционал, который мы называем “состояния”. Так вот эти “состояния” образуют что-то вроде автомата, или структуру Крипке. Так вот, существуют алгоритмы проверки выполнимости
темпоральных логик на таких структурах.
Станислав Фомин, Agile Learning: Эффективные инструменты
Аннотация по вышеприведенной ссылке, а вот краткий промо-ролик:
Если собираетесь там быть — заходите, обычно на наших докладах нескучно.
