Документ обсуждает автоматизацию бизнес-процессов и проектирование архитектуры IT-решений с акцентом на выявление критических абстракций и понимание бизнес-логики. В нем рассматриваются проблемы и ограничения, с которыми сталкиваются разработчики, такие как пределы гибкости и масштабируемости решений, а также важность отказоустойчивости и интеграции. Автор подчеркивает необходимость постоянного рефакторинга, эффективности кода и важность документации для успешного выполнения проектов.

1. Автоматизация
бизнес-процессов:
проектирование архитектуры
конкурентных решений
Павел Спесивцев
Ведущий разработчик
7 ноября 2012 года

2. I object to doing things that
computers can do.
Olin Shivers
2/15

3. Цели
 Разработать подход к проектированию
IT-решений для бизнеса
 Выявить критические абстракции
 Обозначить наиболее важные аспекты
цикла существования программного
продукта
 Разобраться, что такое «бизнес-логика»
и что о ней надо знать разработчику
3/15

4. Бизнес-«нелогика»
Идея!
4/15

5. Задачи IT через призму бизнеса
 Нет полного видения модели предметной
области в перспективе, даже если все
уверены в обратном
 Сервисные задачи не интересуют
«бизнес-логику»
 Сделать «это» очень просто!
 «Это» нужно вчера
5/15

6. Эра «стартапов»
 Поиск надежной бизнес-модели, НИОКР
в области интернет-рынков
 Быстрый рост на начальных инвестициях
 Быстрое падение
 «Патентный троллинг»
 Слияние и поглощение
6/15

7. Предел гибкости
 Переусложнение неизбежно?
 Что забыли учесть?
 Закон Завинского
 Что потеряет проект в ближайший месяц,
если не сможет читать почту завтра?
7/15
Every program attempts to expand until it can
read mail. Those programs which cannot so
expand are replaced by ones which can.

8. Предел сложности решений
 Насколько интенсивно будет меняться
продукт в ближайшее время?
 Какова квалификация вовлеченной группы
разработчиков?
 Сколько времени понадобится разработчику
с опытом от трех лет, чтобы погрузиться
в проект?
8/15

9. Предел масштабируемости
 Будем ли мы продавать услуги клиентам
из соседних галактик?
 Сделаем все многопоточным?
 Что тяжелее – вычисления или данные?
 RDBMS vs NoSQL
9/15

10. Инструмент для задачи,
а не задача для инструмента
(маркетинговые ловушки)
 Западня универсальных систем
(«миллионы мух не могут ошибаться»)
 Насколько готовое решение решает
задачи ближайших 6 месяцев?
 Какова стоимость результатов работы
ближайших 6 месяцев?
 Риски vs страховка
10/15

11. Без чего жить программировать
нельзя
 Логов много не бывает
 Простота интеграции и миграции –
не путать с легкостью переключения
на другие СУБД (насколько нужна
последняя?)
 Ввода/вывода мало не бывает
 Кэш и его инвалидация
 Насколько просто это тестировать?
11/15

12. Перманентный рефакторинг
рабочий
прототип
элегантное
решение
оптимизация
12/15

13. О чем можно забыть
и потом сильно пожалеть
 Отказоустойчивость и устойчивость к взлому
 Простота диагностики
 «Ломка» при смене ключевых разработчиков
(«Кто это писал?»)
 Эффективность одновременной работы
большого числа людей над общим проектом
 Степень надежности проноса новых версий
 Инкапсуляция (неинкапсулированные решения
влекут затратный и болезненный рефакторинг)
13/15

14. Эффективность кода
 DRY!
 Документация
 Эксплуатация общепризнанных паттернов
(только достоверно необходимых для конкретной
задачи абстракции)
 Экономия «на спичках»
 Единый согласованный стиль кода
и абстракций для всех участников команды
14/15

15. Спасибо!
Вопросы?
Павел Спесивцев
spesivtsev@custis.ru
15/15