Разработка корпоративных (бизнес) приложений (лекция 1)

Разработка корпоративных (бизнес) приложений

Введение

Краткое содержание курса

• Обзор рынка разработки программного обеспечения– Что есть и какая практическая разница– Собрать все в кучку, для определенности –

надо оно вам или нет и что конкретно• Углубленный рассказ про рынок бизнес

(крупного) софта– По ролям с деталями– Если оно вам надо, то в какой роли

Кто здесь?

• Александр Горник• agornik@gmail.com

• Совладелец itcd.ru• Google / yandex / facebook / livejournal /

moikrug / …

Зачем

• Поиск сотрудников• +Карма

• Хочется верить что по итогу курса хотя бы один человек придет к нам на работу / стажировку

Формальности

• Лекции доступны в электронном виде• При ответах можно пользоваться всем чем

угодно

• 5 –любая осязаемая практическая деятельность

• 3, 4 – понимание о чем речь и способность искать информацию

Посещаемость

Пожалуйста, не ходите на лекции! если не готовы слушать!

Опрос

• Какие курсы, языки вам читали? HTML / HTTP?• Кто лично писал код? На чем?• Читали ООП?• Кто знает что такое виртуальный метод?• Читали ли вам базы данных?• Кто может написать select? Как реализуется связь

m:m? • Структуры данных и сложность алгоритмов?• Список народу с email адресами для оповещений о

разном

Вопросы?

• Не задают только дураки• Чем больше – тем лучше

Какая бывает разработка

Куда бежать, на что смотреть, что выбирать

По языку

• Языки низкого уровня (работа с памятью)– Assembler, C, C++

• Языки высокого уровня (библиотеки + GC)– Java (Java+), .NET (С#+)– Нишевые (JavaScript, Ruby, Python, Flash, Flex …)

• Не совсем разработка– SQL, HTML …

По платформе

• Классические приложения– Windows, Linux, приставки, «толстые» клиенты

• Серверные приложения– Web, enterprise

• Web UI – HTML, JS

• Мобильные приложения– iOS, Android

• Embedded системы• Нишевые

– 1C, SAP, Bitrix, SalesForce …

По парадигме

• Процедурное– Embedded и, быть может, самый простой UI (JS)

• ООП– 90% всего рынка

• Декларативное– SQL и всякие DSL (MDX, конфигурации пр-тов…)

• AOP, функциональное и прочее– Нишевое, для специфических задач

По размеру

• Большое (релизы, поддержка, процессы)– Объем кода– Возраст кода– Количество человек работающих на проекте

• Маленькое– Гибкость во всем– Работает почти всё что угодно

По типу задач

• Алгоритмы и производительность– embedded, графика, звук, AI…

• Бизнес приложения– БД, бизнес логика, большой размер

• Клиентские приложения (интерфейс)

По предметной области

• Банки-финансы, медицина, производство, документооборот, игры…

• Есть очень большая разница между разными предметными областями

Тенденции

• Уровень языков повышается везде• Системы становятся больше и сложнее

(ООП)• Все уходит на сервер• Веб разработка очень сильно растет

(HTML5)• Суровая специализация (iOS), мечты о

кроссплатформенности пока только мечты

Например

• Web приложения– Высокий уровень языков– Все размеры приложений– UI программирование (на разном)– БД, бизнес логика (часто)– Бывают нюансы с нагрузкой

• Игры– Низкий + самый высокий уровень одновременно– Алгоритмы, графика, производительность

«Корпоративные» (бизнес) приложения (системы)

Google, facebook, 1c, sap, salesforce, ozon.ru, amazon.com, yandex и

миллионы noname

Смесь разных типов ПО

• Большие размеры• Длительные сроки разработки и поддержки• Различные интерфейсы (UI)• Сложная бизнес логика на сервере• Большие объемы данных• Большая нагрузка

Организационные сложности

• Множество людей разных специальностей– сложность координации

• Множество заинтересованных сторон– сложность сбора требований

• Сложность планирования и соблюдения сроков и бюджетов– С учетом размеров проектов

Сложные бизнес требования

• Неизвестность и неполнота бизнес требований при старте проекта

• Постоянное изменение и дополнение требований в связи с динамикой бизнеса

Как следствие• Сложность документирования требований• Сложность их реализации и модификации

Сложность масштабирования

• По определению не могут работать на одном физическом сервере

• Возникает задача – как сделать так, что производительность росла пропорционально добавляемому железу– Google, Facebook

Длительная поддержка и доработка

• Жизненный цикл ПО длится в разы большего среднего времени работы сотрудника на одном месте работы

• В рамках поддержки нужно дорабатывать и расширять функционал системы

Интеграция с разнородными системами

• При разработке часто нужно использовать множество сторонних систем

• Без возможности их модификации• В т.ч. неготовых систем со своим циклом

разработки• Без качественного описания таких систем

Решения

• Процессы– Как организовать людей что бы правильно

оценить, выполнить сроки в условиях меняющихся требований

• Архитектура– Как организовать код что бы он позволял

менять требования, масштабировался, был готов к расширению и интеграции, а еще дешев в поддержке и доработке

Как бывает и к чему стремимсяСкорость разработки

Время

Хорошо

Плохо

Банкротство

Выход на проектную мощность

Правильная архитектура и процесс

Неправильная архитектура и процесс

В следующих сериях

• Процессы разработки ПО• Роли при разработке ПО

Как заработать много денег?

(в этой области)

1. Постоянно читать книжки2. Знать английский язык и читать западные

источники3. Научиться письменно излагать свои мысли4. Не ходить на работу в ФГУП НИИ…

И еще раз почитать книжек

Вопросы?

• Литература по данной лекции– Джоел о программирование (

www.joelonsoftware.ru + переводы)• http://www.ozon.ru/context/detail/id/2820575/• http://www.ozon.ru/context/detail/id/4878099/

– Фредерик Брукс, Мифический человеко-месяц