Автоматизация бизнес-процессов: проектирование архитектуры конкурентных решений 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! • Документация • Эксплуатация общепризнанных паттернов – только достоверно необходимых для конкретной задачи абстракции • Экономия на спичках • Единый согласованный стиль всех для всех участников команды Спасибо! [email protected]