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

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

2. Введение

3. Краткое содержаниекурсаОбзор рынка разработки программного обеспеченияЧто есть и какая практическая разницаСобрать все в кучку, для определенности – надо оно вам или нет и что конкретноУглубленный рассказ про рынок бизнес (крупного) софтаПо ролям с деталямиЕсли оно вам надо, то в какой роли

4. Кто здесь?Александр Горникagornik@gmail.comСовладелец itcd.ruGoogle / yandex / facebook / livejournal / moikrug / …

5. ЗачемПоиск сотрудников+КармаХочется верить что по итогу курса хотя бы один человек придет к нам на работу / стажировку

6. ФормальностиЛекции доступны в электронном видеПри ответах можно пользоваться всем чем угодно5 –любая осязаемая практическая деятельность3, 4 – понимание о чем речь и способность искать информацию

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

8. ОпросКакие курсы, языки вам читали? HTML / HTTP?Кто лично писал код? На чем?Читали ООП?Кто знает что такое виртуальный метод?Читали ли вам базы данных?Кто может написать select? Как реализуется связь m:m? Структуры данных и сложность алгоритмов?Список народу с email адресами для оповещений о разном

9. Вопросы?Не задают только дуракиЧем больше – тем лучше

10. Какая бывает разработкаКуда бежать, на что смотреть, что выбирать

11. По языкуЯзыки низкого уровня (работа с памятью)Assembler, C, C++Языки высокого уровня (библиотеки + GC)Java (Java+), .NET (С#+)Нишевые (JavaScript, Ruby, Python, Flash, Flex …)Не совсем разработкаSQL, HTML …

12. По платформеКлассические приложенияWindows, Linux, приставки, «толстые» клиентыСерверные приложенияWeb, enterpriseWeb UI HTML, JSМобильные приложенияiOS, AndroidEmbedded системыНишевые1C, SAP, Bitrix, SalesForce…

13. По парадигмеПроцедурноеEmbedded и, быть может, самый простой UI (JS)ООП90% всего рынкаДекларативноеSQL и всякие DSL (MDX, конфигурации пр-тов…)AOP, функциональноеи прочееНишевое, для специфических задач

14. По размеруБольшое (релизы, поддержка, процессы)Объем кодаВозраст кодаКоличество человек работающих на проектеМаленькоеГибкость во всемРаботает почти всё что угодно

15. По типу задачАлгоритмы и производительностьembedded, графика, звук, AI…Бизнес приложенияБД, бизнес логика, большой размерКлиентские приложения (интерфейс)

16. По предметной областиБанки-финансы, медицина, производство, документооборот, игры…Есть очень большая разница между разными предметными областями

17. ТенденцииУровень языков повышается вездеСистемы становятся больше и сложнее (ООП)Все уходит на серверВеб разработка очень сильно растет (HTML5)Суровая специализация (iOS), мечты о кроссплатформенности пока только мечты

18. НапримерWeb приложенияВысокий уровень языковВсе размеры приложенийUIпрограммирование (на разном)БД, бизнес логика (часто)Бывают нюансы с нагрузкойИгрыНизкий + самый высокий уровень одновременноАлгоритмы, графика, производительность

19. «Корпоративные» (бизнес) приложения (системы)Google, facebook, 1c, sap, salesforce, ozon.ru, amazon.com, yandexи миллионы noname

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

21. Организационные сложностиМножество людей разных специальностейсложность координацииМножество заинтересованных сторонсложность сбора требованийСложность планирования и соблюдения сроков и бюджетовС учетом размеров проектов

22. Сложные бизнес требованияНеизвестность и неполнота бизнес требований при старте проектаПостоянное изменение и дополнение требований в связи с динамикой бизнесаКак следствиеСложность документирования требованийСложность их реализации и модификации

23. Сложность масштабированияПо определению не могут работать на одном физическом сервереВозникает задача – как сделать так, что производительность росла пропорционально добавляемому железуGoogle, Facebook

24. Длительная поддержка и доработкаЖизненный цикл ПО длится в разы большего среднего времени работы сотрудника на одном месте работыВ рамках поддержки нужно дорабатывать и расширять функционал системы

25. Интеграция с разнородными системамиПри разработке часто нужно использовать множество сторонних системБез возможности их модификацииВ т.ч. неготовых систем со своим циклом разработкиБез качественного описания таких систем

26. РешенияПроцессыКак организовать людей что бы правильно оценить, выполнить сроки в условиях меняющихся требованийАрхитектураКак организовать код что бы он позволял менять требования, масштабировался, был готов к расширению и интеграции, а еще дешев в поддержке и доработке

27. Как бывает и к чему стремимсяСкорость разработкиВыход на проектную мощностьПравильная архитектура и процессХорошоНеправильная архитектура и процессПлохоВремяБанкротство

28. В следующих серияхПроцессы разработки ПОРоли при разработке ПО

29. Как заработать много денег?(в этой области)Постоянно читать книжкиЗнать английский язык и читать западные источникиНаучиться письменно излагать свои мыслиНе ходить на работу в ФГУП НИИ…

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

31. Вопросы?Литература по данной лекцииДжоел о программирование (http://www.joelonsoftware.com/+ переводы)http://www.ozon.ru/context/detail/id/2820575/http://www.ozon.ru/context/detail/id/4878099/Фредерик Брукс, Мифический человеко-месяц