Автоматизация_бизнес-процессов_(семинар_2012-11-07).

Автоматизация бизнес-процессов:
проектирование архитектуры
конкурентных решений
I object to doing things that computers can do
Olin Shivers
Цели
• Разработать подход к проектированию ITрешений для бизнеса
• Выявить критические абстракции
• Обозначить наиболее жизненно важные
аспекты цикла существования
программного продукта
• Что такое «бизнес-логика» и что о ней надо
знать разработчику
Бизнес-«нелогика»
Идея!
Задачи от бизнеса через призму
• Отсутствие видения модели каждой
сущности в перспективе, даже если все
уверены в обратном
• Сервисные задачи не интересуют «бизнеслогику»
• Сделать «это» очень просто!
• «Это» нужно вчера
Эра «стартапов»
• Поиск надежной бизнес-модели, НИОКР в
области интернет-рынков
• Быстрый рост на начальных инвестициях
• Быстрое падение
• «Патентный троллинг»
• Слияние и поглощение
Предел гибкости
• Переусложнение неизбежно?
• Что забыли учесть?
• Закон Завинского:
– Every program attempts to expand until it can
read mail. Those programs which cannot so
expand are replaced by ones which can.
• Что потеряет проект в ближайший месяц,
если не сможет читать почту завтра?
Предел сложности решений
• Насколько интенсивно будет меняться
продукт на протяжении ближайшего
времени?
• Какова квалификация вовлеченной группы
разработчиков?
• Сколько времени понадобится
разработчику с опытом от 3х лет, чтобы
погрузиться в проект?
Предел масштабируемости
• Будем ли мы продавать услуги клиентам из
соседних галактик?
• Сделаем все многопоточным?
• Что тяжелее: вычисления или данные?
• RDBMS vs NoSQL
Инструмент для задачи, а не задача
для инструмента
(маркетинговые ловушки)
• Западня универсальных систем
– миллионы мух не могут ошибаться
• На сколько готовое решение решает задачи
ближайших 6 месяцев?
• Какова стоимость результатов работы
ближайших 6 месяцев?
• Риски vs Страховка
Без чего жить программировать
нельзя
• Логов много не бывает
• Простота интеграции и миграции, не путать
с легкостью переключения на другие СУБД
(насколько нужна последняя?)
• Ввода/вывода мало не бывает
• Кэш и его инвалидация
• Насколько просто это тестировать?
Перманентный рефакторинг
рабочий
прототип
элегантное
решение
оптимизация
О чем можно забыть и потом сильно
пожалеть
• Отказоустойчивость и устойчивость к взлому
• Простота диагностики
• «Ломка» при смене ключевых разработчиков
(кто это писал?)
• Эффективность одновременной работы
большого числа людей над общим проектом
• Степень надежности проноса в бой новых
версий
• Не инкапсулированные решения приводят к
затратному и болезненному рефакторингу
Эффективность кода
• DRY!
• Документация
• Эксплуатация общепризнанных паттернов
– только достоверно необходимых для
конкретной задачи абстракции
• Экономия на спичках
• Единый согласованный стиль всех для всех
участников команды
Спасибо!
spesivtsev@custis.ru